Hi, Stephan wrote: > is something you cannot do anyways. I'm further saying that the > accelerant hook does not do the clipping, but it can however be done > in > DisplayDriver before passing it on to the accelerant. The accelerant does not do clipping indeed. You are required to tell it what exactly litterally to blit. There could be one exception, but you may not rely on that: (Virtual)screen size clipping. The accelerant in theory could set the engine to clip at the borders of a screen (so say 0,0,640,480 or so). I am not using this. Clipping in my accelerants is disabled: activating that means I need more hw registerlevel info. Not always available! > I hope it is clear now which kind of overlapping I mean. It would be > much easier if I draw this out on paper, I guess... :-)) If you would issue blitting commands this way: (in a single cmd to the accelerant (one list) 1. blit 0,0,100,100 -> 100,0 2. blit 50,0,150,100 ->400,400 You have a problem: between 1 and 2 you need to update the rectangle 50,0,99,100 with content or you will copy partly rubbish during the second blit. (I might be a single bit off: it's always hard to envision it exactly :) > I'm pretty sure it does an in-place copy. It just figures out in > which > direction to read and write the bytes, so that it doesn't read from > locations that have already been written to during that operation. > Suppose this: The accelerant does in place copying indeed. Direction is either determined by software in the accelerant, or by the HW itself(!) > And that's correct. Ok, I hope you understand what I mean by in-place > copy and what I mean by overlapping. That is the one kind of > overlapping. In this case, the destination area overlaps the source > area in memory, but that is _no_ problem when you take that into > account in your copy algorithm. And I think this is what the graphics > engine in the accelerant is doing as well. It does not copy to out of > screen regions and then back into visible region at the offset. > Unless > Rudolf convinces me otherwise... :-) Nope. I'll most certainly NOT do that! :-) (stay out of 'my' memory please ;-) Bye! Rudolf.