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

Re: [GD-Windows] Windows in .NET :(

[Ben C. <be...@gu...>]

On Friday, September 6, 2002, 6:50:24 PM, someone wrote:

[snip]
>> This code worked
>> PIXELFORMATDESCRIPTOR pfd;
>>     WNDCLASS wc;
>>     // register window class
>>     wc.style = CS_OWNDC;
>>     wc.cbClsExtra = 0;
>>     wc.cbWndExtra = 0;
>>     wc.hInstance = ctx->HInst;
>>     wc.hbrBackground = (HBRUSH)GetStockObject( BLACK_BRUSH );
>>     wc.lpszMenuName = NULL;
>>     wc.lpszClassName = ctx->AppName;
>>     DWORD so;
>>     if (!RegisterClass( &wc ))
>>         so = GetLastError();
>> 
>> and now I get an error 87 - bad parameter

 I'm working from memory here, but don't you have to set the size
parameter of the WNDCLASS structure, and zero out all the unused
members?

-- 
Ben Carter - Neko Technologies - be...@gu...
http://www.neko-tech.com/ - http://www.absoluteterror.com/
---------------------------------PGP Key available on request---
"Broken mirror, a million shades of light,
 the old echo fades away. 
 But just you and I can find the answer, 
 and then we can run to the end of the world."
                                - Small of two pieces, Xenogears

[GD-Windows] RE: [GD-General] [GD General] Windows in .NET :(

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

(cc'ing the Windows list and removing the general list)

You haven't specified a WNDPROC for your window class.  That might be
one lame reason. =20

In any event, it's a pretty safe bet that oodles of apps calling
RegisterClass were compiled through VS.NET before it shipped.  You
should probably have another look at your code.  Try building a DX
sample app, and compare their setup code against yours.

--brian

> -----Original Message-----
> From: Joe Collins [mailto:jo...@mu...]=20
> Sent: Friday, September 06, 2002 10:51 AM
> To: gam...@li...
> Subject: [GD-General] [GD General] Windows in .NET :(
>=20
>=20
> Hi all,
>=20
> I just stupidly upgraded to Visual C++ .NET from VC6. And so=20
> of course=20
> my windows code doesn't
> work with it for some lame reason.
>=20
> This code worked
> PIXELFORMATDESCRIPTOR pfd;
>     WNDCLASS wc;
>     // register window class
>     wc.style =3D CS_OWNDC;
>     wc.cbClsExtra =3D 0;
>     wc.cbWndExtra =3D 0;
>     wc.hInstance =3D ctx->HInst;
>     wc.hbrBackground =3D (HBRUSH)GetStockObject( BLACK_BRUSH );
>     wc.lpszMenuName =3D NULL;
>     wc.lpszClassName =3D ctx->AppName;
>     DWORD so;
>     if (!RegisterClass( &wc ))
>         so =3D GetLastError();
>=20
> and now I get an error 87 - bad parameter
>=20
> Anyone "upgrade" and have similar problems?
>=20
> On a side note, I have previously tried to get the mousewheel=20
> working in=20
> my code. But
> I get a compile error when I try to use WM_MOUSEWHEEL - undefined
>=20
> There seems to be some magic defines you need to set to get this to=20
> compile... Something to do with
> #define _WIN32_WINNT 0x0400
> #define _WIN32_WINDOWS 0x500
>=20
> but it doesn't seem to work for me. Perhaps there is more=20
> magic in the=20
> ordering or something.
>=20
> Anyway, any help would be sweet.
>=20
> Thanks,
>=20
> -Joe
>=20
>=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-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
>=20

RE: [GD-Windows] More timer fun!

[Leath M. <lea...@ep...>]

> Intel has info at ftp://download.intel.com/ial/home/sp/mmts097.pdf

Excellent -- they've thought of multi processor systems... :) Pity
the doc is two years old and there still isn't anything available...

Leathal.

RE: [GD-Windows] More timer fun!

[Philip T. <pt...@wi...>]

Actually, recent Intel mobos ( ICH3 chipsets iirc, see
http://www.extremetech.com/print_article/0,3998,a=3D10473,00.asp ) do =
have
updated timer hw, and MS will support it in some future OS product I am
not supposed to mention.=20

Intel has info at ftp://download.intel.com/ial/home/sp/mmts097.pdf

Some of the reasons behind the creation of the new timer, as well as
some of our plans for its use have already been posted in the doc
Guidelines for Providing Multimedia Support on
http://www.microsoft.com/hwdev/platform/proc/mm-timer.asp

I believe this was also discussed at the recent WinHEC.

Note, AMD will support this in future mobos as well.

-----Original Message-----
From: Barstow Jason [mailto:JBa...@uk...]=20
Sent: Wednesday, September 04, 2002 2:12 AM
To: gam...@li...
Subject: RE: [GD-Windows] More timer fun!=20


Perhaps we could persuade gfx card manufacturers to add a decent high
precision low latency clock to their cards. Could be exposed via D3D API
or other.

Seeing as we're specifically interested in a solution for gaming and
most of us now presume gfx hardware, this seems like a reasonable
solution.

Would take a while to come through but then how long has this problem
existed already (and with no signs of a practical solution) ?

Jason


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

> > Perhaps we could persuade gfx card manufacturers to add a decent high
> > precision low latency clock to their cards.

> PC's lack of a way to synchronize to the vertical retrace (despite being
> spec'd in EGA or VGA, don't remember) has been in place long enough that I

Anything that sits on the other end of the north bridge is doomed to
be high latency (microsecond or worse) AFAICT.

RDTSC is the best we've got, and it works fine except on SpeedStep.
Grumble.

Cheers,

				/ h+

Re: [GD-Windows] More timer fun!

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

Barstow Jason <JBa...@uk...> wrote:

> Perhaps we could persuade gfx card manufacturers to add a decent high
> precision low latency clock to their cards.
> Could be exposed via D3D API or other.

PC's lack of a way to synchronize to the vertical retrace (despite being
spec'd in EGA or VGA, don't remember) has been in place long enough that I
can't imagine something like you describe. In any case, 3D hardware is not
the place where to look for game logic timing information: the app needs
time information even if it hasn't initialized the rendering engine (think
dedicated servers), or while it's minimized (device lost), etc etc.

  Javier Arevalo
  Pyro Studios

RE: [GD-Windows] More timer fun!

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

Perhaps we could persuade gfx card manufacturers to add a decent high
precision low latency clock to their cards.
Could be exposed via D3D API or other.

Seeing as we're specifically interested in a solution for gaming and most of
us now presume gfx hardware, this seems like a reasonable solution.

Would take a while to come through but then how long has this problem
existed already (and with no signs of a practical solution) ?

Jason

RE: [GD-Windows] More timer fun!

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

> Could you share some insight as to doing this with some 
> reliability? In most

Well, the source code for NTP is rather more authoritative than I 
could ever be :-)

However, a quick-and-dirty way (which I've used privately in the 
past) might include setting up your packets such that, from the 
clients point of view:

- tack on current time when sending
- server returns your-send-time + server-reply-time on the reply
- you receive a packet containing your-send-time, and at this point 
  compare server-reply-time to your-receive-time, your-send-time

Note that the round-trip time is now known. The server's time must 
be in the range of your-send-time through your-receive-time, with a 
tendency towards the center of that range (assuming symmetric round 
trips). You can know to immediately adjust your clock if the server's 
own notion of time is outside this range; a good place to adjust to 
is such that the center of your window lines up with the server-reply-
time.

But, as I said, for a less quick-and-dirty way to do it, you should 
go to some authoritative source. (Maybe a pun was intended there :-)

Cheers,

				/ h+

RE: [GD-Windows] More timer fun!

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

> Anyone mind if I summarize and send this all to an internal MS alias
> with a bunch on kernel gurus on it?  I'll see what I can find...

This is a public list, so feel free.  It would be very, very nice if 
there was a final, authoritative, reliable way to handle timing on all 
Windows platforms.

Sounds like Jon Watte has this figured out, but he's not sharing =P

Brian

RE: [GD-Windows] More timer fun!

[Tom F. <to...@mu...>]

There's the fourth method that someone suggested - set up a silent sound of
known length, and play it on your sound card. And have a notification at the
end of each cycle. And now you have a medium-term calibrator for
timeGetTime()'s slow drifts. Very very hacky, but suprisingly accurate, even
on cheapo sound cards.

Of course, many of them don't support notifications, so...


Tom Forsyth - purely hypothetical Muckyfoot bloke.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Jon Watte [mailto:hp...@mi...]
> Sent: 02 September 2002 19:56
> To: Grills, Jeff; gam...@li...
> Subject: RE: [GD-Windows] More timer fun! 
> 
> 
> 
> > and that we can apparently fix this within our games with 
> enough work,
> > Microsoft should integrate fixes for this into their current and 
> > past OS's.
> 
> QueryPerformanceCounter() is slow enough already (on the order of 1 
> microsecond because of the bus transaction involved). Fixing it is 
> decidedly non-trivial, and, at a minimum, requires doubling the cost 
> of calling it. I think most people who use these functions would 
> rather not take the additional cost hit.
> 
> RDTSC doesn't skip, that I've heard of. It's absolutely the right 
> thing to use for profiling and similar measurements. The only 
> weakness of it is that it may not measure wall-clock time accurately 
> on laptops (that use TimeStep CPUs). I'm prepared to live with that 
> on a local scale, and to use an unholy heuristic trio of 
> QPC/timeGetTime()/RDTSC for keeping track of wallclock time on a 
> global scale.
> 
> Cheers,
> 
> 				/ h+
> 
> 
> 
> -------------------------------------------------------
> 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] More timer fun!

