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
