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

Re: [GD-Windows] More timer fun!

[Pierre T. <p.t...@wa...>]

Somebody should write a definitive Gem about this (say in GPG 4 ?). Or maybe
someone already has and I don't know about it ? Is there a place explaining
the issues and, hopefully, giving canonical source code to solve them once
and for all ?

Pierre

----- Original Message -----
From: Jon Watte <hp...@mi...>
To: <bri...@py...>; <gam...@li...>
Sent: Friday, August 30, 2002 6:51 AM
Subject: RE: [GD-Windows] More timer fun!


>
> timGetTime() / GetTickCount() only return 32 bit values, AFAIK.
>
> There are some problems with keeping time on PC hardware. timeGetTime()
> will lag behind wallclock time when there is lots of bus traffic (==
> graphics-heavy application running). QueryPerformanceCounter() will
> somtimes jump ahead by 1.3 or 4.1 seconds when there is lots of bus
> traffic, in a quantum leap. RDTSC ticks once per cycle, but mobile
> CPUs will adjust their CPU frequency quite often, so you can't get a
> good bead on that, either.
>
> Also, QPC and TGT/GTC each take a bus transaction to execute, and thus
> run in 1-2 microseconds, which is an eternity if you need to call them
> more than once or twice per frame rendered.
>
> I ended up with an unholy concoction of all three methods, which ends
> up getting good overall relation to wallclock time, cheap calls, but
> some local mis-match where my clock will lag behind wall-clock "locally"
> but get adjusted "globally" when the CPU goes into powersave mode.
>
> Yuck.
>
> Cheers,
>
> / h+

RE: [GD-Windows] More timer fun!

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

Not only will QPC sometimes jump ahead by one to four seconds because of
bus traffic, on some processors due to a known manufacturing defect QPC
can actually jump backwards and forwards in time significantly.  As far
as I know this only happens on a small percentage of manufactured CPUs
(I have observed it at least once on a P3).

This has bitten me in the past.  For example one of the programs I
debugged had logic that looked something like this:

	// start timer:

	__int64 freq;
	QueryPerformanceFrequency(&freq);
	__int64 start =3D QueryPerformanceCounter();
=09

	// once a frame:

	if (QueryPerformanceCounter() - start > freq)
	{
		// change a state
	}

Basically someone was waiting for a second to elapse before moving on in
a state.


The program in question was "hung" in a menu waiting to continue.  When
I hooked up a debugger to this it turned out that QPC would reset (jump
backwards) every 6 minutes.  The reset just happened to be between the
initial call to QPC and before the one second could elapse.

Painful indeed,
Phil

-----Original Message-----
From: Jon Watte [mailto:hp...@mi...]=20
Sent: Thursday, August 29, 2002 9:51 PM
To: bri...@py...; gam...@li...
Subject: RE: [GD-Windows] More timer fun!


timGetTime() / GetTickCount() only return 32 bit values, AFAIK.

There are some problems with keeping time on PC hardware. timeGetTime()=20
will lag behind wallclock time when there is lots of bus traffic (=3D=3D =

graphics-heavy application running). QueryPerformanceCounter() will=20
somtimes jump ahead by 1.3 or 4.1 seconds when there is lots of bus=20
traffic, in a quantum leap. RDTSC ticks once per cycle, but mobile=20
CPUs will adjust their CPU frequency quite often, so you can't get a=20
good bead on that, either.

Also, QPC and TGT/GTC each take a bus transaction to execute, and thus=20
run in 1-2 microseconds, which is an eternity if you need to call them=20
more than once or twice per frame rendered.

I ended up with an unholy concoction of all three methods, which ends=20
up getting good overall relation to wallclock time, cheap calls, but=20
some local mis-match where my clock will lag behind wall-clock "locally"

but get adjusted "globally" when the CPU goes into powersave mode.

Yuck.

Cheers,

			/ h+


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> brian hook
> Sent: Thursday, August 29, 2002 9:40 PM
> To: gam...@li...
> Subject: [GD-Windows] More timer fun!
>=20
>=20
> Well, in the process of trying to figure out why on a very few systems

> (maybe less than 1%) my timing code was messed up, I stumbled across=20
> this tid bit at the Pest Patrol Web site:
>=20
> "A Range Check Error can occur on DELL computers running Windows ME=20
> with software using the Windows function GetTickCount. In such
systems,=20
> this function is not returning the elapsed time since system power on,

