Thread: RE: [GD-Windows] message pump problem
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-windows
|
From: Donavon K. <kei...@ea...> - 2003-11-30 19:12:33
|
Gah -- ignore me, please! Haven't had my coffee yet... didn't register
the 'else'...
> -----Original Message-----
> From: Donavon Keithley [mailto:kei...@ea...]
> Sent: Sunday, November 30, 2003 1:15 PM
> To: 'gam...@li...'
> Subject: RE: [GD-Windows] message pump problem
>
> Oh, and WRT to this:
>
> > 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
> > }
> > }
>
> What Jon was saying is that you're processing at most one message per
> frame. Not a good idea. Nothing guarantees that your app will
receive
> fewer messages per second than your frame rate and if you're counting
on
> this, you're asking for trouble.
>
> You want to pump the queue dry, then do your frame.
>
> Donavon Keithley
|
|
From: Gareth L. <GL...@cl...> - 2003-12-02 16:35:27
|
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
|
|
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
|
|
From: Gareth L. <GL...@cl...> - 2003-12-02 17:41:00
|
- 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
|
|
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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X