gamedevlists-windows — List for discussing game development on the Windows platform

RE: [GD-Windows] Monitor aspect detection

[Nicolas R. <nic...@fr...>]

Ok...

I'm not speaking of projection matrices yet... We don't need to dig into
that right now :)
Speaking of field of views is enough.

Let say that I want a hFov of 60=B0 on a 1280x1024 mode.
We agree that vFov =3D 2*atan(height * tan(hFov/2) / width).
On a 4:3 display vFov should be 45=B0
If I only take into account the display mode vFov would be 48=B0.

This case is quite common and not really a problem... Until you need a
large hFov, for example 120=B0.
Instead of the 90=B0 you should get for vFov, you will have 96=B0.

As Jon stated, they are also perfectly pixel-square 1280x1024 LCD modes
(5:4 LCD monitors) !!!

You have four choices then:
- Live with that, and let those squares be rectangles.
- Assume user is always on a 4:3 monitor. (bye bye good old 16:9
projector).
- Remove the pesky resolutions (those not clearly 4:3, 16:9 or 3:4,...)
from user choices.
- Try to find an algorithm, working 100% in 90% of cases, and using one
of the above choices for the rest.




> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...] On=20
> Behalf Of Gareth Lewin
> Sent: Tuesday, December 09, 2003 8:00 PM
> To: gam...@li...
> Subject: RE: [GD-Windows] Monitor aspect detection
>=20
>=20
> Surely what you are describing means you have a 4x3=20
> backbuffer or projection matrix and you are rendering to a=20
> non 4x3 front buffer ?=20
>=20

RE: [GD-Windows] Win98 lockup problem

[Antonio T. L. <wil...@te...>]

Some OpenGL drivers are known to use DirectX for certain things, so don't
rule out that the something in the DirectX runtime/driver is the only to
blame for your problem.

I believe Nvidia's OpenGL driver uses directdraw to lock the frontbuffer
surface or something along those lines. On my TNT2 in Win98 there used to be
a problem where the OpenGL driver was leaking some direct3d object, so the
second time you'd run the OpenGL app it would fail to start ("ddhelp caused
an invalid page fault..."), and the only solution was to launch a DirectX
application (windows media player) *before* any OpenGL application (so the
OpenGL driver wouldn't try to deinitialize DirectX at app's end, because it
was already running when the app started).

Did you try the OpenGL renderer on an ATI card as well? (I don't know if
they use DirectX in their OpenGL driver :? ).

Regarding debugging it, you could be lucky and it could be the DirectX
runtime waiting for some unsignalled object, but if as you say the whole
system locks up, I'm afraid you are stuck somewhere in the driver or kernel
layers (I would bet some spinning loop in the DirectX kernel layer or the
Win16 semaphore). I think that SoftIce is your only way to go (and tons of
patience).

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Daniel Vogel
> Sent: Tuesday, December 09, 2003 11:28 AM
> To: gam...@li...
> Subject: [GD-Windows] Win98 lockup problem
> 
> I'm seeing a problem here where most though not all Win98/ME machines will
> cause the system to lock up after trying to run another D3D app after
> Unreal
> Tournament 2004 exits. The bug is on both ATI and NVIDIA and happens with
> both DirectX 8.1 and 9.0b but doesn't happen with e.g. Unreal Tournament
> 2003. I tried running killhelp.exe (which no longer seems to be part of
> the
> DirectX 9 SDK) without success - is it supposed to work on a machine with
> DirectX 9.0b installed? What is interesting is that D3D apps will also
> crash
> if I start the game with the OpenGL renderer but not if I pick the
> software
> renderer. This means both the OpenGL and D3D renderer must do something
> that
> leaves the machine in an unstable state though I can't figure out what.
> 
> Remotely stepping through the code the app terminates (without a trace and
> without locking up) in Direct3DCreate8 on second run with the D3D renderer
> and locks in ChangeDisplaySettings with the OpenGL one.
> 
> Anyone got any experience tracking down a problem like this? Luckily Win2k
> was already around when I made the switch from Linux game development to
> Windows so I'm not too familiar with all the idiosyncrasies of Win98 :)
> 
> -- Daniel, Epic Games Inc.
> 
> 
> 
> -------------------------------------------------------
> 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_idU5