> and the value returned can be enormous, causing a range check error.=20
> Dell's Range Check Error affects timeGetTime as well as GetTickCount.
A=20
> third timing function, therefore, has been used in PestPatrol,=20
> PestPatrolCL, and PPUpdater."
>=20
> Well, sure enough, the two users I know that were having this problem=20
> have Dell Dimension L's with Windows ME.  I'm not sure what the=20
> specifics of this problem are (I'm using 64-bit ints already), but I
do=20
> some more range checking now and hopefully this problem goes away.
>=20
> -Hook
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D555
>=20


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
_______________________________________________
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] More timer fun!

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

> The Dell problem seems to be that the time reported isn't since system
> boot, but instead some arbitrarily high number, maybe out of the BIOS
> with battery backup.

The 32 bit value will wrap around once every 4 billion milliseconds. Could
you be seeing that? If the number starts arbitrarily high, then the up time
won't need to go to a month and a half to actually reach this point...

Cheers,

			/ h+

RE: [GD-Windows] More timer fun!

[brian h. <bri...@py...>]

> I guess it's possible that sign extension from a 64-bit integer back 
> down to a 32-bit integer could cause the problem, but I've looked 
over 
> my code and basically it's all in 64-bit integers, with no funny 
> casting or anything like that once timeGetTime() returns.

Bzzzzt, there WAS one tiny, itty bitty bit of funny casting after all 
=) So while the Dell stuff operates "unexpectedly", it basically just 
manifested a bug in my code:

int delta = ( int ) ( timeGetTime() - last_time );

//Do some stuff that assumes that "delta" is always > 0


Everything is fine, until timeGetTime() - last_time becomes some very 
large number because, say, last_time is set to 0 (*cough*), at which 
point everything explodes because delta is < 0 and that's not something 
my code expected to ever see.

Learn something new every day =)

Brian

RE: [GD-Windows] More timer fun!

[brian h. <bri...@py...>]

> timGetTime() / GetTickCount() only return 32 bit values, AFAIK.

You're right, DWORD...and that might be my problem right there.

The Dell problem seems to be that the time reported isn't since system 
boot, but instead some arbitrarily high number, maybe out of the BIOS 
with battery backup.

Hmmm, I was thinking sign extension might cause my bug, but that 
doesn't seem to be the case -- DWORD won't sign extend into a 64-bit 
value.

I guess it's possible that sign extension from a 64-bit integer back 
down to a 32-bit integer could cause the problem, but I've looked over 
my code and basically it's all in 64-bit integers, with no funny 
casting or anything like that once timeGetTime() returns.

Hmmmm.

> There are some problems with keeping time on PC hardware.

That would be one of the larger understatements I've seen =\

Brian

RE: [GD-Windows] More timer fun!

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

timGetTime() / GetTickCount() only return 32 bit values, AFAIK.

There are some problems with keeping time on PC hardware. timeGetTime() 
will lag behind wallclock time when there is lots of bus traffic (== 
graphics-heavy application running). QueryPerformanceCounter() will 
somtimes jump ahead by 1.3 or 4.1 seconds when there is lots of bus 
traffic, in a quantum leap. RDTSC ticks once per cycle, but mobile 
CPUs will adjust their CPU frequency quite often, so you can't get a 
good bead on that, either.

Also, QPC and TGT/GTC each take a bus transaction to execute, and thus 
run in 1-2 microseconds, which is an eternity if you need to call them 
more than once or twice per frame rendered.

I ended up with an unholy concoction of all three methods, which ends 
up getting good overall relation to wallclock time, cheap calls, but 
some local mis-match where my clock will lag behind wall-clock "locally" 
but get adjusted "globally" when the CPU goes into powersave mode.

Yuck.

Cheers,

			/ h+


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> brian hook
> Sent: Thursday, August 29, 2002 9:40 PM
> To: gam...@li...
> Subject: [GD-Windows] More timer fun!
> 
> 
> Well, in the process of trying to figure out why on a very few systems 
> (maybe less than 1%) my timing code was messed up, I stumbled across 
> this tid bit at the Pest Patrol Web site:
> 
> "A Range Check Error can occur on DELL computers running Windows ME 
> with software using the Windows function GetTickCount. In such systems, 
> this function is not returning the elapsed time since system power on, 
> and the value returned can be enormous, causing a range check error. 
> Dell's Range Check Error affects timeGetTime as well as GetTickCount. A 
> third timing function, therefore, has been used in PestPatrol, 
> PestPatrolCL, and PPUpdater."
> 
> Well, sure enough, the two users I know that were having this problem 
> have Dell Dimension L's with Windows ME.  I'm not sure what the 
> specifics of this problem are (I'm using 64-bit ints already), but I do 
> some more range checking now and hopefully this problem goes away.
> 
> -Hook
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> 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] More timer fun!

