Sign in to follow this  
ProblemBaby

stable refresh rate with GDI

Recommended Posts

Hi Iam going to make some editors for my game and want to be able to show examples of animations etc so I need a stable refresh rate, I dont want to involve OGL or DX if it isn't necessary and all drawing is already programmed with GDI. My question is: what should my main loop and drawing routine look like? I want to refresh each 1/60th sec. Its no fullscreen drawing just a 256x256 area, do you think it will run too slow? Thanks

Share this post


Link to post
Share on other sites
By stable refresh rate, you mean "I want exactly this refresh rate" or you mean "I want to have a good enough refresh rate that won't vary too much" ?

Using GDI, the first one won't be possible. You application may be delayed if another application takes too much CPU, and moreover Windows is not a RTOS. The last one may be possible, providing that you don't want to cover the full screen (seems to be your case (256x256 is small enough) and providing that your update function is fast enough. You'll have to use a timer to handle teh refresh (and draw directly in the timer handler instead of sending a WM_PAINT message: paint message can be queued and merged)

As a side note, if you want to achieve fast blitting I recommend you to give a look to teh very small tinyptc library.

HTH,

Share this post


Link to post
Share on other sites
It sounds like you want to draw waiting for the vertical blank of your monitor, however I don't belive you can do this in GDI, if you are trying to reduce flicker/tearing, then draw everything to a memory DC backbuffer and draw it to your window with your gameloop.

In direct3D and directDraw it gives you the option to wait for the vertical blank to avoid 'tearing' which I assume is what your refering to.

Share this post


Link to post
Share on other sites
Yeah thats what I want!
3 questions though...

1.
Should I manually code the "wait code"
(Loop until its time to update)

2.
How is a backbuffer created, flipped, what functions should I look up?

3.
What should my WM_PAINT look like?

Share this post


Link to post
Share on other sites
Quote:
Original post by ProblemBaby
Yeah thats what I want!
3 questions though...

1.
Should I manually code the "wait code"
(Loop until its time to update)


This is the main idea, but it is not possible under windows. Normally, you have to poll a VGA port but AFAIK this will be impossible to do under Windows XP. If you plan to use DirectX, you can setup vsync correclty so that it will only redraw your window

Quote:
Original post by ProblemBaby
2.
How is a backbuffer created, flipped, what functions should I look up?


Have a look to CMemDC code (here). It is some MFC-based code, but you'll get the idea.

Quote:
Original post by ProblemBaby
3.
What should my WM_PAINT look like?


I tend to believe that you don't want to achieve a 60Hz refresh rate. What you want to achieve is a flicker free refresh. To do this in a classic Window application, you must
  • catch the WM_ERASEBKGND message and return TRUE - so that the system will never erase the content of the window with a solid color
  • use double buffering (using a DIB section, as shown in CMemDC)

This way, you'll have a stable look and you won't have to update your windows at this insane refresh rate. In fact, you'll only have to update your windows if something changed.

Now, if you want to display animations at a fast rate, I strongly suggest you to modify the application message pump and to display one frame each time you don't have to handle a message. This way, you won't even have to wait for a timer or wait for a WM_PAINT message to come. You simply draw on your window, and that's all.

Regards,

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this