On Thu, 28 Mar 2002, Phoebus Dokos wrote: > Hi all, > I was wondering if anyone has tried moving screen memory around using a > lookup table instead of calculating the memory position of each pixel every > time...
Yes. > Anyone that has used both methods knows which one is faster? It depends on the usage pattern, and the scaling factor. Scaling factor: If the factor is 1:1 or 2:1 or similar, it's much easier than if the scaling factor is 525:625 (for example) Usage pattern: If it's a one-shot deal, creating a table is significantly slower. If it's a table which once calculated can be used repeatedly, there's no real penalty in speed, but the price you pay is making a large quantity of memory permanently unavailable. > That table would be an X (the x coordinate) by Y (the y coordinate) and in > each x by y position, the screen memory address that this corresponds to > would be contained (and maybe the alternate memory location for swapping)... > > In that aspect when giving a hypothetical command Draw_Sprite, x,y, instead > of calculating every single time what memory address x and y correspond to, > the command could look it up a table directly. My solution was simple, very fast, and very flexible. I created a small table of precalculated values for each possible combination. In my case, there were two resolutions: 512x256 and 1024x512, so the scaling ratio was 2:1 forward or 1:2 backward. For each direction I had precalculated steps calculated for the first byte address of each scan line, and a multiplier (1 for double, 0 for half). I also included a line length, because comparing a byte value is quicker than using MOD and doing division, which is relatively slow. Using this method, I got a factor of 25 speed improvement on the previous system, which gave time to do processing to the byte being transferred, say to change color depth etc. If I knew a little more about the exact scenario I could send you a nice block algorythm. Dave
