Windows GDI Flickering

Hi I have just finished learning how to program simple windows and before I moved onto Direct X and all that. I thought it would be a good idea to make a simple game in windows. So I started and Im using the idea of, clearing an object on the screen by drawing a black rectangle around it. Then drawing the object again in a different position over the top of it.
I know windows GDI is meant to be slow I was just wondering if there was a way that isn't too advanced of getting rid of the flickering of the objects in the game.
Thanks

I haven't done any games or anything like that myself but I think you should use offscreen drawing. There's a lot of information about it in MSDN. Basicly you draw your things and then BitBlt them to screen DC.
Not that I know anything, I started winprogramming just this weekend myself:P.

Basically you create a HBITMAP and draw to it, then BitBlt it onto your window.

that's exactly right. It's called back buffering. You basically always draw to a bitmap in the background (a memory HDC). And then you blit when it is done. DirectX and OpenGL both also do this.

Okay so this HBITMAP. I am guessing this is a handle to something. My question is how would your draw to this. Could you still use your pens brushes and the HDC or is there another way, and then how do you then switch it with whats on the screen?

If anyone has an example of some code I can see it would be very appreciated thanks.

I have a code snippet of how I created my back buffer and bound it to a DC.
http://cboard.cprogramming.com/showt...threadid=43686

The best solution is the double buffer solution that everyone is speaking about. It is how all real games are made today.

But... Depending on your game, you can make it like they did in the old days - draw the object in its new location first (assuming no see-thru pixels in the sprite), and then delete the sprite from the old location, but only what was NOT covered by the drawing.

Personally, I would just learn the double buffering method. Even though GDI is slow, its fast enough for a simple game with double buffering. And, you'll get used to how it is done, which will help when you eventually move on to DirectX.

>>Could you still use your pens brushes and the HDC or is there another way<<

Yes. Once you have created an off-screen 'memory' device context and selected a valid bitmap into it you can use any gdi drawing function you want. Same goes for gdi objects such as pens and brushes.

>>how do you then switch it with whats on the screen?<<

Use BitBlt - an example of its use is linked at the bottom of that page. Search this board and google for plenty more examples.

Alright im starting to get this and managed to get an example of this technique working. Just another question and hopefully I will be out of your hair. You see I have a project in a number of classes each in control of drawing their object. Should I have each class create a seperate bitmap and do each bit individually, or just have one big bitmap as a parameter to each of these functions and repaint the whole screen?

Thanks again

>>Basically you create a HBITMAP and draw to it,

No you create a compatible device context and bitmap. A HBITMAP is just a handle to a bitmap. It needs a device context to hold the rest of the GDI resources.

>>create a seperate bitmap and do each bit individually, or just have one big bitmap as a parameter to each of these functions

Up to you. I do both depending on the complexity. If you are moving an image around the screen I would suggest seperate bmp's. As this will allow you finer control. Assemble all the little pieces then draw them all to the back buffer.

Then call for a paint.
Do not do more than one BitBlt() in the paint handler.

Alright thanks for that. I will just have one bitmap. its seems more efficient somehow and then get each class to edit it how it sees fit and then in the end bitblt the final product to the screen.