Jump to content
  • Advertisement

Archived

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

Shriek

Rendering scene from within a child window procedure?

This topic is 6026 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

Hello, All the windows based OpenGL programs I''ve seen call the scene rendering routine from the WinMain message loop. This is fine if that is what is needed for the main window. Will this methodology still work if the rendering context is set for a child window? I know the scene rendering routine can be called from within WM_PAINT, but depending on the application this may bot be desired. Another way would be to set an WIN32 API based timer, although this would be the least desirable since a window procedure based timer can be ignored based on the messages waiting in the event queue. Here''s a scenario where the rendering methodology is important: say I have an OpenGL based modelling/animation program. Sometimes, it may only be important for the scene rendering to occur when a WM_PAINT message is received. The other time that it would important for rendering a scene as fast as possible would be when an animation viewport was being used. If animation is not needed at the time and rendering a scene happens as much as possible there would be an undesired waste of CPU cycles. So has anyone else dealt with this type of issue and come up with a solution? Thanks. -Curtiss

Share this post


Link to post
Share on other sites
Advertisement
Darn, I had to go make it more complicated than it is, especially when the solution is rather simple. A state variable is exactly what I need for this. This way I can still use WM_PAINT to render non-dynamic scenes when needed while the state variable will signify when I need animation to be done for a viewport...

-Curtiss

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!