I'd not seen that demo previously. What is it using all that memory
for? From the description of the tables being pretty easy to generate,
it makes it sound like some of the 3d positioning is precalculated,
but then he seems to think that he'd be able to save a lot of memory
if he didn't have the speed of mode 4 pixel plotting to deal with. So
maybe it's [parts of] the line drawing code?
On 9 Apr 2008, at 01:49, Andrew Collier wrote:
On 8 Apr 2008, at 14:35, Thomas Harte wrote:
I know there are some demos with bits of 3d graphics, but I figure
that spending 256 kb on getting the fastest possible rotating cube
isn't a helpful guide.
I assume you're referring to Marc Broster's "Dead Wild Cat" demo on
Fred 50, here?
In defence of big pre-calculated tables: unless you have specific
plans for other use of that memory, what's wrong with using the
resources available to make your code run more quickly?
— is there any speed advantage to using the ROM routines such as
JDRAW, JPUT and/or JBLITZ? I appreciate that they are more general
case than routines that it makes sense to write for a game, but as
I understand it the ROM is uncontended?
The speed gain from uncontended instruction RAM is a relatively
small effect (especially for routines which write to the screen
often, since any access to main RAM will round timings to the
nearest 8 t-states if the screen is displayed). The ROM line drawing
routines are written very much for being small; in MNEMOdemo 2 I
wrote some line drawing routines which are significantly faster (I
can't remember how much - probably a factor of 3 or so) at the cost
of making them about 8 times bigger, which was still only a couple
of k. Basically, by writing several routines each specialised for a
small range of angles, you can remove some comparisons which
otherwise get performed for every pixel.
At the far extreme, you could generate code sequences to draw lines
of specific and exact length and direction; a seperate routine for
every individual line. This way, no run-time angle calculations at
all would ever have to be performed. A quick back-of-the-envelope
calculation suggests that a routines to draw every possible line up
to 64 pixels in either x or y offset would take roughly 300k (plus a
16k table pointing to the location of each routine) so that could be
a viable approach.
Andrew
--
--- Andrew Collier ----
---- http://www.intensity.org.uk/ ---
--