[Aaron B. <aar...@po...>]

> 
> As I understand it, what you describe is the MS preferred way 
> to deal with 
> performance/accuracy critical timing (I seem to recall there 
> being an MSDN 
> article or tech note on the subject, but a quick search didn't find 
> anything). 

http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q274323&ID=KB;EN-US;
Q274323

> results instead. There's reasons for not using timeGetTime() for 
> everything, though what they are escapes me at the moment.

It returns a value in millisec, but I've seen it return the same value for
20ms or longer - i.e. it was only "ticking" about 50 times a second. More
recently I've seen it accurate to 5 or 10ms.

Actually, from the docs:

Windows NT/2000: The default precision of the timeGetTime function can be
five milliseconds or more, depending on the machine. You can use the
timeBeginPeriod and timeEndPeriod functions to increase the precision of
timeGetTime. If you do so, the minimum difference between successive values
returned by timeGetTime can be as large as the minimum period value set
using timeBeginPeriod and timeEndPeriod. Use the QueryPerformanceCounter and
QueryPerformanceFrequency functions to measure short time intervals at a
high resolution, 

Windows 95: The default precision of the timeGetTime function is 1
millisecond. In other words, the timeGetTime function can return successive
values that differ by just 1 millisecond. This is true no matter what calls
have been made to the timeBeginPeriod and timeEndPeriod functions. 


