I think you are right anatoly, in that doing something special for scrolling is what is the right thing, and having an api that blocks blitting to itself but has a special call for "scroll" would be the ideal api.
However I remember way back when SDL was much younger (like late 1990's) blits of a surface to itself would not crash (why should they?) but would instead do what you would expect for an efficient blit routine - if you blitted with an offset opposite the sequential order that the blit would be performed in, you'd end up "tiling" or repeating some portion of the image all over itself (because as you'd copy pixels into parts of the source you havent copied from yet, you'd be overwriting the source image before you got to use it) So the fact that anybody is able to use this blitting a surface to itself trick to scroll in 4 directions without getting crap results, means that SDL must have implemented some sort of blit a surface to itself magic that involves either changing the sequential blit direction, or using intermediate copies of some sort. Which basically means SDL must have special code that says "blit to self = do blit that is safe for scrolling operation" So given that, it seems to me that bliting a surface to itself should be a valid op in SDL land starting at some point post-2000, but for that the code somehow got broken on windows in some revision. On Sun, Aug 3, 2008 at 10:45 AM, techtonik <[EMAIL PROTECTED]> wrote: > > The root of such problems is why people need to blit on the same > surface? Usually it is because they just need to scroll it a bit to > avoid repainting the whole thing from scratch. Perhaps some scroll > methods will be more welcomed than another exception to process. > > -- > --anatoly t. >