RE: [GD-Windows] Win98 lockup problem

[Jon W. <hp...@mi...>]

You can get remote (serial) debugging working using the RTERM.EXE executable
and the DEBUGGER.EXE serial debugger nub on the target machine. More details
in the Win98/ME DDK, which you can still get from Microsoft's DDK download
site, although it's not supported. There has been one or two similar
problems that I've actually gotten to the bottom of using these tools, but
they're rather more frustrating to use than their NT equivalents (WinDBG
and, on XP, FireWire remote debugging).

What we've found is that automatic resource clean-up doesn't happen on Win98
the same way as it happens on WinXP. Terminating processes will not close
file descriptors and release handles in a way that'll let the drivers clean
up correctly. We've had to instruct our QA to reboot DOS-based Windows after
they've seen one crash. We also had to track resources (handles, contexts,
bitmaps, etc) in the program and clean all of them up in atexit() in order
to be able to re-launch on DOS-based Windows. It really is a PITA.

Cheers,

			/ h+


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Daniel Vogel
Sent: Tuesday, December 09, 2003 11:28 AM
To: gam...@li...
Subject: [GD-Windows] Win98 lockup problem


I'm seeing a problem here where most though not all Win98/ME machines will
cause the system to lock up after trying to run another D3D app after Unreal
Tournament 2004 exits. The bug is on both ATI and NVIDIA and happens with
both DirectX 8.1 and 9.0b but doesn't happen with e.g. Unreal Tournament
2003. I tried running killhelp.exe (which no longer seems to be part of the
DirectX 9 SDK) without success - is it supposed to work on a machine with
DirectX 9.0b installed? What is interesting is that D3D apps will also crash
if I start the game with the OpenGL renderer but not if I pick the software
renderer. This means both the OpenGL and D3D renderer must do something that
leaves the machine in an unstable state though I can't figure out what.

Remotely stepping through the code the app terminates (without a trace and
without locking up) in Direct3DCreate8 on second run with the D3D renderer
and locks in ChangeDisplaySettings with the OpenGL one.

Anyone got any experience tracking down a problem like this? Luckily Win2k
was already around when I made the switch from Linux game development to
Windows so I'm not too familiar with all the idiosyncrasies of Win98 :)

-- Daniel, Epic Games Inc.



-------------------------------------------------------
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_idU5

[GD-Windows] Win98 lockup problem

[Daniel V. <vo...@ep...>]

I'm seeing a problem here where most though not all Win98/ME machines =
will
cause the system to lock up after trying to run another D3D app after =
Unreal
Tournament 2004 exits. The bug is on both ATI and NVIDIA and happens =
with
both DirectX 8.1 and 9.0b but doesn't happen with e.g. Unreal Tournament
2003. I tried running killhelp.exe (which no longer seems to be part of =
the
DirectX 9 SDK) without success - is it supposed to work on a machine =
with
DirectX 9.0b installed? What is interesting is that D3D apps will also =
crash
if I start the game with the OpenGL renderer but not if I pick the =
software
renderer. This means both the OpenGL and D3D renderer must do something =
that
leaves the machine in an unstable state though I can't figure out what.

Remotely stepping through the code the app terminates (without a trace =
and
without locking up) in Direct3DCreate8 on second run with the D3D =
renderer
and locks in ChangeDisplaySettings with the OpenGL one.

Anyone got any experience tracking down a problem like this? Luckily =
Win2k
was already around when I made the switch from Linux game development to
Windows so I'm not too familiar with all the idiosyncrasies of Win98 :)

-- Daniel, Epic Games Inc.

RE: [GD-Windows] Monitor aspect detection

[Gareth L. <GL...@cl...>]

Surely what you are describing means you have a 4x3 backbuffer or projection
matrix and you are rendering to a non 4x3 front buffer ? 