You could simply average the returned value from timeGetTime() over the last
N frames, but you might get visible speed changes if the frame rate suddenly
changes...

Aaron.

RE: [GD-Windows] More timer fun!

[Tom H. <to...@3d...>]

At 10:49 AM 9/2/2002, Tom Forsyth wrote:
>Sounds like one Jon should definately write, seeing as he's got something
>robust working. Go on Jon, do it. You know you want to.
>
>Presumably for a once-per-cycle timer test (which is all you usually need
>for games) you could use QPC, but spot the quantum leaps (forwards and
>backwards) by watching timeGetTime() deltas.

As I understand it, what you describe is the MS preferred way to deal with 
performance/accuracy critical timing (I seem to recall there being an MSDN 
article or tech note on the subject, but a quick search didn't find 
anything). Basically, you use QPC and watch out for large jumps, or 
negative deltas, and if they occur, you validate the results with 
timeGetTime(). In the case of a bogus result, you use the timeGetTime() 
results instead. There's reasons for not using timeGetTime() for 
everything, though what they are escapes me at the moment.

The "bad" thing is that the calls themselves can take a decent amount of 
time, but reliable timing is much more important than ultra fast timing. 
And, realistically, 1 to 4 microseconds per-frame for games is a perfectly 
reasonable amount of time to spend on getting timing information. In 
practice, I've never found a reason to have a lot of different timer calls 
per frame, though I guess others may. It just seems like it would make a 
great many things unnecessarily difficult.

Tom

RE: [GD-Windows] More timer fun!

[Steve L. <st...@mi...>]

Anyone mind if I summarize and send this all to an internal MS alias
with a bunch on kernel gurus on it?  I'll see what I can find...

Obviously, no promises...

Cheers,
	Steve


-----Original Message-----
From: Jon Watte [mailto:hp...@mi...]=20
Sent: Monday, September 02, 2002 3:31 PM
To: Grills, Jeff; gam...@li...
Subject: RE: [GD-Windows] More timer fun!=20


> don't manifest on their development machines.  Even Tom Forsyth, whom
most
> of us would say is a reasonably intelligent programmer, had problems
with
> clock drift on non-development machines using timeGetTime().  Can
> we expect
> as much from your average run of the mill programmer?  I think not.

But now we're dealing with TIME!

There's no way for your app to tell whether QueryPerformanceCounter()
jumped forward, or whether some device driver decided to lock up the
machine for a second. There is NO DIFFERENCE at the application
programming level. Thus, these functions aren't broken (unless they
actually GO BACKWARDS, as opposed to just lagging or skipping).

Note that two computers that are not hooked up to the same physical
crystal are doomed to skew out of sync sooner or later. The description
I saw from Tom sounds to me as if there was no attempt to bring the
clocks back in sync over the network. If you don't do that, you will
lose, always. Just like a digital mixing studio (or video production
studio) Just Won't Work (tm) without a common house clock.

> MS is in the unique position to know enough about the actual hardware
to
> understand if the system has these problems with QPC, and avoid the
extra