[brian h. <bri...@py...>]

Well, in the process of trying to figure out why on a very few systems 
(maybe less than 1%) my timing code was messed up, I stumbled across 
this tid bit at the Pest Patrol Web site:

"A Range Check Error can occur on DELL computers running Windows ME 
with software using the Windows function GetTickCount. In such systems, 
this function is not returning the elapsed time since system power on, 
and the value returned can be enormous, causing a range check error. 
Dell's Range Check Error affects timeGetTime as well as GetTickCount. A 
third timing function, therefore, has been used in PestPatrol, 
PestPatrolCL, and PPUpdater."

Well, sure enough, the two users I know that were having this problem 
have Dell Dimension L's with Windows ME.  I'm not sure what the 
specifics of this problem are (I'm using 64-bit ints already), but I do 
some more range checking now and hopefully this problem goes away.

-Hook

RE: [GD-Windows] Process hanging inside ExitProcess()

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

If this happens on Win2k or WinXP, I would heartily recommend trying to
debug this with WinDBG (which is available as a free download as part of
the Windows 2000 DDK, and part of MSDN in the Windows DDK).

Cheers,

				/ h+


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Javier Arevalo
> Sent: Thursday, August 29, 2002 3:17 AM
> To: GDWindows
> Subject: [GD-Windows] Process hanging inside ExitProcess()
>
>
> Hi!
>
> We currently have this annoying bug where, every few days, the game hangs
> when quitting, inside CRT's call to ExitProcess() with one (sometimes two)
> additional threads running. Of course, it only hangs in our retail builds,
> without our helpful debug logs. When we try to break into the debugger, it
> dumps the following message to the debug output:
>
> DBG: Break command failed within 3 seconds.
> DBG: Potential deadlock. Soft broken.
>
> The usual suspect is the multithreaded sound DLL, since the only reason
> ExitProcess() might hang seems to be while waiting for DLLs to detach. We
> use the undocumented MSVC++ 6 trick for assigning names to threads (cool!)
> so we can identify those in the debugger, but when we get this particular
> deadlock, MSVC++ seems to "forget" the names, and stack traces only show a
> couple levels inside KERNEL32, none of our user code. Thus we are not sure
> which DLLs and/or threads are causing this deadlock.
>
> Anybody has suggestions that can be helpful for debugging and/or solving
> this problem?
>
> Thanks in advance,
>   Javier Arevalo
>   Pyro Studios
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> 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] Process hanging inside ExitProcess()

[Javier A. <ja...@py...>]

David Notario <dno...@mi...> wrote:

> The thing I would recommend is using a debugger like windbg or cdb.

I feared you would say that. :) I guess it's a good time to install the
Win2K symbols too... I'm downloading the whole Customer Support Pack at
http://www.microsoft.com/Windows2000/downloads/tools/symbols/download.asp

With some luck I'll catch you sometime when this happens. Thanks!

  Javier Arevalo
  Pyro Studios

RE: [GD-Windows] Process hanging inside ExitProcess()

[David N. <dno...@mi...>]

