drawing & animation

using the win32 gdi #2

backbuffering, autoredraw and refresh

in the previous section we used the autoredraw property and the refresh function to force a copy of the form to be stored in memory and then updated. the same thing can of course be accomplished on a picture box.

there is also an alternative to this scheme, namely backbuffering. backbuffering is a simple technique, where you keep a 慶opy?of the gaming field (display area) in a non-visible area. all the sprites and other drawings are drawn into the backbuffer, which is then drawn all at once onto the display area.

if we could view the process it would look something like this:

step 1: draw all the masks and sprites onto the non-visible back buffer

step 2: draw everything in the back buffer to the visible area

so why does this produce flickerless animation? the main reason is that we only use one blit operation to draw everything we need from the backbuffer to the front display area. this disables all the intermediate updates, which might occur between each blit operation, and thus produces a clean drawing. get it? basically you are doing all the work with the sprites and masks off screen, where the game player doesn't see it and blitting to the play area once. the other way all the operations take place in the visible play area.

which method is then the best method? well, it depends on your type of application and the design you have made. the sample project backbuf found in backbuf.zip demonstrates both methods and times the amount of time elapsed. we tested both of the methods with this sample project and with some additional projects. all the empirical data from the tests conclusively demonstrate that neither method is faster. the best would of course then be the autoredraw ?refresh method, since it does not use the extra picture box to store the backbuffer in. but it also depends on the size of the drawing area you have. if it is big, then the refresh ?autoredraw method -might appear slightly slower than the backbuffering scheme. so the choice is really up to you, test your game with both schemes and use the one you like best.

sprite animations and stretchblt

now we know how to move a sprite around the window, but usually that is not enough to form a complete game. sometimes there is also a need to change the actual sprite image, in order to accommodate certain conditions of a game.

the actual implement of such a scenario is actually quite simple, it is just a matter of changing the actual sprite picture. so if we had a need of a small ball note: will change this to a small animated character instead rotating around the screen, we would simply make each rotation in a drawing program and draw each in a specified order. very much like a little cartoon animation block.

in the sample project animation contained in animation.zip we will do just that, create a ball with shifting colors. the first thing to note is that so far we have used a picture box to hold each separate bitmap. if we were to do that for each sprite in a game with several animated sprites, we would be using up quite a number of picture boxes. so instead, we will draw all the animation frames of the sprite in just one bitmap, and only draw the part of this bitmap that we need. the bitmap would look like this:

notice the apparent black sprite, which actually represents a black circle.