I believe chip set vendors write drivers for their chip sets, just
like toaster vendors write drivers for their toasters. And, looking
at the varying quality of chipset drivers (and other drivers in
general), I've seen little correlation between "more compled systems"
and "more competent driver writers".

Cheers,

			/ h+



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

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

Jon Watte <hp...@mi...> wrote:

> Note that two computers that are not hooked up to the same physical
> crystal are doomed to skew out of sync sooner or later. The


True there will be _some_ difference, but I certainly don't expect that to
be in the order of seconds per hour (seconds per month is reasonable).

> description I saw from Tom sounds to me as if there was no attempt to
> bring the clocks back in sync over the network. If you don't do that,
> you will lose, always. Just like a digital mixing studio (or video
> production studio) Just Won't Work (tm) without a common house clock.

Could you share some insight as to doing this with some reliability? In most
cases, a 1-second drift will be noticed as a 1-second lag, so that's the
kind of precision we're shooting for when we attempt to sync the machines'
time.Without some common ground amoung these two machines, I have no clue
how to sync them with that level of precision. The most I could do is, if
the game host's clock runs faster, have clients detect an overflow of
packets and adapt to that, but if it runs slower?!?

  Javier Arevalo
  Pyro Studios

RE: [GD-Windows] ASCII to key name

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

The ';' not getting converted correctly was a bug in my code though I still
have the problem of "cursor up" being reported as "UP" if I do
GetKeyNameText( lParam, ... ) and "NUM 8" if I do GetKeyNameText(
(DWORD(MapVirtualKey( wParam, 0 ))) << 16, ... ) from within WM_KEYDOWN.

-- Daniel, Epic Games Inc.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Daniel Vogel
> Sent: Monday, September 02, 2002 9:04 PM
> To: gam...@li...
> Subject: [GD-Windows] ASCII to key name
>
>
> Does anyone know how to convert from ASCII to something that works with
> GetKeyNameText?
>
> I already tried various VkKeyScan, OemKeyScan, MapVirtualKey combinations
> but they all fail with e.g. cursor up or ';'.
>
> -- Daniel, Epic Games Inc.
>
>
>
> -------------------------------------------------------
> 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] ASCII to key name

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

Does anyone know how to convert from ASCII to something that works with
GetKeyNameText?

I already tried various VkKeyScan, OemKeyScan, MapVirtualKey combinations
but they all fail with e.g. cursor up or ';'.

-- Daniel, Epic Games Inc.

RE: [GD-Windows] More timer fun!

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

request it. request it. bug microsoft. I bunch of times stuff doesn't
get into schedule because there's no 'demand'. I know from internal
lists that the game studios have gone through the same headaches with
the time functions, so it's actually everybody suffering this problem.
=20
Bashing in third party lists wont have any effect.
=20
David

PD: I apologize for the previous non ASCII email. Outlook web doesn't
support it :(



> -----Original Message-----
> From: Grills, Jeff [mailto:jg...@so...]
> Sent: Monday, September 02, 2002 11:20 AM
> To: gam...@li...
> Subject: RE: [GD-Windows] More timer fun!
>=20
>=20
> We could never rely on users having such a thing, unless it was cheap
> enough
> to put in the box with our games.  Even then, I'm not sure we could
trust
> them to install it correctly, even assuming they have an open USB
slot.
>=20
> I think the better question is, why can't a $500 (or even $3000) PC
keep
> decent time?  It's just silly.  QPT jumping by several seconds over
1/20th
> of a second is simply absurd.  Given the hardware issues that are
present,
> and that we can apparently fix this within our games with enough work,
> Microsoft should integrate fixes for this into their current and past
> OS's.
> They need to give us a way to determine if it's installed, allow us to
> redistribute the fixes, and then at our game install time we can
prompt
> the
> user to install them as necessary.
>=20
> j
>=20
> -----Original Message-----
> From: Rich [mailto:leg...@xm...]
> Sent: Monday, September 02, 2002 1:02 PM
> To: gam...@li...
> Subject: Re: [GD-Windows] More timer fun!
>=20
>=20
>=20
> In article <F9CD80F99127D211BA2B00A0C9D855CDDF98FF@LORDANDMASTER>,
>     Tom Forsyth <to...@mu...>  writes:
>=20
> > Curse those hardware designers!
>=20
> Why doesn't someone sell a $5 USB dongle that has decent time? :)
> --
> Ask me about my upcoming book on Direct3D from Addison-Wesley!
>   Direct3D Book <http://www.xmission.com/~legalize/book/>
>     izfree: Open source tools for Windows Installer
>             <http://izfree.sourceforge.net>
>=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

RE: [GD-Windows] More timer fun!

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

> don't manifest on their development machines.  Even Tom Forsyth, whom most
> of us would say is a reasonably intelligent programmer, had problems with
> clock drift on non-development machines using timeGetTime().  Can
> we expect
> as much from your average run of the mill programmer?  I think not.

But now we're dealing with TIME!

There's no way for your app to tell whether QueryPerformanceCounter()
jumped forward, or whether some device driver decided to lock up the
machine for a second. There is NO DIFFERENCE at the application
programming level. Thus, these functions aren't broken (unless they
actually GO BACKWARDS, as opposed to just lagging or skipping).