VGhlIHRoaW5nIEkgd291bGQgcmVjb21tZW5kIGlzIHVzaW5nIGEgZGVidWdnZXIgbGlrZSB3aW5k
Ymcgb3IgY2RiLiBZb3UgY2FuIGRvd25sb2FkIGl0IGZyb206DQogDQpodHRwOi8vd3d3Lm1pY3Jv
c29mdC5jb20vZGRrL2RlYnVnZ2luZy9pbnN0YWxseDg2LmFzcA0KIA0KVGhlc2UgZGVidWdnZXJz
IHdpbGwgbGV0IHlvdSBleGFtaW5lIGludGVybmFsIHdpbmRvd3Mgc3RydWN0dXJlcy4gVGhpcyB3
aWxsIGxldCB5b3UgbGVhcm4gdmVyeSBxdWlja2x5IG9uIHdoaWNoIHRocmVhZCB5b3UncmUgaGFu
Z2luZy4gQmFzaWNhbGx5LCB5b3UncmUgcHJvYmFibHkgaW4gc29tZSBXYWl0WFhYT2JqZWN0IGZ1
bmN0aW9uIGFuZCB5b3Ugd2lsbCB3YW50IHRvIGV4YW1pbmUgdGhhdCBPYmplY3QgdG8gc2VlIG9u
IHdoYXQgdGhyZWFkIGl0J3Mgd2FpdGluZy4gVGhpcyBpcyBlYXN5IHRvIGRvIGluIHdpbmRiZyAo
YXMgaXQgaGFzIGNvbW1hbmRzL2V4dGVuc2lvbnMgdG8gZGlzcGxheSB0aGVzZSBrZXJuZWwgb2Jq
ZWN0cykuIA0KIA0KV2UgZG8gYWxsIG91ciBzdHJlc3MgcnVucyB3aXRoIHRoZXNlIGRlYnVnZ2Vy
cywgdGhleSdyZSBwcmV0dHkgY3VtYmVyc29tZSBhbmQgYSBwYWluIHRvIGxlYXJuLCBidXQgYXJl
IHZlcnkgcG93ZXJmdWwsIGFuZCBhbGxvdyBhIGxvdCBvZiBjdXN0b21pemluZyBieSB3cml0aW5n
IHlvdXIgb3duIHBsdWdpbnMvY29tbWFuZHMuDQogDQpKYXZpZXIsIGNvbnRhY3QgbWUgb2ZmbGlu
ZSBpZiB5b3UgbmVlZCBoZWxwIHNldHRpbmcgdXAvdXNpbmcgd2luZGJnLg0KIA0KRGF2aWQNCg0K
CS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IEphdmllciBBcmV2YWxvIFttYWls
dG86amFyZUBweXJvc3R1ZGlvcy5jb21dIA0KCVNlbnQ6IFRodSA4LzI5LzIwMDIgMzoxNiBBTSAN
CglUbzogR0RXaW5kb3dzIA0KCUNjOiANCglTdWJqZWN0OiBbR0QtV2luZG93c10gUHJvY2VzcyBo
YW5naW5nIGluc2lkZSBFeGl0UHJvY2VzcygpDQoJDQoJDQoNCglIaSENCgkNCglXZSBjdXJyZW50
bHkgaGF2ZSB0aGlzIGFubm95aW5nIGJ1ZyB3aGVyZSwgZXZlcnkgZmV3IGRheXMsIHRoZSBnYW1l
IGhhbmdzDQoJd2hlbiBxdWl0dGluZywgaW5zaWRlIENSVCdzIGNhbGwgdG8gRXhpdFByb2Nlc3Mo
KSB3aXRoIG9uZSAoc29tZXRpbWVzIHR3bykNCglhZGRpdGlvbmFsIHRocmVhZHMgcnVubmluZy4g
T2YgY291cnNlLCBpdCBvbmx5IGhhbmdzIGluIG91ciByZXRhaWwgYnVpbGRzLA0KCXdpdGhvdXQg
b3VyIGhlbHBmdWwgZGVidWcgbG9ncy4gV2hlbiB3ZSB0cnkgdG8gYnJlYWsgaW50byB0aGUgZGVi
dWdnZXIsIGl0DQoJZHVtcHMgdGhlIGZvbGxvd2luZyBtZXNzYWdlIHRvIHRoZSBkZWJ1ZyBvdXRw
dXQ6DQoJDQoJREJHOiBCcmVhayBjb21tYW5kIGZhaWxlZCB3aXRoaW4gMyBzZWNvbmRzLg0KCURC
RzogUG90ZW50aWFsIGRlYWRsb2NrLiBTb2Z0IGJyb2tlbi4NCgkNCglUaGUgdXN1YWwgc3VzcGVj
dCBpcyB0aGUgbXVsdGl0aHJlYWRlZCBzb3VuZCBETEwsIHNpbmNlIHRoZSBvbmx5IHJlYXNvbg0K
CUV4aXRQcm9jZXNzKCkgbWlnaHQgaGFuZyBzZWVtcyB0byBiZSB3aGlsZSB3YWl0aW5nIGZvciBE
TExzIHRvIGRldGFjaC4gV2UNCgl1c2UgdGhlIHVuZG9jdW1lbnRlZCBNU1ZDKysgNiB0cmljayBm
b3IgYXNzaWduaW5nIG5hbWVzIHRvIHRocmVhZHMgKGNvb2whKQ0KCXNvIHdlIGNhbiBpZGVudGlm
eSB0aG9zZSBpbiB0aGUgZGVidWdnZXIsIGJ1dCB3aGVuIHdlIGdldCB0aGlzIHBhcnRpY3VsYXIN
CglkZWFkbG9jaywgTVNWQysrIHNlZW1zIHRvICJmb3JnZXQiIHRoZSBuYW1lcywgYW5kIHN0YWNr
IHRyYWNlcyBvbmx5IHNob3cgYQ0KCWNvdXBsZSBsZXZlbHMgaW5zaWRlIEtFUk5FTDMyLCBub25l
IG9mIG91ciB1c2VyIGNvZGUuIFRodXMgd2UgYXJlIG5vdCBzdXJlDQoJd2hpY2ggRExMcyBhbmQv
b3IgdGhyZWFkcyBhcmUgY2F1c2luZyB0aGlzIGRlYWRsb2NrLg0KCQ0KCUFueWJvZHkgaGFzIHN1
Z2dlc3Rpb25zIHRoYXQgY2FuIGJlIGhlbHBmdWwgZm9yIGRlYnVnZ2luZyBhbmQvb3Igc29sdmlu
Zw0KCXRoaXMgcHJvYmxlbT8NCgkNCglUaGFua3MgaW4gYWR2YW5jZSwNCgkgIEphdmllciBBcmV2
YWxvDQoJICBQeXJvIFN0dWRpb3MNCgkNCgkNCgkNCgkNCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJVGhpcyBzZi5uZXQgZW1haWwgaXMg
c3BvbnNvcmVkIGJ5OlRoaW5rR2Vlaw0KCVdlbGNvbWUgdG8gZ2VlayBoZWF2ZW4uDQoJaHR0cDov
L3RoaW5rZ2Vlay5jb20vc2YNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KCUdhbWVkZXZsaXN0cy13aW5kb3dzIG1haWxpbmcgbGlzdA0KCUdhbWVkZXZs
aXN0cy13aW5kb3dzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KCWh0dHBzOi8vbGlzdHMuc291cmNl
Zm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2dhbWVkZXZsaXN0cy13aW5kb3dzDQoJQXJjaGl2ZXM6
DQoJaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9tYWlsYXJjaGl2ZS9mb3J1bS5waHA/Zm9ydW1faWQ9
NTU1DQoJDQoNCg==