> -----Original Message-----
> From: Nicolas Romantzoff [mailto:nic...@fr...]
> Sent: 09 December 2003 17:50
> To: gam...@li...
> Subject: RE: [GD-Windows] Monitor aspect detection
> 
> 
> Hi,
> 
> Well, frankly not really an obsession, but had a bug-report on
> point-lights lighting not being spherical. In fact, the lighting was
> making a ellipsoid mark instead of a circular one. Trust me, this was
> really obvious, and the only reason was the 1280x1024 resolution.
> 
> I know some games do "remove" those resolutions, and propose the
> 1280x960 instead, but never found that removing options from the user
> was a nice way of correcting "bugs".
> 
> The other reason for that is handling the "new" features of some LCD
> monitors being put vertically instead of horizontally. This could have
> been patched by simply comparing width and height, but that's a very
> unnatural ugly way of doing it ! :)
> 
> Nicolas.
> 
> 
> > -----Original Message-----
> > 
> > I'm quite curious why this obsession, though: is it just to 
> > get it "right" or is there some virtual/physical match-up 
> > issue involved? Could you go the other way, and ask that the 
> > user adjusts his/her monitor so that the pixels are square? 
> > Perhaps ship a ruler in the box?
> > 
> > Cheers,
> > 
> > 			/ h+
> 
> 
> 
> -------------------------------------------------------
> 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
> 

RE: [GD-Windows] Monitor aspect detection

[Nicolas R. <nic...@fr...>]

Hi,

Well, frankly not really an obsession, but had a bug-report on
point-lights lighting not being spherical. In fact, the lighting was
making a ellipsoid mark instead of a circular one. Trust me, this was
really obvious, and the only reason was the 1280x1024 resolution.

I know some games do "remove" those resolutions, and propose the
1280x960 instead, but never found that removing options from the user
was a nice way of correcting "bugs".

The other reason for that is handling the "new" features of some LCD
monitors being put vertically instead of horizontally. This could have
been patched by simply comparing width and height, but that's a very
unnatural ugly way of doing it ! :)

Nicolas.


> -----Original Message-----
> 
> I'm quite curious why this obsession, though: is it just to 
> get it "right" or is there some virtual/physical match-up 
> issue involved? Could you go the other way, and ask that the 
> user adjusts his/her monitor so that the pixels are square? 
> Perhaps ship a ruler in the box?
> 
> Cheers,
> 
> 			/ h+

RE: [GD-Windows] Monitor aspect detection

[Phil T. <ph...@mi...>]

I think these are only going to work if the monitor is correctly
identified (i.e. through plug-n-play); otherwise, if the monitors are
using the generic drivers/settings there is no way for GDI to return the
real information.

Phil

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Nicolas Romantzoff
Sent: Tuesday, December 09, 2003 9:43 AM
To: gam...@li...
Subject: RE: [GD-Windows] Monitor aspect detection

Hi !

Thanks for reminding me that GDI function !

Had already looked into it, alas ASPECTX and ASPECTY always returned
identical values whatever mode was selected, and whatever monitor I was
using. Looks like ASPECTX=3DASPECTY for screen ! (btw, never understood
the "meaning" of ASPECTXY... But who cares).

Gave it another try today, but this time using the "HORZSIZE" and
"VERTSIZE" I completely missed the first time... And those seem to work
!
So... Using the current mode resolution and those HORZSIZE/VERTSIZE
values, I've finally been able to compute a correct aspect whatever the
mode is (at least on my machine). Still have to try it on some weird
LCDs and settings, but hope is back !


Thanks everyone !

Nicolas


> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...] On=20
> Behalf Of brian sharon
> Sent: Tuesday, December 09, 2003 4:11 PM
> To: gam...@li...
> Subject: Re: [GD-Windows] Monitor aspect detection
>=20
>=20
> Does GetDeviceCaps() give you a clue about whether pixels are=20
> square? =20
> I'm thinking specifically of the ASPECTX and ASPECTY arguments.
>=20
> --brian
>=20
>=20



