On Thu, 28 Mar 2002, Phoebus Dokos wrote: > 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 :-)
My algorythm is still quicker. Some values are calculated just once. The X, Y, X',Y' dimensions. The Xinstep, Yinstep, Xinstep', Yinstep' (distance in from edge in bytes) Xscale, Yscale (redundant if 1:1) Xmax', Ymax' (to quickly detect overrun of the side/bottom of the new screen, required only on the first and last lines) If you check the bounds first, then calculate the required steps and offsets, it's a straight nested loop to do the copy. My worry is you said that the start of (either one of?) the screen memories could move while the copy/move is happening. If this is the case, these checks have to be done whether you use a table or not. Or find out what causes the screen base address to change, and block that activity while the copy is in progress? IMHO Dave
