Ah... one more thing.
In your line routine you are using
Dbug's Method of Flood Filling Memory
You use at least:
- two 201 tables for pixel address
- three 256 tables for mul6, div6 and mod6
- An additional table of 240 bytes for I don't know what...
which is 1410 bytes of tables! add that to your 711 bytes routine and other minor tables...
I am using just two tables, one of 200 bytes and another of 240, which are used for pixel address (pointer, mod6, and bit inside scan).
But, of course, this means lots of more cycles per loop, even if it is just the jsr/rts and other minor operations...
I wonder if there is any way of mixing these two, to keep the speed while saving memory. Or do you think we can make this expense? Remember we will need at least a sin table and others for fast multiplication (a table of squares, typically, but depend on the algorithm). I fear we end up with using 5K just for drawing lines and make multiplications!
Well, in the end, we can allways put that in overlay and load from disk
Some (large) notes about making 3D... This is long but I would like to get some feedback on it... even if it might be confusing at some points.
Everything is based on Vertexes. We need 3 lists of vertex coordinates (16-bit each <x,y,x>) of MAX_VERTEX length... More than 64 vertexes could be too many to deal with.
A polygon is defined by a list of vertex (indexes to the above list), such as
<v1,v2,v3,v4,$ff> ($ff indicating the end of list)
which means "draw a line from v1 to v2, then from v2 to v3, then from v3 to v4 and close it with a line from v4 to v1".
Objects are defined by a list of polygons, e.g.
<number of polygons> <v1,v2,v3,v4,$ff><v5,v6,v7,$ff>...
Converting everything to triangles makes life much easier, but it was not used in Elite (I think) and might increase the number of lines to draw and vertex to move!
3D movement is just applying transformations to sets of vertex. When a ship moves or rotates, only its vertexes are transformed. When the player does this (roll its ship or turn), ALL the vertexes are transformed. Transformations are matrix operations, normally being some multiplications for the value of the sin or cos of the angle and/or some additions/substractions.
Then, at each frame project them over the list of vertex projections. Two buffers (old and new), each one with two (x,y) 16-bit entries per vertex.
Then "simply" draw each object, i.e. get a polygon, calculate if it is hidden or not (more multiplications here) and, if not, draw it line by line.
Another thing that should be done is keeping track of those lines that have already been drawn (as pairs of vertex, which are indexes of 8-bit). Before drawing a line, look if it has been already drawn to skip the process...
Need a good way of storing this information to speed up the search process... I imagine Dbug setting up a matrix of MAX_VERTEX*MAX_VERTEX to implement this
This only deals with objects in the scene, and I am avoiding talking about clipping!
In fact we need to keep track of objects out of sight (as they appear on the radar) and "drop" them into the scene when they get in the field of view (and pop them out when they exit the field of view).
I think this is easier, as we just need to know there is an object at 3D coordinates <x,y,z> and deal with its movement and actions (firing, escaping...), BUT also need to apply transformations, as the reference system is usually set up with the player ship as origin.
Maybe this can be skipped, and use a "world" scene with "absolute" 3D coordinates, and change them when the object enters the field of view, but I don't know if there will be problems here...
This is indeed a great challenge! but it was also making an isometric game... even some thought it was impossible
If only we could add one of the creators of Elite to this discussion to enlighten us...