RE: [GD-Windows] message pump problem
Brought to you by:
vexxed72
Menu
▾
▴
RE: [GD-Windows] message pump problem
|
From: Donavon K. <kei...@ea...> - 2003-12-02 17:11:03
|
I thought I was pretty clear about the contexts in which *I* would use
this, and if you can't comment out two lines faster than you can open
another file and copy and paste some code, you must be doing something
wrong.
If nothing else, I think it's just interesting to understand how things
work, but I realize that's not for everybody.
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Gareth Lewin
> Sent: Tuesday, December 02, 2003 10:33 AM
> To: gam...@li...
> Subject: RE: [GD-Windows] message pump problem
>
> So you are recommending using a system that works and can be
explained,
> but
> has numerous drawbacks (or caveats) and is in no way simpler or
preferable
> to just copy/pasting the exact same code to a new app ?
>
> Ok....
>
> -----Original Message-----
> From: Donavon Keithley [mailto:kei...@ea...]
> Sent: 30 November 2003 19:05
> To: gam...@li...
> Subject: RE: [GD-Windows] message pump problem
>
>
> Here's a little trivia plus a trick:
>
> In addition to what Jon said, the explanation for this behavior is
that,
> unlike nearly all other messages, WM_PAINT is not queued up. Rather
the
> way it works is that, when GetMessage & PeekMessage detect that all
> queued messages have been handled, they go through the list of windows
> associated with the thread and if one is found with an invalidated
> region, they return a synthesized WM_PAINT message for it. This way
> there's no problem with paint messages stacking up and painting
doesn't
> get in the way of higher priority things. EndPaint validates the
window
> and that's why you're supposed to call it.
>
> Make sense?
>
> Now, I find this can be usefully exploited. Whenever I need a
> quick-and-dirty D3D app or whatever (and because I'm not a fan of the
> D3D app wizard code), I go through the Win32 wizard and then just
remove
> BeginPaint & EndPaint from the WM_PAINT handler and instead call my
"do
> frame" code there. Voila, no need to screw with the message pump or
> recall what PeekMessage's parameters are. The behavior is nearly
> identical to the PeekMessage loop Jon posted.
>
> There is a minor caveat: WM_TIMER is also synthesized in the same way
as
> WM_PAINT but only after all windows are validated, so you'll never see
a
> WM_TIMER message. And if you try to do this with multiple windows on
> the same thread, clearly only one of them will end up getting paint
> messages.
>
> Oh, and this behavior is actually documented. Of course it's
documented
> that you're supposed to call BeginPaint/EndPaint, so that's breaking
the
> rules. If that bothers you, you could instead call InvalidateRect
after
> EndPaint and get the same effect.
>
> Donavon Keithley
>
>
>
> > -----Original Message-----
> > From: gam...@li...
> > [mailto:gam...@li...] On Behalf
Of
> > Marin Kovacic
> > Sent: Tuesday, November 25, 2003 12:32 AM
> > To: gam...@li...
> > Subject: Re: [GD-Windows] message pump problem
> >
> > > The problem with this is that Windows expects your message proc to
> deal
> > with
> > > a number of messages in a burst and gets finicky when intervening
> "other
> > > thing" happen. I would re-structure that loop as:
> > > while( 1 ) {
> > > while( PeekMessage( PM_REMOVE ) ) {
> > > if( !IsDialogMessage() ) {
> > > TranslateMessage();
> > > DispatchMessage();
> > > }
> > > }
> > > Draw();
> > > }
> >
> > But it's essentially the same thing. I'm not executing any of the
game
> > stuff
> > while there's still messages in the queue (if I did I wouln't get
the
> > stall).
> > Note the if-else:
> >
> > while(1)
> > {
> > if (PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE))
> > {
> > GetMessage(&msg, NULL, 0, 0);
> > TranslateMessage(&msg);
> > DispatchMessage(&msg);
> > }
> > else
> > {
> > //do game frame here
> > }
> > }
> >
> > > Further, I'd set up the window proc to also call Draw() from
> WM_TIMER
> > > messages, and possibly from WM_PAINT. That's necessary if you want
> to
> > keep
> > > updating while the user is moving the window.
> >
> > I'm refreshing the frontbuffer from the WM_PAINT (not executing the
> game
> > logic).
> > I'll give WM_TIMER a bit of thought.
> >
> > > When you get WM_PAINT, you have to BeginUpdate() and EndUpdate()
> even if
> > you
> > > don't do anything else. If you don't begin/end updates, then
Windows
> > will
> > > not realize that the window has been updated, the dirty region
will
> be
> > > non-empty, and you'll get an endless stream of WM_PAINT messages.
> (Sound
> > > familiar? :-)
> >
> > Duh. Found a bug. It must have slipped in during the previous
> bug-hunting
> > session. :)
> > Check it out, it's ridiculous:
> >
> > case (WM_PAINT):
> > {
> > BeginPaint(g_focusWindow, NULL);
> > if (g_pBlitko)
> > {
> > g_pBlitko->PresentFrame();
> > return (0);
> > }
> > EndPaint(g_focusWindow, NULL);
> > return (0);
> > }break;
> >
> > Thanks for the help,
> > Marin Kovacic
> > Lemonade Productions
> > http://www.lemonade-p.com
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program.
> > Does SourceForge.net help you be more productive? Does it
> > help you create better code? SHARE THE LOVE, and help us help
> > YOU! Click Here: http://sourceforge.net/donate/
> > _______________________________________________
> > Gamedevlists-windows mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=555
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
|
