Example: anim_one
Setting up
Before we get things animated, we need to set up a structure to store the position of the ball between updates. This struct will store the current position and size of the ball, as well as the delta values, how much we want it to move each frame.
Once we have the structure type declared, we also declare a global instance of the struct. This is ok since we only have one ball, if were were going to animate a bunch of them, you’d probably want to use an array or other container (such as a linked list in C++) to store them in a more convenient way.
We’ve also defined a constant BALL_MOVE_DELTA
which is how far we want the ball to move on each update. The reason we store deltas in the BALLINFO
structure as well is that we want to be able to move the ball left or right and up and down independantly, BALL_MOVE_DELTA
is just a handy name to give the value so we can change it later if we want.
Now we need to initialize this structure after we load our bitmaps:
The ball starts off in the top left corner, moving to the right and down according to the dx
and dy
members of BALLINFO
.
Setting the Timer
The easiest way to add a simple timer into a window program is with SetTimer()
, it’s not the best, and it’s not recommended for real multimedia or full games, however it’s good enough for simple animations like this. When you need something better take a look at timeSetEvent()
in MSDN; it’s more accurate.
Here we’ve declared a timer id so that we can refer to it later (to kill it) and then set the timer in the WM_CREATE
handler of our main window. Each time the timer elapses, it will send a WM_TIMER
message to the window, and pass us back the ID in wParam
. Since we only have one timer we don’t need the ID, but it’s useful if you set more than one timer and need to tell them apart.
We’ve set the timer to elapse every 50 milliseconds, which results in approximately 20 frames per second. Approximately because like I said, SetTimer()
is a little inaccurate, but this isn’t critical code, and a few milliseconds here or there won’t kill us.
Animating in WM_TIMER
Now when we get WM_TIMER
we want to calculate the new position for the ball and draw its updated position.
I’ve put the code for updating and drawing the ball in their own functions. This is good practice, and it lets us draw the ball from either WM_TIMER
or WM_PAINT
without duplicating code, note that the method we use to get the HDC
in each case is different, so it’s best to leave this code in the message handlers and pass the result into the DrawBall()
function.
All this does is some basic math, we add the delta value to the x position to move the ball. If the ball goes outside the client area, move it back in range and change the delta value to the opposite direction so that the ball “bounces” off the sides.
This is essentially the same drawing code as the past few examples, with the exception that it gets the position and dimensions of the ball from the BALLINFO
structure. There is however one important difference…
Double Buffering
When doing your drawing directly to the HDC
of the window, it’s entirely possible that the screen will get updated before you’re done… for example after you draw the mask and before you draw the colour image over top, the user might see a flicker of the back background before your program has a chance to draw over it in colour. The slower your computer and the more drawing operations that you do, the more flicker will be apparent and eventually it will look like a big jumbled mess.
This is terribly distracting, and we can solve it simply by doing all the drawing in memory first, and then copying the completed masterpiece to the screen in a single BitBlt()
so that the screen is updated directly from the old image, to the complete new image with none of the individual operations visible.
To do this, we create a temporary HBITMAP
in memory that is the exact size of the area we are going to draw to on the screen. We also need an HDC
so that we can BitBlt()
to the bitmap.
Now that we have a place to draw to in memory, all of the drawing operations use hdcBuffer
instead of hdc
(the window) and the results are stored on the bitmap in memory untill we are complete. We can now copy the whole thing over to the window in one shot.
That’s it, and we clean up our HDC
s and HBITMAP
s as usual.
Faster Double Buffering
In this example I am creating and destroying the bitmap used for double buffering each frame, I did this basically because I wanted to be able to size the window so it’s easier to just always create a new buffer than to track when the window position changes and resize the buffer. It would be more efficient to create a global double buffer bitmap and either not allow the window to resize or only resize the bitmap when the window resized, instead of creating it and destroying it all the time. It’s up to you to implement this if you want to optimize the drawing for a game or something.
Killing the Timer
When our window is destroyed, it’s a good idea to release all resources we used, and in this case that includes the timer we set. To stop it, we simply call KillTimer()
and pass in the ID that we used when we created it.