Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

romer

Flicker free animation in GDI help

This topic is 5688 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

A friend told me to try making a program showing the rules of conway''s game of life being carried out. I''m doing it in straight Win32 using GDI for the graphics. It''s pretty much done, everything works and all, but I''m going back and making a few tweaks here and there. The main problem I have with it is that currently when I draw to the window, it flickers badly. They way I have it set up is that when the user hits a key, it updates all the structures holding the data, then it paints everything at once. I''m doing the painting in the WM_PAINT section of my message loop. I was wondering what''s the best way of removing the flicker when using GDI? I''ve read about doing a sort of double buffering technique using memory DCs, but when I tried implementing it, it still flickered quite a bit. I think, however, it was because everytime it was going to redraw the grid of cells, it would create a new memory DC, then when it was finished drawing, it frees the DC. Should I create the memory DC only once? Should I call CreateCompatibleDC using the hdc returned from BeginPaint if the drawing is going to be done in the WM_PAINT handler? Are there any other techniques I can look into for removing the flicker when using GDI?

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
use a memory bitmap that represents the entire drawing area. create it up front, using createcompatiblebitmap with a dc of your window''s as the dc param (this will create a ddb instead of a dib), and don''t deleteobject it until the app is closed. do the same thing for your memory dc. do all of your drawing to the memory dc. the only thing you should ever do "to" the window dc is one bitblt which blits the entire memory bitmap to it using a srccpy rop.

don''t use invalidaterect or wm_paint processing at all for your life cycle updates. instead, use some sort of timing mechanism, either through a normal gaming loop and time-based updates, or fixed fps, or possibly wm_timer msgs if you don''t care too much about the accuracy of the timing. in any event, use your own dc gotten via getdc as the destination of your bitblt. if you set up your window class with a class dc you can get this dc up front and then release it only when the app is closed. i think the class style is OWNDC. this type of dc you don''t have to worry about freeing up like you do with a dc out of the normal pool of dcs.

make your window class''s background brush null and process the wm_erasebkgnd msg by a "return 1" statement so that no drawing is done. for wm_paint processing, you should only need one bitblt call in between your beginpaint and endpaint calls; other than the different destination dc this bitblt would be just like your gaming loop bitblt.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!