Note that two computers that are not hooked up to the same physical
crystal are doomed to skew out of sync sooner or later. The description
I saw from Tom sounds to me as if there was no attempt to bring the
clocks back in sync over the network. If you don't do that, you will
lose, always. Just like a digital mixing studio (or video production
studio) Just Won't Work (tm) without a common house clock.

> MS is in the unique position to know enough about the actual hardware to
> understand if the system has these problems with QPC, and avoid the extra

I believe chip set vendors write drivers for their chip sets, just
like toaster vendors write drivers for their toasters. And, looking
at the varying quality of chipset drivers (and other drivers in
general), I've seen little correlation between "more compled systems"
and "more competent driver writers".

Cheers,

			/ h+

RE: [GD-Windows] More timer fun!

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

cmVxdWVzdCBpdC4gcmVxdWVzdCBpdC4gYnVnIG1pY3Jvc29mdC4gSSBidW5jaCBvZiB0aW1lcyBz
dHVmZiBkb2Vzbid0IGdldCBpbnRvIHNjaGVkdWxlIGJlY2F1c2UgdGhlcmUncyBubyAnZGVtYW5k
Jy4gSSBrbm93IGZyb20gaW50ZXJuYWwgbGlzdHMgdGhhdCB0aGUgZ2FtZSBzdHVkaW9zIGhhdmUg
Z29uZSB0aHJvdWdoIHRoZSBzYW1lIGhlYWRhY2hlcyB3aXRoIHRoZSB0aW1lIGZ1bmN0aW9ucywg
c28gaXQncyBhY3R1YWxseSBldmVyeWJvZHkgc3VmZmVyaW5nIHRoaXMgcHJvYmxlbS4NCiANCkJh
c2hpbmcgaW4gdGhpcmQgcGFydHkgbGlzdHMgd29udCBoYXZlIGFueSBlZmZlY3QuDQogDQpEYXZp
ZA0KIA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogR3JpbGxzLCBKZWZm
IFttYWlsdG86amdyaWxsc0Bzb2Uuc29ueS5jb21dIA0KCVNlbnQ6IE1vbiA5LzIvMjAwMiAxMjoy
MCBQTSANCglUbzogJ0pvbiBXYXR0ZSc7IGdhbWVkZXZsaXN0cy13aW5kb3dzQGxpc3RzLnNvdXJj
ZWZvcmdlLm5ldCANCglDYzogDQoJU3ViamVjdDogUkU6IFtHRC1XaW5kb3dzXSBNb3JlIHRpbWVy
IGZ1biEgDQoJDQoJDQoNCg0KCUhvdyBjb3VsZCBwZW9wbGUgcG9zc2libHkgd2FudCB0byB1c2Ug
YSBmdW5jdGlvbiB0aGF0J3MgYnJva2VuIGFuZCB3aWxsDQoJcmV0dXJuIGluY29ycmVjdCB2YWx1
ZXMgb2NjYXNpb25hbGx5PyAgSSBiZXQgbW9zdCBwcm9ncmFtbWVycyBvdXQgdGhlcmUgdGhhdA0K
CXVzZSBRUEMgYXJlbid0IGV2ZW4gYXdhcmUgb2YgdGhlIHByb2JsZW1zIHRoYXQgaXQgaGFzLCBl
c3BlY2lhbGx5IGlmIHRoZXkNCglkb24ndCBtYW5pZmVzdCBvbiB0aGVpciBkZXZlbG9wbWVudCBt
YWNoaW5lcy4gIEV2ZW4gVG9tIEZvcnN5dGgsIHdob20gbW9zdA0KCW9mIHVzIHdvdWxkIHNheSBp
cyBhIHJlYXNvbmFibHkgaW50ZWxsaWdlbnQgcHJvZ3JhbW1lciwgaGFkIHByb2JsZW1zIHdpdGgN
CgljbG9jayBkcmlmdCBvbiBub24tZGV2ZWxvcG1lbnQgbWFjaGluZXMgdXNpbmcgdGltZUdldFRp
bWUoKS4gIENhbiB3ZSBleHBlY3QNCglhcyBtdWNoIGZyb20geW91ciBhdmVyYWdlIHJ1biBvZiB0
aGUgbWlsbCBwcm9ncmFtbWVyPyAgSSB0aGluayBub3QuDQoJDQoJV291bGQgeW91IHVzZSBzcXJ0
KCkgaWYgaXQgb2NjYXNpb25hbGx5IHJldHVybmVkIHRoZSB3cm9uZyByZXN1bHQ/ICBJDQoJd291
bGRuJ3QuICBXb3VsZCB5b3UgYmUgd2lsbGluZyB0byBoYXZlIHNxcnQoKSB0YWtlIHR3aWNlIHRo
ZSB0aW1lIGlmIHRoZQ0KCXJlc3VsdHMgaXQgcmV0dXJuZWQgd2VyZSBhbHdheXMgY29ycmVjdD8g
IEkgd291bGQuDQoJDQoJTVMgaXMgaW4gdGhlIHVuaXF1ZSBwb3NpdGlvbiB0byBrbm93IGVub3Vn
aCBhYm91dCB0aGUgYWN0dWFsIGhhcmR3YXJlIHRvDQoJdW5kZXJzdGFuZCBpZiB0aGUgc3lzdGVt
IGhhcyB0aGVzZSBwcm9ibGVtcyB3aXRoIFFQQywgYW5kIGF2b2lkIHRoZSBleHRyYQ0KCW92ZXJo
ZWFkIGlmIHRoZSBoYXJkd2FyZSBpcyByZWxpYWJsZS4gIElmIHRoZXJlIHJlYWxseSBpcyBzb21l
IG1ham9yDQoJcmVzaXN0YW5jZSB0byBRUEMoKSBnZXR0aW5nIHNsb3dlciwgdGhlbiBNUyBzaG91
bGQgcHJvdmlkZSB1cyBhIG5ldyByb3V0aW5lLA0KCXdoYXRldmVyIHRoZSBuYW1lLCB0aGF0IGFj
dHVhbGx5IHdvcmtzLiAgSXQgc2hvdWxkbid0IGJlIG15IHJlc3BvbnNpYmlsaXR5DQoJdG8gd3Jp
dGUgY29kZSB0byBmaWd1cmUgb3V0IHRoZSBwcm9wZXIgdGltZSB0byBhIHJlYXNvbmFibGUgZGVn
cmVlIG9mDQoJcHJlY2lzaW9uIC0tIHRoYXQncyBhIGpvYiBmb3IgdGhlIG9wZXJhdGluZyBzeXN0
ZW0uDQoJDQoJag0KCQ0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJRnJvbTogSm9uIFdh
dHRlIFttYWlsdG86aHBsdXNAbWluZGNvbnRyb2wub3JnXQ0KCVNlbnQ6IE1vbmRheSwgU2VwdGVt
YmVyIDAyLCAyMDAyIDE6NTYgUE0NCglUbzogR3JpbGxzLCBKZWZmOyBnYW1lZGV2bGlzdHMtd2lu
ZG93c0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglTdWJqZWN0OiBSRTogW0dELVdpbmRvd3NdIE1v
cmUgdGltZXIgZnVuIQ0KCQ0KCQ0KCQ0KCT4gYW5kIHRoYXQgd2UgY2FuIGFwcGFyZW50bHkgZml4
IHRoaXMgd2l0aGluIG91ciBnYW1lcyB3aXRoIGVub3VnaCB3b3JrLA0KCT4gTWljcm9zb2Z0IHNo
b3VsZCBpbnRlZ3JhdGUgZml4ZXMgZm9yIHRoaXMgaW50byB0aGVpciBjdXJyZW50IGFuZA0KCT4g
cGFzdCBPUydzLg0KCQ0KCVF1ZXJ5UGVyZm9ybWFuY2VDb3VudGVyKCkgaXMgc2xvdyBlbm91Z2gg
YWxyZWFkeSAob24gdGhlIG9yZGVyIG9mIDENCgltaWNyb3NlY29uZCBiZWNhdXNlIG9mIHRoZSBi
dXMgdHJhbnNhY3Rpb24gaW52b2x2ZWQpLiBGaXhpbmcgaXQgaXMNCglkZWNpZGVkbHkgbm9uLXRy
aXZpYWwsIGFuZCwgYXQgYSBtaW5pbXVtLCByZXF1aXJlcyBkb3VibGluZyB0aGUgY29zdA0KCW9m
IGNhbGxpbmcgaXQuIEkgdGhpbmsgbW9zdCBwZW9wbGUgd2hvIHVzZSB0aGVzZSBmdW5jdGlvbnMg
d291bGQNCglyYXRoZXIgbm90IHRha2UgdGhlIGFkZGl0aW9uYWwgY29zdCBoaXQuDQoJDQoJUkRU
U0MgZG9lc24ndCBza2lwLCB0aGF0IEkndmUgaGVhcmQgb2YuIEl0J3MgYWJzb2x1dGVseSB0aGUg
cmlnaHQNCgl0aGluZyB0byB1c2UgZm9yIHByb2ZpbGluZyBhbmQgc2ltaWxhciBtZWFzdXJlbWVu
dHMuIFRoZSBvbmx5DQoJd2Vha25lc3Mgb2YgaXQgaXMgdGhhdCBpdCBtYXkgbm90IG1lYXN1cmUg
d2FsbC1jbG9jayB0aW1lIGFjY3VyYXRlbHkNCglvbiBsYXB0b3BzICh0aGF0IHVzZSBUaW1lU3Rl
cCBDUFVzKS4gSSdtIHByZXBhcmVkIHRvIGxpdmUgd2l0aCB0aGF0DQoJb24gYSBsb2NhbCBzY2Fs
ZSwgYW5kIHRvIHVzZSBhbiB1bmhvbHkgaGV1cmlzdGljIHRyaW8gb2YNCglRUEMvdGltZUdldFRp
bWUoKS9SRFRTQyBmb3Iga2VlcGluZyB0cmFjayBvZiB3YWxsY2xvY2sgdGltZSBvbiBhDQoJZ2xv
YmFsIHNjYWxlLg0KCQ0KCUNoZWVycywNCgkNCgkgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIC8gaCsNCgkNCgkNCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQoJVGhpcyBzZi5uZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OiBPU0RO
IC0gVGlyZWQgb2YgdGhhdCBzYW1lIG9sZA0KCWNlbGwgcGhvbmU/ICBHZXQgYSBuZXcgaGVyZSBm
b3IgRlJFRSENCglodHRwczovL3d3dy5pbnBob25pYy5jb20vci5hc3A/cj1zb3VyY2Vmb3JnZTEm
cmVmY29kZTE9dnMzMzkwDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCglHYW1lZGV2bGlzdHMtd2luZG93cyBtYWlsaW5nIGxpc3QNCglHYW1lZGV2bGlz
dHMtd2luZG93c0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglodHRwczovL2xpc3RzLnNvdXJjZWZv
cmdlLm5ldC9saXN0cy9saXN0aW5mby9nYW1lZGV2bGlzdHMtd2luZG93cw0KCUFyY2hpdmVzOg0K
CWh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvbWFpbGFyY2hpdmUvZm9ydW0ucGhwP2ZvcnVtX2lkPTU1
NQ0KCQ0KDQo=