[GD-Windows] Naming threads

[Javier A. <ja...@py...>]

Javier Arevalo <ja...@py...> wrote:

> We use the undocumented MSVC++ 6 trick for assigning names to
> threads (cool!) so we can identify those in the debugger

Some people asked me about this, so here's the code:

void BASE_SetThreadName(const char *pszName, unsigned threadId)
{
  // 10 chars maximum length of name.
  char buf[10];
  strncpy(buf, pszName, sizeof(buf));
  buf[sizeof(buf)-1] = '\0';

  enum { MS_VC_EXCEPTION = 0x406d1388 };

  struct THREADNAME_INFO
  {
      DWORD dwType;        // must be 0x1000
      LPCSTR pszName;       // pointer to name (in same addr space)
      DWORD dwThreadID;    // thread ID (-1 caller thread)
      DWORD dwFlags;       // reserved for future use, most be zero
  };

  THREADNAME_INFO info;
  info.dwType = 0x1000;
  info.pszName = pszName;
  info.dwThreadID = threadId? threadId : ::GetCurrentThreadId();
  info.dwFlags = 0;

  __try
  {
      RaiseException(MS_VC_EXCEPTION, 0, sizeof(info) / sizeof(DWORD),
(DWORD *)&info);
  }
  __except (EXCEPTION_CONTINUE_EXECUTION)
  {
  }
}

In the Debug | Threads dialog you can now see the names of the threads.

  Javier Arevalo
  Pyro Studios

[GD-Windows] Process hanging inside ExitProcess()

[Javier A. <ja...@py...>]

Hi!

We currently have this annoying bug where, every few days, the game hangs
when quitting, inside CRT's call to ExitProcess() with one (sometimes two)
additional threads running. Of course, it only hangs in our retail builds,
without our helpful debug logs. When we try to break into the debugger, it
dumps the following message to the debug output:

DBG: Break command failed within 3 seconds.
DBG: Potential deadlock. Soft broken.

The usual suspect is the multithreaded sound DLL, since the only reason
ExitProcess() might hang seems to be while waiting for DLLs to detach. We
use the undocumented MSVC++ 6 trick for assigning names to threads (cool!)
so we can identify those in the debugger, but when we get this particular
deadlock, MSVC++ seems to "forget" the names, and stack traces only show a
couple levels inside KERNEL32, none of our user code. Thus we are not sure
which DLLs and/or threads are causing this deadlock.

