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-03 07:58:58
|
I'm not saying it's Earth-shattering or anything, it's just something
that I've found handy a number of times, usually when creating a
throwaway app. And like I said, if not calling EndPaint bothers you,
just call InvalidateRect at the end of the WM_PAINT handler -- same
behavior, perfectly legal and "right".
There's another potential advantage to this approach, which is that in
windowed mode your loop won't freeze up when the window is being dragged
or a menu is open. Unlike when using PeekMessage, keeping your
simulation alive doesn't require any additional effort. Some people
might actually want the freeze, but I generally don't care for it. I'd
rather decide for myself when to stop the action.
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Gareth Lewin
> Sent: Tuesday, December 02, 2003 11:38 AM
> To: gam...@li...
> Subject: RE: [GD-Windows] message pump problem
>
> - Understanding how it works is great (I strongly believe if that.)
> - Copy and pasting vs removing those two lines (or alternatively
inserting
> case WM_PAINT: \n break;) is shorter, but that's not the point.
>
> Anyway, I'm sorry, I didn't mean to offend, I just believe in doing
things
> right, see from my experiance thats the way to have less problems at
the
> end.
>
> -----Original Message-----
> From: Donavon Keithley [mailto:kei...@ea...]
> Sent: 02 December 2003 17:19
> To: gam...@li...
> Subject: RE: [GD-Windows] message pump problem
>
>
> 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
>
>
>
>
>
> -------------------------------------------------------
> 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
|