RE: [GD-Windows] More timer fun!

[Grills, J. <jg...@so...>]

How could people possibly want to use a function that's broken and will
return incorrect values occasionally?  I bet most programmers out there that
use QPC aren't even aware of the problems that it has, especially if they
don't manifest on their development machines.  Even Tom Forsyth, whom most
of us would say is a reasonably intelligent programmer, had problems with
clock drift on non-development machines using timeGetTime().  Can we expect
as much from your average run of the mill programmer?  I think not.

Would you use sqrt() if it occasionally returned the wrong result?  I
wouldn't.  Would you be willing to have sqrt() take twice the time if the
results it returned were always correct?  I would.

MS is in the unique position to know enough about the actual hardware to
understand if the system has these problems with QPC, and avoid the extra
overhead if the hardware is reliable.  If there really is some major
resistance to QPC() getting slower, then MS should provide us a new routine,
whatever the name, that actually works.  It shouldn't be my responsibility
to write code to figure out the proper time to a reasonable degree of
precision -- that's a job for the operating system.

j

-----Original Message-----
From: Jon Watte [mailto:hp...@mi...]
Sent: Monday, September 02, 2002 1:56 PM
To: Grills, Jeff; gam...@li...
Subject: RE: [GD-Windows] More timer fun! 



> and that we can apparently fix this within our games with enough work,
> Microsoft should integrate fixes for this into their current and 
> past OS's.

