The transformation matrix is calculated in the following way (I won't bother describing how I formulated this method: see an advanced maths textbook for details): to rotate an angle q about the origin, the 3x3 trans matrix is defined:

In actuality, when I want to rotate my polys in the 3D world, I define the matrix before hand: the sin and cos functions are comparatively slow; and then apply the matrix using a fast seperate procedure, written in assembly language (I will not describe my experiences of trying to code matrix multiplication on the FPU. Makes me shudder even now). Right: you can now effectively move around your 3D world. Any forms of movement (up and down, sliding left and right) can be implemented by changing the x, y, or z values of your polygons. The next major concept lies in converting these 3D polys to 2D points for display on the screen. First, something vital but often overlooked must be done: your polys must be sorted. This is necessary to ensure that polygons in the foreground obscure those behind them: your world will look pretty trippy otherwise. The best way to sort them is to use a quick sorting algorithm (such as quicksort), but to use complete z values for best performance. The polygons must be sorted in order of descending z values, so those furthest into the screen are highest on the list. You can do this by averaging out the z values for each poly, although I dare say there are more sophisticated ways of doing this: nonetheless, this works quite fine. It should be noted that the polys only change their order when rotated; and so there is no need to use a slow sort routine when moving backwards or forwards, so omit this if you need to optimise. In addition, a cutoff point needs to be decided for drawing the polygons, to ensure they dissappear once behind you.

Back to previous page | Next page