Anybody has suggestions that can be helpful for debugging and/or solving
this problem?

Thanks in advance,
  Javier Arevalo
  Pyro Studios

RE: [GD-Windows] ChangeDisplaySettings and other windows

[Andrew G. <ag...@cl...>]

Yup that's right.

The correct cleanup order should be

Release all resources
Release device
Release D3D
Destroy all GDI stuff
Destroy window



Andy @ 
Climax Brighton 



-----Original Message-----
From: Gareth Lewin [mailto:GL...@cl...]
Sent: 27 August 2002 09:00
To: Javier Arevalo; gam...@li...
Subject: RE: [GD-Windows] ChangeDisplaySettings and other windows


Hmm, I can't remember the solution, but the idea is a race condition between
when you main window is destroyed and when you come out of fullscreen mode.

The thing is to play with the order of those two. For example make sure that
you destroy your direct3d device in responce to the WM_CLOSE message, so you
know it is killed before the window.

Or in respond to WM_DESTROY

Or make sure that after the window has been killed the device is still alive
and only destroy it in responce to WM_QUIT.

Sorry haven't done this in a while. You might want to try the DirectXDev
mailing list 

> -----Original Message-----
> From: Javier Arevalo [mailto:ja...@py...]
> Sent: 26 August 2002 07:54
> To: gam...@li...
> Subject: Re: [GD-Windows] ChangeDisplaySettings and other windows
> 
> 
> > 'It screws up my windows'. The problem is when their desktop is set
> > to say 1024x768 and the game runs in a fullscreen resolution lower
> > than that, say 640x480. When they exit the game, all their 
> previously
> > opened windows have been clipped to 640x480 and maybe moved position
> 
> Never heard of a solution that worked, plenty that didn't 
> work. I think it
> is a Windows / DirectX design flaw.
> 
>   Javier Arevalo
>   Pyro Studios
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> 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: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
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] ChangeDisplaySettings and other windows

[Barstow J. <JBa...@uk...>]

The D3D samples seem to exhibit the correct behaviour
- so it might be worth checking those out for precise order/handling of
these messages.


I've just converted the sample framework to straight C as the basis for a
new project.
So in addition to correctly handling D3D startup/shutdown (and associated
resolution changes) I now have the basics of a D3D app that will
support alt-tab, alt-enter etc. Its my experience that trying to retro-fit
these features can be frustrating to say the least.

RE: [GD-Windows] ChangeDisplaySettings and other windows

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

When I say "Race condition" I meant "Order of operation"

Sowwy.

_____________________
Regards, Gareth Lewin


> -----Original Message-----
> From: Gareth Lewin [mailto:GL...@cl...]
> Sent: 27 August 2002 09:00
> To: Javier Arevalo; gam...@li...
> Subject: RE: [GD-Windows] ChangeDisplaySettings and other windows
> 
> 
> Hmm, I can't remember the solution, but the idea is a race 
> condition between
> when you main window is destroyed and when you come out of 
> fullscreen mode.
> 
> The thing is to play with the order of those two. For example 
> make sure that
> you destroy your direct3d device in responce to the WM_CLOSE 
> message, so you
> know it is killed before the window.
> 
> Or in respond to WM_DESTROY
> 
> Or make sure that after the window has been killed the device 
> is still alive
> and only destroy it in responce to WM_QUIT.
> 
> Sorry haven't done this in a while. You might want to try the 
> DirectXDev
> mailing list 
> 
> > -----Original Message-----
> > From: Javier Arevalo [mailto:ja...@py...]
> > Sent: 26 August 2002 07:54
> > To: gam...@li...
> > Subject: Re: [GD-Windows] ChangeDisplaySettings and other windows
> > 
> > 
> > > 'It screws up my windows'. The problem is when their 
> desktop is set
> > > to say 1024x768 and the game runs in a fullscreen resolution lower
> > > than that, say 640x480. When they exit the game, all their 
> > previously
> > > opened windows have been clipped to 640x480 and maybe 
> moved position
> > 
> > Never heard of a solution that worked, plenty that didn't 
> > work. I think it
> > is a Windows / DirectX design flaw.
> > 
> >   Javier Arevalo
> >   Pyro Studios
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by: OSDN - Tired of that same old
> > cell phone?  Get a new here for FREE!
> > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> > _______________________________________________
> > 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: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> 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] ChangeDisplaySettings and other windows

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