-------------------------------------------------------
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=3D555

RE: [GD-Windows] Monitor aspect detection

[Nicolas R. <nic...@fr...>]

Hi !

Thanks for reminding me that GDI function !

Had already looked into it, alas ASPECTX and ASPECTY always returned
identical values whatever mode was selected, and whatever monitor I was
using. Looks like ASPECTX=ASPECTY for screen ! (btw, never understood
the "meaning" of ASPECTXY... But who cares).

Gave it another try today, but this time using the "HORZSIZE" and
"VERTSIZE" I completely missed the first time... And those seem to work
!
So... Using the current mode resolution and those HORZSIZE/VERTSIZE
values, I've finally been able to compute a correct aspect whatever the
mode is (at least on my machine). Still have to try it on some weird
LCDs and settings, but hope is back !


Thanks everyone !

Nicolas


> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of brian sharon
> Sent: Tuesday, December 09, 2003 4:11 PM
> To: gam...@li...
> Subject: Re: [GD-Windows] Monitor aspect detection
> 
> 
> Does GetDeviceCaps() give you a clue about whether pixels are 
> square?  
> I'm thinking specifically of the ASPECTX and ASPECTY arguments.
> 
> --brian
> 
> 

RE: [GD-Windows] Monitor aspect detection

[Jon W. <hp...@mi...>]

There are a number of 16:10 or thereabouts monitors (1600x1024, for
example).

I think you're just screwed (that's a technical term). Again, the user has
full control over pixel aspect ratio by adjusting their monitor. You have to
assume that the user has adjusted the monitor to be square-pixeled during
everyday work. And if they haven't, that they like the other-aspect they've
set up for themselves.

The best I think you can do is assume that the mode that the monitor is in
when the user starts the program (which is NOT necessarily the "highest"
mode) is one that has square pixels. The aspect ratios that you could get
out of Windows haven't ever been useful to me (even back in the HGA/GCA days
where pixels weren't even intended to be square :-).

I'm quite curious why this obsession, though: is it just to get it "right"
or is there some virtual/physical match-up issue involved? Could you go the
other way, and ask that the user adjusts his/her monitor so that the pixels
are square? Perhaps ship a ruler in the box?

Cheers,

			/ h+

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Nicolas Romantzoff
Sent: Tuesday, December 09, 2003 3:01 AM
To: gam...@li...
Subject: RE: [GD-Windows] Monitor aspect detection


Highest resolution width: 1920
Highest resolution height: 1200
Resulting "ratio": 8:5
Closest "well-known" ratio: 16:9
Resolution matching that ratio: 1920x1080 => Monitor detected as a 16:9
monitor !

Re: [GD-Windows] Monitor aspect detection

[brian s. <pud...@po...>]

Does GetDeviceCaps() give you a clue about whether pixels are square?  
I'm thinking specifically of the ASPECTX and ASPECTY arguments.

--brian

On Tuesday, December 9, 2003, at 03:00  AM, Nicolas Romantzoff wrote:

