Name: Voxie - A 4K demo entry Author: Jeffrey Lee Size: 4096 bytes Needs: Probably runs on RISC OS 2 and above, 264K free RAM, 160K screen memory Description: A rather fast voxel renderer, with a few other demo FX stuck round it to bring it up to the 4K limit Introduction ~~~~~~~~~~~~ Run voxie, watch the 3 demo FX, then play with the voxel. Once the voxel is up and running, the cursor keys will turn/move the camera and escape quits. Because the voxel is randomly generated, you may sometimes end up with a voxel that's all one colour, or rather repetitive.... if this happens simply run voxie again to get a new one. Features ~~~~~~~~ * Some code to warp & scroll an image of the desktop (demo FX 1) * Some code to clear the screen from the bottom up (demo FX 2) * A scrolly message (demo FX 3) * A random voxel generator, based around the intersection of two cos waves * A fast voxel renderer with simple fog, reaching between 20 and 100fps on a Strong ARM The code ~~~~~~~~ There are two source files - voxie_src and voxie_src2, both requiring extASM V1 to compile (Have a look round acornsearch.co.uk to find a copy). estASM may be old, but it's easier than doing LADR's and stuff in BASIC. voxie_src is the source for the CodeCraft version, while voxie_src2 is a development version just featuring the voxel generator & renderer, and a few other control features. The CodeCraft version has a slightly improved voxel generator & random number generator, and the routines jiggled around a bit to reduce the number of instructions that get expanded. The source should be 32bit compliant, but I haven't checked it against the guidelines ;) There are also the two BASIC apps MakeTable and MakeTable2, which generate the colour and cos tables used by the code. In voxie_src2, the extra controls are: N - Generate new voxel E - Erode current voxel. Repeated erosion causes a symmetrical design :( V - Switch between top down and 3D view S - Toggle VSync waiting Also the number of centiseconds taken to draw the voxel is shown in the top-left corner of the screen. The main point of interest to anyone looking through the source is probably going to be how I got the voxel renderer running so fast, so this is it: A simple voxel renderer would send out one ray per screen pixel, resulting in a lot of data being loaded and checked when most of it doesn't result in a pixel being drawn. But if you were to fill the screen column by column from the bottom up, then you can cut out most of the work by using the previous ray to start the next one; when a ray hits the voxel, you calculate the screen y position needed to clear that part of the voxel, draw a line up to there on screen, then recalculate the ray position and direction so that it continues from above the part of the voxel you just hit. This means that it's effectively building up the screen by following the contours of the voxel, rather than mindlessly bombarding it with rays. Of course the above method only works well when the camera isn't pitched or rolled; if it were then the x and y gradients of the rays would change for each pixel going up the screen, leading to miscalculations on how long the line it needs to draw is, and where to continue from once it has been drawn. I do have some code lying around to allow the camera to be pitched, but haven't tested it yet... An interesting point to notice about the source is that I've made no attempt to read or write to the screen in words; I did try it out, but my attempts only made it slower :( Contact ~~~~~~~ If you want to report a bug, suggestion, improvement, or other comment then send an email to phlamethrower@hotmail.com.