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/ --- --