> Thanks Jon for the feedback...
>
> Getting the "maximum resolution" for width/height and using this as the
> base aspect ratio (guessing the monitor do have square pixels) is what
> I'm currently doing... And it seems to work fine on most CRTs, but for
> my wife's computer. Sticked to a 1280x1024 heighest resolution (desktop
> also in that resolution), this algorithm detects a ... 5:4 monitor.
>
> Other problem I came across was with a vertically positioned LCD (and
> the funny thing is: a 1280x1024 vertically positioned 4:3 monitor).
> Under that config, I detect a 4:5 monitor (I have no clue the monitor
> has been positioned vertically).
>
> Final problem I already found: weird resolution LCDs. Things like
> 1300x1060.
>
> One solution could have been to:
> - Enumerate modes and compute a monitor-ratio based on highest width /
> highest height displayable.
> - Select the closest "well-known" format matching that ratio (4:3, 
> 16:9,
> 3:4...) [if identical, stop here].
> - Enumerate modes and find the closest mode to "1:1" pixel-ratio for
> that fixed monitor-ratio.
> - Use that mode to compute the final monitor ratio.
>
> I'm currently using the first step only.
> Adding the second step would solve trivial 1280x1024 best resolution
> problems.
> Adding the last 2 steps would solves strange resolution monitor 
> problems
> some LCDs do have.
>
> Unfortunately, here is the configuration I'm currently using: ViewSonic
> P95f + GeForce 3.
> Highest resolution width: 1920
> Highest resolution height: 1200
> Resulting "ratio": 8:5
> Closest "well-known" ratio: 16:9
> Resolution matching that ratio: 1920x1080 => Monitor detected as a 16:9
> monitor !
>
>
> With different drivers:
> Highest resolution width: 1920
> Highest resolution height: 1440
> Resulting "ratio": 4:3
> (though 1920x1080 and 1920x1200 resolutions still present).
>
>
> I could select the well-known ratio by limiting myself to "lower" 
> ratios
> only (giving me a 4:3 format for the first case), but I fear that on
> some configs, the highest resolution would be 1920x1080 and back to a
> wrong 16:9 detection.
>
>
> Nicolas.
>
>
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Jon Watte
> Sent: Tuesday, December 09, 2003 1:11 AM
> To: gam...@li...
> Subject: RE: [GD-Windows] (no subject)
>
>
> To make things exciting, many LCD 1280x1024 monitors have square 
> pixels.
>
> I'd go with the assumption that monitors do have square pixels, and 
> thus
> the view ratio == resolution ratio. Then supply a "special" option to
> compensate for the known oddball cases, of which 1280x1024 on a 4x3
> monitor is the only obvious one.
>
> Well, there's the case of 800x600 being blown up to fullscreen on a 
> 16:9
> display, too, and stretching like mad. There's no good way of finding
> this out. The best you can do is capture the resolution at start-up,
> before mode switch, and assume it's square.

RE: [GD-Windows] Monitor aspect detection

[Nicolas R. <nic...@fr...>]

Thanks Jon for the feedback...

Getting the "maximum resolution" for width/height and using this as the
base aspect ratio (guessing the monitor do have square pixels) is what
I'm currently doing... And it seems to work fine on most CRTs, but for
my wife's computer. Sticked to a 1280x1024 heighest resolution (desktop
also in that resolution), this algorithm detects a ... 5:4 monitor.

Other problem I came across was with a vertically positioned LCD (and
the funny thing is: a 1280x1024 vertically positioned 4:3 monitor).
Under that config, I detect a 4:5 monitor (I have no clue the monitor
has been positioned vertically).

Final problem I already found: weird resolution LCDs. Things like
1300x1060.

One solution could have been to:
- Enumerate modes and compute a monitor-ratio based on highest width /
highest height displayable.
- Select the closest "well-known" format matching that ratio (4:3, 16:9,
3:4...) [if identical, stop here].
- Enumerate modes and find the closest mode to "1:1" pixel-ratio for
that fixed monitor-ratio.
- Use that mode to compute the final monitor ratio.

I'm currently using the first step only.
Adding the second step would solve trivial 1280x1024 best resolution
problems.
Adding the last 2 steps would solves strange resolution monitor problems
some LCDs do have.

Unfortunately, here is the configuration I'm currently using: ViewSonic
P95f + GeForce 3.
Highest resolution width: 1920
Highest resolution height: 1200
Resulting "ratio": 8:5
Closest "well-known" ratio: 16:9
Resolution matching that ratio: 1920x1080 => Monitor detected as a 16:9
monitor !


With different drivers:
Highest resolution width: 1920
Highest resolution height: 1440
Resulting "ratio": 4:3
(though 1920x1080 and 1920x1200 resolutions still present).


I could select the well-known ratio by limiting myself to "lower" ratios
only (giving me a 4:3 format for the first case), but I fear that on
some configs, the highest resolution would be 1920x1080 and back to a
wrong 16:9 detection.


Nicolas.


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Jon Watte
Sent: Tuesday, December 09, 2003 1:11 AM
To: gam...@li...
Subject: RE: [GD-Windows] (no subject)