Hmm, I can't remember the solution, but the idea is a race condition between
when you main window is destroyed and when you come out of fullscreen mode.

The thing is to play with the order of those two. For example make sure that
you destroy your direct3d device in responce to the WM_CLOSE message, so you
know it is killed before the window.

Or in respond to WM_DESTROY

Or make sure that after the window has been killed the device is still alive
and only destroy it in responce to WM_QUIT.

Sorry haven't done this in a while. You might want to try the DirectXDev
mailing list 

> -----Original Message-----
> From: Javier Arevalo [mailto:ja...@py...]
> Sent: 26 August 2002 07:54
> To: gam...@li...
> Subject: Re: [GD-Windows] ChangeDisplaySettings and other windows
> 
> 
> > 'It screws up my windows'. The problem is when their desktop is set
> > to say 1024x768 and the game runs in a fullscreen resolution lower
> > than that, say 640x480. When they exit the game, all their 
> previously
> > opened windows have been clipped to 640x480 and maybe moved position
> 
> Never heard of a solution that worked, plenty that didn't 
> work. I think it
> is a Windows / DirectX design flaw.
> 
>   Javier Arevalo
>   Pyro Studios
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> 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] ChangeDisplaySettings and other windows

[Javier A. <ja...@py...>]

> 'It screws up my windows'. The problem is when their desktop is set
> to say 1024x768 and the game runs in a fullscreen resolution lower
> than that, say 640x480. When they exit the game, all their previously
> opened windows have been clipped to 640x480 and maybe moved position

Never heard of a solution that worked, plenty that didn't work. I think it
is a Windows / DirectX design flaw.

  Javier Arevalo
  Pyro Studios

[GD-Windows] ChangeDisplaySettings and other windows

[Chris C. <chr...@l8...>]

It's one of those things that you couldn't care less about while developing,
but when friends start to test for you they all say it - 'It screws up my
windows'. The problem is when their desktop is set to say 1024x768 and the
game runs in a fullscreen resolution lower than that, say 640x480. When they
exit the game, all their previously opened windows have been clipped to
640x480 and maybe moved position as well. These are not my windows, but is
there anything I can about them? 
(I am using slightly modified NeHe basecode for window/dc/rc creation)

Re: [GD-Windows] CreateDialog failure

[Pierre T. <p.t...@wa...>]

> - Then, I tried using GetModuleHandle() with various parameters, to get
back
> the instance handle from DLL 1. I would have expected
GetModuleHandle(NULL)
> to work. Nope, it never made any difference. It also took me a while to
> figure out that HMODULE was actually the same as HINSTANCE.

....and of course after reading the docs more carefully I finally made it
work, simply passing the DLL name as a parameter. Next time I'll RTFM twice.

Pierre

Re: [GD-Windows] CreateDialog failure

[Pierre T. <p.t...@wa...>]

> From there, I keep track of the HANDLE parameter, static-cast it to a
> HINSTANCE in a very very ugly way, use this for CreateDialog().... and it

Ok my mistake. I copy-pasted a DllMain() function from another source code,
that was using a HANDLE parameter, but it's actually defined as a HINSTANCE
in the MSDN. Seems to work just as well with a HANDLE nonetheless.

