On Sunday, January 12, 2003, at 04:27 pm, Thomas Harte wrote:
I also wonder whether the extra memory would be of particular
benefit.
Yes, at least if you're drawing in Mode 4. Do you remember a demo
called DWC (Dead Wild Cat) by Marc Broster on Fred 50? It drew
rotating
3D wireframe objects and usually kept up to 50 fps. He used most of
the
Sam's memory to hold pre-calculated line drawing routines.
You mean, if he had been able to go to extremes, having 256*192 *
256*192 routines, one for each possible [clipped] slope and position
of line?
Well, I haven't examined it, but if I were doing the same thing, I
wouldn't use quite that many routines (it would take just over two
gigabytes of RAM just for the single-byte RET instruction at the end of
each routine...).
We can assume one register-pair (say, HL for the sake of argument) will
be set up with the address of x1,y1 when the routine is called. From
there you only need 512x384 routines to draw to any possible position
on the screen. If you have the option of swapping the start and end
points such that y1 <= y2, you can halve the number of routines to
512x192. But you'd have to double it again to cope with the line
starting in the left or right half of a byte. If you assume that lines
will never exceed a certain length, you can reduce the number of
routines even further. You could split long lines into shorter
sections, and call the routine for the shorter section instead of
repeating a lot of the code.
Actually that's still potentially quite a lot of routines. Maybe he
filled memory with math-tables to optimise one routine... Anyway, my
point was that for Sam graphics programming, in general the more memory
you're prepared to use, the faster your code can get (this isn't
necessarily true any more on modern CPUs, because in many similar
situations you're more limited by cache size and bus bandwidth than by
raw processing power. The cost of looking up a result often now
outweighs the benefit of not calculating it).
I always thought a good way to attack a vector renderer on the SAM
Coupé would be to stick in black and white, but to take advantage of
the 16 colour palette and the scanline interrupts to clear 1/16ths of
scanlines which are not reused very cheaply. Or possibly to clear
16x16 blocks of pixels, depending on how much you want to expend on
interrupt palette things. Otherwise, it always strikes me that
clearing the display costs almost as much as drawing it in the first
place which is a stupid situation to be in.
I don't quite see what you're getting at with your descriptions above...
However, the way I see it; every byte that you clear costs time. The
ideal situation is when you're only clearing bytes which were used in
the previous frame and were unused in the current frame. If you clear a
block of 16x16 pixels, that's likely to be a lot of bytes which were
never filled and so didn't need to be blacked out.
Andrew
--
--- Andrew Collier ----
---- http://www.intensity.org.uk/ ---
--
r<2+ T<4* cSEL dMS hEn/CB<BL A4 S+*<++ C$++L/mP W- a-- Vh+seT+ (Cantab)
1.1.4