To make things exciting, many LCD 1280x1024 monitors have square pixels.

I'd go with the assumption that monitors do have square pixels, and thus
the view ratio == resolution ratio. Then supply a "special" option to
compensate for the known oddball cases, of which 1280x1024 on a 4x3
monitor is the only obvious one.

Well, there's the case of 800x600 being blown up to fullscreen on a 16:9
display, too, and stretching like mad. There's no good way of finding
this out. The best you can do is capture the resolution at start-up,
before mode switch, and assume it's square.

RE: [GD-Windows] (no subject)

[Jon W. <hp...@mi...>]

Message
To make things exciting, many LCD 1280x1024 monitors have square pixels.

I'd go with the assumption that monitors do have square pixels, and thus the
view ratio == resolution ratio. Then supply a "special" option to compensate
for the known oddball cases, of which 1280x1024 on a 4x3 monitor is the only
obvious one.

Well, there's the case of 800x600 being blown up to fullscreen on a 16:9
display, too, and stretching like mad. There's no good way of finding this
out. The best you can do is capture the resolution at start-up, before mode
switch, and assume it's square.

Note that most CRT monitors have separate width/height adjustment for the
image, so individual users may have a different adjustment, too.

Cheers,

                / h+

  -----Original Message-----
  From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Nicolas Romantzoff
  Sent: Monday, December 08, 2003 3:58 PM
  To: Gamedevlists-Windows@Lists. Sourceforge. Net
  Subject: [GD-Windows] (no subject)


  Hi,

  I'm looking for a way of "detecting" the pixel-aspect under a given mode.

  My first idea was to first detect the monitor's aspect, and then multiply
that with (mode's height / mode's width). Alas, couldn't find any way to
retrieve that monitor's aspect.

  I need that information to adapt cameras field of views between different
(yet well-known) resolutions like 1280x1024, which is absolutely not a
square pixel on a 4:3 monitor, and 800x600, which is perfectly square. And i
will flame anyone answering difference is not visible ! :)))

  It becomes extremely important now, with some monitors (especially latest
LCDs), allowing to be positioned "vertically" (3:4 monitors), or with weird
resolutions (832x702).

  If anyone could be of a help on that, i would really appreciate !

  __________________________________________________________________
  Nicolas Romantzoff
  ICQ#: 1182420
        Current ICQ status:
  +  More ways to contact me
  __________________________________________________________________




  ---
  Outgoing mail is certified Virus Free.
  Checked by AVG anti-virus system (http://www.grisoft.com).
  Version: 6.0.547 / Virus Database: 340 - Release Date: 02/12/2003

[GD-Windows] Monitor aspect detection

[Nicolas R. <nic...@fr...>]

Hi,

First, let me apologize for the missed "send" of this e-mail, HTML + no
subject... Everything I hate ! :(((


 
I'm looking for a way of "detecting" the pixel-aspect under a given
mode.
 
My first idea was to first detect the monitor's aspect, and then
multiply that with (mode's height / mode's width). Alas, couldn't find
any way to retrieve that monitor's aspect.
 
I need that information to adapt cameras field of views between
different (yet well-known) resolutions like 1280x1024, which is
absolutely not a square pixel on a 4:3 monitor, and 800x600, which is
perfectly square. And i will flame anyone answering difference is not
visible ! :)))
 
It becomes extremely important now, with some monitors (especially
latest LCDs), allowing to be positioned "vertically" (3:4 monitors), or
with weird resolutions (832x702).
 
If anyone could be of a help on that, i would really appreciate !
 


Nicolas Romantzoff

RE: [GD-Windows] Handlig Form/Control messages in Windows Forms without ::WndProc(Message *); method

[Jon W. <hp...@mi...>]

I see no reason subclassing shouldn't be fine, but I also haven't done it in
the specific situation you're mentioning.

Try it and let us know what happens :-)