(And I finally noticed there was a "Center" style in the resource editor so
I'm using this right now.)

Pierre

Re: [GD-Windows] CreateDialog failure

[Pierre T. <p.t...@wa...>]

>are you sure hInstance is the instance handle to your dll and not the app?
>otherwise LoadResource on the dialog resource will fail

Ok, it finally works but I'm still puzzled. In short, the instance handle
was indeed wrong.

- At first I was using the instance handle from the MAX window (in DLL 0,
say), whereas the requested dialog resource was located in my new DLL, say
DLL 1. No way it could have worked. Nonetheless, there was no clear error
code/message to tell me I was doing something wrong, which is a bit clumsy.

- Then, I tried using GetModuleHandle() with various parameters, to get back
the instance handle from DLL 1. I would have expected GetModuleHandle(NULL)
to work. Nope, it never made any difference. It also took me a while to
figure out that HMODULE was actually the same as HINSTANCE.

- Finally, I added a DllMain function in DLL 1. It wasn't there already
since DLL 1 is a plug-in only exposing a limited set of functions to DLL 0.
From there, I keep track of the HANDLE parameter, static-cast it to a
HINSTANCE in a very very ugly way, use this for CreateDialog().... and it
works ! Casting from HANDLE to HINSTANCE was only a hunch, and not an
obvious one since the implicit cast fails to compile. It looks extremely
ugly and I don't know if it's common practice or anything, but that's the
only thing that seems to work so far. If there's a better way to get back
the correct HINSTANCE, tell me... (you guessed it, I'm not really the Win32
API expert)

- For the records, using hWnd from DLL 0 as a parent seems to work, and
using NULL for the DialogProc works as well.

- Now, I have another problem. The created dialog contains a bitmap, that is
correctly displayed until I try to recenter the dialog.... When I do that,
using SetWindowPos(), the dialog gets centered correctly, but the bitmap
disappears ! This is insane. The SetWindowPos() parameters look insane as
well. I just want X and Y, bloody hell ! Right now here's what I have :

SetWindowPos(hWnd, NULL, x, y, 0, 0,
SWP_NOSIZE|SWP_NOZORDER|SWP_NOACTIVATE|SWP_NOOWNERZORDER);

Any idea why it makes a bitmap contained in the dialog whose handle is hWnd
disappear .....?

Anyway thanks for the hints so far, it helped.

Pierre

PS: for various reasons I can't use MFC in DLL 1, even if I do in DLL 0.

RE: [GD-Windows] CreateDialog failure

[Brian S. <bs...@mi...>]

I mostly use MFC for these sorts of things but here are some ideas to =
try:

* are you sure hInstance is the instance handle to your dll and not the =
app?  otherwise LoadResource on the dialog resource will fail

* is hWnd a fully created window, or is it one you're in the process of =
creating?  have you tried passing NULL for the parent?

* Is NULL a valid value for the DialogProc?  Should it be DefDlgProc?

* If you replace your call with MessageBox(...) does everything work?

Unfortunately I do not know the answer to your real problem, but here's =
a timesaving tip: typing "err,hr" into a watch window in the debugger =
saves you the hassle of calling GLE/FormatMessage/etc.

--brian


-----Original Message-----
From:	Pierre Terdiman [mailto:p.t...@wa...]
Sent:	Sat 8/24/2002 7:18 AM
To:	gam...@li...
Cc:=09
Subject:	[GD-Windows] CreateDialog failure
Hi,

I create a dialog using something like :

handle =3D CreateDialog(
      hInstance,
      MAKEINTRESOURCE(IDD_DIALOG1),
      hWnd,
      NULL);

But returned handle is null, which means (I guess) something went wrong.

So I tried :

  DWORD Er =3D GetLastError();

Then retrieving the error string using FormatMessage (using the code =
snippet from the MSDN). But it doesn't help since error code is 0 and =
the translated string says there was no error.

Hmm. What do I do now ?
What are the usual reasons for CreateDialog to fail ?

In case it's important, the call takes place in a DLL dynamically loaded =
by a 3DS MAX plug-in, and hInstance and hWnd used to create the dialog =
are the ones from the MAX plug.

Pierre

Re[2]: [GD-Windows] CreateDialog failure

[<pat...@t-...>]

Hrmpf. Guess that rules out those options, then.

From the original post:
> In case it's important, the call takes place in a DLL
> dynamically loaded by a 3DS MAX plug-in, and hInstance
> and hWnd used to create the dialog are the ones from
> the MAX plug.
But the dialog resource is actually in the plug-in, and not
in the dll? :-)

If yes, I wonder if there's any obscure rules as to acessing
another's hinstance - I wouldn't think so, but maybe someone
else knows more?

> Hmmm.
Yes, definately :)

-- 
Pat

Re: [GD-Windows] CreateDialog failure

[Pierre T. <p.t...@wa...>]

> Are you really passing NULL as the DLGPROC,

Yes.

> or was that an
> oversight typing the email? I didn't think that was an
> optional parameter.

Doesn't seem to make any difference. But it must be optional, I've already
successfully created dialogs that way in other apps.

> I got bitten at some point by having some common controls
> in a dialog, but forgetting to use InitCommonControls() or
> ...ControlsEx() which caused me no end of stress for being
> something so blindingly simple %)

I'm not using common controls, this is just the default created dialog with
OK / Cancel right now.

Hmmm.

Pierre

Re: [GD-Windows] CreateDialog failure

[<pat...@t-...>]

Are you really passing NULL as the DLGPROC, or was that an
oversight typing the email? I didn't think that was an
optional parameter.

I got bitten at some point by having some common controls
in a dialog, but forgetting to use InitCommonControls() or
...ControlsEx() which caused me no end of stress for being
something so blindingly simple %)

Other than that: beats me :)

Cheers,

-- 
Pat