QueryPerformanceCounter() is slow enough already (on the order of 1 
microsecond because of the bus transaction involved). Fixing it is 
decidedly non-trivial, and, at a minimum, requires doubling the cost 
of calling it. I think most people who use these functions would 
rather not take the additional cost hit.

RDTSC doesn't skip, that I've heard of. It's absolutely the right 
thing to use for profiling and similar measurements. The only 
weakness of it is that it may not measure wall-clock time accurately 
on laptops (that use TimeStep CPUs). I'm prepared to live with that 
on a local scale, and to use an unholy heuristic trio of 
QPC/timeGetTime()/RDTSC for keeping track of wallclock time on a 
global scale.

Cheers,

				/ h+

Re: [GD-Windows] More timer fun!

[Rich <leg...@xm...>]

In article <9EA...@ma...>,
    "Grills, Jeff" <jg...@so...>  writes:

> We could never rely on users having such a thing, unless it was cheap enough
> to put in the box with our games.  Even then, I'm not sure we could trust
> them to install it correctly, even assuming they have an open USB slot.

It was a silly suggestion, hence the :)

> I think the better question is, why can't a $500 (or even $3000) PC keep
> decent time?

Its called backwards compatability.  The timer support in the original
PC sucked and nobody has bothered to fix it because until gaming there
just weren't any apps that demanded decent time, and if they did they
were such niche applications that people could afford to add a little
piece of HW that had the time support they needed.
-- 
Ask me about my upcoming book on Direct3D from Addison-Wesley!
  Direct3D Book <http://www.xmission.com/~legalize/book/>
    izfree: Open source tools for Windows Installer
            <http://izfree.sourceforge.net>

