3D Rotator

3D Rotator





Mark Jones with a program which makes


his 3D rotator published in the July


1983 issue up to eight times faster.





In July of last year, I wrote a program for Your Computer


called 3D Rotator. This program allowed the Basic pro-


grammer to manipulate simply defined 3D figures at machine-


code speeds. A typical time was 0.5 seconds for a cube.


Though this was extremely fast relative to Basic it was not


fast enough for practical dynamic games. With this in mind


I have speeded up the 3D routine by as much as eight times


and made it more versatile. The speeds achieved now are as


fast as those seen in commercial games such as 3D Tank


Duel, with the advantage that they can be called from


Basic.


Data is stored as blocks of code at any memory location


that you specify. The data should be followed by a blank


area which = 12 * (number of sets of data). Therefore the


total memory required for any one image = 19 * (number of


sets of data). The data itself is made up of three 2's


complement numbers and one 1 byte number. A 2's complement


number is a 2 byte number where the negative form is 65536-


number, e.g., -5 = 65536-5 and +5 = 5. A 2 byte number is


Poked into memory as described on page 173 of the Spectrum


manual.


The numbers are stored as follows: x co-ordinate, y co-


ordinate, z co-ordinate and the 1 byte number 0 to indicate


a plot at x,y,z or 1 to draw a line from the last point


plotted to x,y,z. I include a Basic program - program A -


which will handle conversion of data into a suitable form


for the machine-code program. The Basic program will also


store the essential parameters such as the pointer to the


data, number of sets of data etc., for that figure.


Producing the data for a simple 3D figure is relatively


easy. I refer you for further information to my article


3D Rotator of July 1983 and Ian Angell's article BBC 3D


Graphics in the February 1984 edition of Your Computer.


[I do not have current access to these articles. The BBC


article would, naturally, not be linked from WoS, but


Mr. Jones' earlier one seems to be missing as well. In any


case, anyone with a passing knowledge of 3D Cartesian


co-ordinates should find the single example in the Basic


program sufficient.]


The 3D program allows the parameters for up to 16 3D


images. These parameters are stored in fixed areas from


65032 onwards and in blocks of 20 bytes. Thus the start of


the parameter area for figure 4 = 4*20 + 65032 - see


table 1 [at the end of this file].


Each 3D image stored in memory should have a separate set


of parameters though they might share a common set of data.


Draws need not point to a memory area after your 3D data


but I find I keep track of my memory state better by doing


so. For example, fig.0 and fig.1 might both be pyramids and


so use the same data. Draws for fig.0 is as normal, after


the data, but draws for fig.1 points at another section of


free memory and its ADDR points to the fig.0 data.


If it has all seemed rather complicated so far, do not


worry - it is really quite easy to use these 3D routines.


Here is an example:


To set up fig.0 as a cube first of all work out your data


and then store it in data statements in Basic program A.


For a cube there are 16 sets of data so adjust line 15


accordingly. The data is going to be stored at 40000 on-


wards so first of all ensure this area is free from the


Basic system with a


CLEAR 39999


and then adjust line 10 accordingly. Finally, this is going


to be figure 0 so adjust line 5. Now run program A.


Once the program is complete it will give you a print-out


of the next free memory available for data, 40316, and also


the position of the parameters area, 65032. If you now


wished to have another cube that could move independently


of fig.0 then simply make line 10 read


LET addr=40316


Line 5 should read


LET fig=1


and run the program again.


This is, of course, an example and actual addresses will


depend on the number of sets of data you use. Program A as


printed will set up fig.0 as a cube as in the above


example.


Now to actually produce a 3D image on the screen there


are a number of steps:


# Select the current figure by Poking 64976 with the


required figure number 0-15.


# RANDOMIZE USR 64234 actually converts your data to a list


of plots and draws stored in the figure's associated free


area of memory, pointed to by Draws.


# RANDOMIZE USR 64692 produces the 3D image on the screen


from the list of plots and draws.


# RANDOMIZE USR 64679 deletes the last image drawn by the


above routine.


Therefore using various sequences of these routines you can


produce 3D images from within your Basic programs. As an


added feature I have included a machine-code demonstration


program which will put the current figure indicated by


PEEK 64976


through its paces. The number of steps, and so speed of


this demonstration, can be altered by Poking 63501 with a


number between 1 and 150.


The routine is called with


RANDOMIZE USR 63500


Finally, to alter a given figure's position on the


screen, distance from you or angle simply alter the 2's


complement numbers PX, PY, PZ, Phi, Theta and Psi in the


parameters for that figure.


To run a demonstration of the routines from Basic load


with program A and then GO TO 5000. This sets up three


cubes, shows off the machine-code demonstration and then


leaves the three cubes to float around in space spinning.


If you remember the 3D Rotator routine in my last article


you may be interested to compare it with these new rou-


tines. The routine to handle the 3D conversion is written


more efficiently, uses 2 byte x,y,z co-ordinates and does


not draw the figure straight away. This allows a number of


figures to be produced in memory but not drawn until


needed.


This routine also handles calculations for lines parti-


ally off screen ensuring that the line eventually produced


for the draw routine does not go off screen.


The routines to draw and delete figures use a draw rou-


tine specially written for this program which is extremely


fast. The routine does not draw a line by plotting but by


manipulating screen addresses and rotating a mask.


To use the plot/draw routine for for yourself use the


following method:


# Set up an unused figure, e.g. fig. 15, by Poking both


DrawS and DrawP with the same value, the address of an


unused area of memory. Next Poke STFLG with 255.


# Store your plots and draws at this address in the


following form:


P,x,y where


P=0 to plot at x,y


P=1 to draw from the last point plotted to x,y


P=255 to end the data


x is a normal x co-ordinate


y has the range 0-191 where 0 is the bottom line of


the edit area.


e.g. to draw a frame around the screen the data would be:


0,0,0, 1,255,0, 1,255,191, 1,0,191, 1,0,0, 255


[ The last two paragraphs described how to enter the


programs. The result is on the TZX. Program A mentioned


above, with a few lines added to make it auto-load the


machine code, is called "Demo". The 3D Rotator machine


code itself is, of course, "3D Rotator". The final


program, "codereader", is the Basic program B used to


load the machine code into memory; it should not be


needed any more, but I've added it for completeness. ]





Table 1.





Offset Bytes Parameter Description Range


0 1 NUMB Number of sets of data 1-255


1 2 ADDR Start address of data


3 2 PX X co-ord (+ve left)


5 2 PY Y co-ord (+ve up)


7 2 PZ Z co-ord (+ve forward)


9 2 PHI Angle about X axis 0-359°


11 2 THETA Angle about Y axis 0-359°


13 2 PSI Angle about Z axis 0-359°


15 2 DRAWS Address of free memory


after 3D data


17 2 DRAWP 6*NUMB + DRAWS


19 1 STFLG Poke this with 0 the 0 to 255


first time you use


the 3D image