Flicker free animation in GDI help
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?
January 23, 2003 09:29 PM
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement