Bitmap blit speeds

Miscellaneous Forums/General Discussion/Bitmap blit speeds

Not sure what language you're using but in BlitzMax if you were using OpenGL for example, without any extensions, you are not guaranteed that the contents of the backbuffer remain intact after a Flip. Sometimes it is, sometimes it isn't. So you can't really treat the backbuffer as a permanent storage place for the previous frame, and besides that the backbuffer has to be the same size as the screen resolution so you can't create extra room for scrolling. And there is no hardware scrolling.

To get it to work you need a separate graphics buffer, which would entail using GL extensions, to create like a framebuffer object and/or render target to render directly to it and then switch it with the backbuffer. Hopefully that switch might not entail a full-screen copy, otherwise it's pointless. But then your buffer can be bigger than the screen and you could feasibly easily achieve 360-degree tilemap scroll engines just like in the Amiga days with minimal redraw.

One thing to consider though is that preserving the background and then drawing moving objects on top of it means that you have to `restore` the background also, so you have to have double-buffering of your buffers (ie to large buffers). If your restoration of graphics is to be efficient you have to use like `dirty rectangles`. But then dirty rects are only efficient up to a point. When there is a lot of stuff going on on-screen graphically, lots of animation etc, it is possibly more efficient to just redraw the whole background rather than restore the graphics, and then you also can skip having to draw extra strips of tiles for scrolling, and also can skip needing large image buffers. So it sort of depends on the visual needs of your game. Trying to copy sections of image buffer from one place to another would have to entail use of making one buffer be a texture and using it to render to another texture, otherwise it'd be too slow to use the `copyrect` routine.

There are also added benefits to updating the whole screen at once. There are no `playfields` on modern graphics cards since they are chunky-format based rather than planar. So if you want to do parallax scrolling you either have to do some clever stencil masking or redraw the whole screen anyway. Also when you redraw the whole screen you get animation capabilities for every single tile `for free`. If you want your tile map background to be highly an animated then this would be the way to go. Also once you get into more advanced stuff like lighting or semi-transparency or foreground/background layers etc it starts to become less desirable to try saving parts of the screen - especially when different areas of the screen start to scroll independently of each other. And what about if you want to start rotating things?

If you just want a minimally-animating one-layer tilemap, maybe two-layers if you're clever, perhaps something like a 2D Mario platform game, you might see some speed gains from using these old techniques, but otherwise I don't see that there is a lot of appeal anymore. The benefits of redrawing everything I think are far more appealing than the slight loss of speed that it might entail.

Also consider the low-end specification of graphics GPU's these days. Probably most computers out there have enough speed and hardware acceleration to run a decent tilemap game with full screen redraw. Like, even 4-5 years ago an iMac had a GeForce4 GPU which is fast enough to run most games like that.