Cheers,

			/ h+


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Jacobo Rodriguez
Sent: Thursday, December 04, 2003 8:07 AM
To: Gam...@li...
Subject: [GD-Windows] Handlig Form/Control messages in Windows Forms
without ::WndProc(Message *); method


Hello, this is mi first post here, and my english aren't too good, so
please forgive my mistakes :)
I need to work with the window messages of a control (Form, Button, etc)
in Windows Forms, of the .NET framework, and, by design reasons, i can't
use ::WndProc(Message *m);  .Can i subclass the Form
(SetWindowLong(hWnd, GWL_WNDPROC, (LONG)MyNewWndProc); ) without danger?
if not, how could i handle the incoming messages to the form/control
before they reach to ::WndProc ?
Thank You.




-------------------------------------------------------
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

[GD-Windows] Handlig Form/Control messages in Windows Forms without ::WndProc(Message *); method

[Jacobo R. <ffe...@ty...>]

Hello, this is mi first post here, and my english aren't too good, so 
please forgive my mistakes :)
I need to work with the window messages of a control (Form, Button, etc) 
in Windows Forms, of the .NET framework, and, by design reasons, i can't 
use ::WndProc(Message *m);  .Can i subclass the Form 
(SetWindowLong(hWnd, GWL_WNDPROC, (LONG)MyNewWndProc); ) without danger? 
if not, how could i handle the incoming messages to the form/control 
before they reach to ::WndProc ?
Thank You.

RE: [GD-Windows] VS .NET conflict with focus follows mouse

[Gareth L. <GL...@cl...>]

Essentially I guess vs.net is doing it at the low level. It's probably doing
it because apps with lots of child windows that are not really child windows
(like vs.net does) has problems with activating a window and the app not
bringing everything to the front.

Unfortunately I know the cause, but I can't recommend a solution :(

-----Original Message-----
From: Dan Glastonbury [mailto:dgl...@pi...]
Sent: 04 December 2003 10:08
To: gam...@li...
Subject: [GD-Windows] VS .NET conflict with focus follows mouse


G'Day,
   Coming from X Windows in my deep, dark days, I'm fond of having focus 
follow mouse.  This way I can overlap windows, reading something from one 
window, whilst typing in another.  But with this feature enabled, VS .NET 
automatically raises to the top of the window stack as soon as the cursor is

over the VS .NET window.  I have the auto raise turned off, and VS .NET is
the 
only app that does it.

Does anyone know how to turn this feature off?  (Is there some registry key
I 
can modify?)

thanks
DanG



-------------------------------------------------------
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

[GD-Windows] VS .NET conflict with focus follows mouse

[Dan G. <dgl...@pi...>]

G'Day,
   Coming from X Windows in my deep, dark days, I'm fond of having focus 
follow mouse.  This way I can overlap windows, reading something from one 
window, whilst typing in another.  But with this feature enabled, VS .NET 
automatically raises to the top of the window stack as soon as the cursor is 
over the VS .NET window.  I have the auto raise turned off, and VS .NET is the 
only app that does it.

Does anyone know how to turn this feature off?  (Is there some registry key I 
can modify?)

thanks
DanG

RE: [GD-Windows] message pump problem

[Donavon K. <kei...@ea...>]

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

RE: [GD-Windows] message pump problem

[Gareth L. <GL...@cl...>]

- 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

Re: [GD-Windows] message pump problem

[Marin K. <m.k...@in...>]

> 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?

Yeah, it makes perfect sense now that I've accustomed to the idea.
It was all jibberish while I was reading about it in the MSDN. :-)

-- 
Marin Kovacic
Lemonade Productions
http://www.lemonade-p.com

RE: [GD-Windows] message pump problem

[Donavon K. <kei...@ea...>]

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

RE: [GD-Windows] message pump problem

[Gareth L. <GL...@cl...>]

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

RE: [GD-Windows] message pump problem

[Donavon K. <kei...@ea...>]

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

RE: [GD-Windows] message pump problem

[Donavon K. <kei...@ea...>]

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

RE: [GD-Windows] message pump problem

[Donavon K. <kei...@ea...>]

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