At 02:25 �� 28/3/2002, you wrote: >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.
See my previous email. The problem is not when you want to move the whole screen or at least huge parts of it as the calculations are minimal but when you want to quickly move around very small screen blocks very fast. A good analogy would be to calculate sine or cosine every time when you can just use a table :-) Phoebus