RE: [GD-Windows] More timer fun!

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

> and that we can apparently fix this within our games with enough work,
> Microsoft should integrate fixes for this into their current and 
> past OS's.

QueryPerformanceCounter() is slow enough already (on the order of 1 
microsecond because of the bus transaction involved). Fixing it is 
decidedly non-trivial, and, at a minimum, requires doubling the cost 
of calling it. I think most people who use these functions would 
rather not take the additional cost hit.

RDTSC doesn't skip, that I've heard of. It's absolutely the right 
thing to use for profiling and similar measurements. The only 
weakness of it is that it may not measure wall-clock time accurately 
on laptops (that use TimeStep CPUs). I'm prepared to live with that 
on a local scale, and to use an unholy heuristic trio of 
QPC/timeGetTime()/RDTSC for keeping track of wallclock time on a 
global scale.

Cheers,

				/ h+

RE: [GD-Windows] More timer fun!

[Grills, J. <jg...@so...>]

We could never rely on users having such a thing, unless it was cheap enough
to put in the box with our games.  Even then, I'm not sure we could trust
them to install it correctly, even assuming they have an open USB slot.

I think the better question is, why can't a $500 (or even $3000) PC keep
decent time?  It's just silly.  QPT jumping by several seconds over 1/20th
of a second is simply absurd.  Given the hardware issues that are present,
and that we can apparently fix this within our games with enough work,
Microsoft should integrate fixes for this into their current and past OS's.
They need to give us a way to determine if it's installed, allow us to
redistribute the fixes, and then at our game install time we can prompt the
user to install them as necessary.

j

-----Original Message-----
From: Rich [mailto:leg...@xm...]
Sent: Monday, September 02, 2002 1:02 PM
To: gam...@li...
Subject: Re: [GD-Windows] More timer fun! 



In article <F9CD80F99127D211BA2B00A0C9D855CDDF98FF@LORDANDMASTER>,
    Tom Forsyth <to...@mu...>  writes:

> Curse those hardware designers!

Why doesn't someone sell a $5 USB dongle that has decent time? :)
-- 
Ask me about my upcoming book on Direct3D from Addison-Wesley!
  Direct3D Book <http://www.xmission.com/~legalize/book/>
    izfree: Open source tools for Windows Installer
            <http://izfree.sourceforge.net>

Re: [GD-Windows] More timer fun!

[Rich <leg...@xm...>]

In article <F9CD80F99127D211BA2B00A0C9D855CDDF98FF@LORDANDMASTER>,
    Tom Forsyth <to...@mu...>  writes:

> Curse those hardware designers!

Why doesn't someone sell a $5 USB dongle that has decent time? :)
-- 
Ask me about my upcoming book on Direct3D from Addison-Wesley!
  Direct3D Book <http://www.xmission.com/~legalize/book/>
    izfree: Open source tools for Windows Installer
            <http://izfree.sourceforge.net>

RE: [GD-Windows] More timer fun!

[Tom F. <to...@mu...>]

Sounds like one Jon should definately write, seeing as he's got something
robust working. Go on Jon, do it. You know you want to.

Presumably for a once-per-cycle timer test (which is all you usually need
for games) you could use QPC, but spot the quantum leaps (forwards and
backwards) by watching timeGetTime() deltas.

In retrospect, timeGetTime() slippage is almost certainly what is killing
many networked games of StarTopia - they start out fine but after half an
hour or so of play they get too far out of sync and die. The system will
cope with a certain amount of lagginess, but gives up at about five seconds,
assuming that your network connection is stuffed. And of course all our
testing in the office was on mainly one or two very similar models of Dell,
so we never saw this problem, even after many hours. Curse those hardware
designers!


Tom Forsyth - purely hypothetical Muckyfoot bloke.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Pierre Terdiman [mailto:p.t...@wa...]
> Sent: 30 August 2002 15:53
> To: gam...@li...
> Subject: Re: [GD-Windows] More timer fun!
> 
> 
> 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+
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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
>