Win32 Experts: Would this work well?
Author
For my game I''m writing (It''s a simple, but fast-paced puzzle game, must run on all Win95 or higher systems) I''m debating the way in which I should be updating the screen.
Since I need a message loop to handle all the windows messages anyway, the thought came across me: Why not use and send my own messages to my WinProc as well, to update the screen? (By using the user-defined WM_APP messages to tell me when (and where) I need to draw something.
Considering these will most likely be sent about 30 times per second (on each screen update), is it a good idea to be (ab)using the windows message pump like this?
quote:Original post by Machaira
No.
I agree. Really, really bad idea.
Use double buffering, and PeekMessage. If there''s no message, render the frame. Else process the message.
daerid: The way you suggest processes at most one message per loop, which can cause latency in the message processing pipeline.
Later,
ZE.
//email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links
Later,
ZE.
//email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links
The way you describe would work, however, if you know before hand, where and when you want to render a frame, why not just call your screen update function there instead of sending a message to the window procedure?
Freeware development:
http://www.ruinedsoft.com/
Freeware development:
http://www.ruinedsoft.com/
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
