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

Re: [GD-Windows] DLL initialization (was: Loading new DLLs on old Windows)

[Andras B. <bn...@ma...>]

It's not like one DLL for each class! :) You could have a class that
provides factory functions, that can create multiple other classes.
Also, the exported interface is usually _very_ high level. On the
implementation side, the plugin can use thousands of classes in one
DLL, it's just that they are internal to that module and not
accessible to the outer world.

BTW: I'm not loading that many DLLs. In fact, this small demo loads
only one DLL, that contains all the logic. The factory creates a very
small class called Main, that upon initialization creates multiple
internal classes, which themselves subscribe to such events like
Simulation, UI_Update, RenderScene, InputEvent, etc... (Event handling
is provided by the framework, through a globally accessible
interface).


Andras


Sunday, February 15, 2004, 12:21:00 PM, Nicolas Romantzoff wrote:

> Hi,

> I hope I'm not saying something too obvious, like ... Not loading more
> than 64+ DLLs ?
> Handles are quite limited under W9x (DOS), and in the past, we had
> several trouble loading numerous plug-ins from big number of DLLs (in
> fact 64+ :( ), we had to regroup some plug-ins.
> BTW I saw in your first message something like "a DLL = a class" ! For a
> medium project (1000 classes ?) that might be far too many DLLs to
> handle for W9x :)

> 1 DLL = 1 Class is a bad choice. You'd better have 1 class <--n----1-->
> 1 factory = 1 DLL.

> Soz if this was what you were doing.

> Nicolas Romantzoff

RE: [GD-Windows] DLL initialization (was: Loading new DLLs on old Windows)

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

Hi,

I hope I'm not saying something too obvious, like ... Not loading more
than 64+ DLLs ?
Handles are quite limited under W9x (DOS), and in the past, we had
several trouble loading numerous plug-ins from big number of DLLs (in
fact 64+ :( ), we had to regroup some plug-ins.
BTW I saw in your first message something like "a DLL = a class" ! For a
medium project (1000 classes ?) that might be far too many DLLs to
handle for W9x :)

1 DLL = 1 Class is a bad choice. You'd better have 1 class <--n----1-->
1 factory = 1 DLL.

Soz if this was what you were doing.

Nicolas Romantzoff



> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Andras Balogh
> Sent: Saturday, February 14, 2004 5:11 PM
> To: gam...@li...
> Subject: Re: [GD-Windows] DLL initialization (was: Loading 
> new DLLs on old Windows)
> 
> 
> Unfortunately I haven't collected detailed system info from 
> other users, but I believe that most of them had 
> Windows2000/XP (not sure, just extrapolating from the few 
> guys I've talked to), while this guy is running a Win98SE box 
> (Windows 4.10.67766446  A).
> 
> 
> Andras

Re: [GD-Windows] DLL initialization (was: Loading new DLLs on old Windows)

[Andras B. <bn...@ma...>]

Saturday, February 14, 2004, 6:03:08 PM, Brian Hook wrote:

>> Unfortunately I haven't collected detailed system info from other
>> users, but I believe that most of them had Windows2000/XP (not
>> sure, just extrapolating from the few guys I've talked to), while
>> this guy is running a Win98SE box (Windows 4.10.67766446  A).

> Well, at the risk of stating the glaringly obvious, it's possible that
> your own DLL is dependent on a DLL that is only available on
> Win2K/WinXP -- have you itemized your dependencies and then looked to
> see if those are available on Win98SE?

Dependency Walker says it depends only on kernel32.dll, msvcp71.dll
and msvcr71.dll (I have provided the last two).

The nicest thing about such plugins, is that they mostly use the
services provided by my framework (or other plugins), thus they are
really lean!



Andras

Re: [GD-Windows] DLL initialization (was: Loading new DLLs on old Windows)

[Brian H. <ho...@py...>]

> Unfortunately I haven't collected detailed system info from other
> users, but I believe that most of them had Windows2000/XP (not
> sure, just extrapolating from the few guys I've talked to), while
> this guy is running a Win98SE box (Windows 4.10.67766446  A).

Well, at the risk of stating the glaringly obvious, it's possible that 
your own DLL is dependent on a DLL that is only available on 
Win2K/WinXP -- have you itemized your dependencies and then looked to 
see if those are available on Win98SE?

Brian

Re: [GD-Windows] DLL initialization (was: Loading new DLLs on old Windows)

[Andras B. <bn...@ma...>]

Unfortunately I haven't collected detailed system info from other
users, but I believe that most of them had Windows2000/XP (not sure,
just extrapolating from the few guys I've talked to), while this guy
is running a Win98SE box (Windows 4.10.67766446  A).


Andras


Friday, February 13, 2004, 7:45:15 PM, Brian Hook wrote:

>> but now some guy told me that it breaks on his machine, giving this
>> error message... So I have to figure this out blindly..

> Welll...the obvious thing is to do a "diff" on his system vs.
> yours/others.  What OS, memory, etc.?

> Brian

Re: [GD-Windows] DLL initialization (was: Loading new DLLs on old Windows)

[Andras B. <bn...@ma...>]

No, it's not crashing. When my framework detects that the required DLL
cannot be loaded, it records the error messages in the log, then quits
nicely. I think I'll just write a stripped down test program, and see
if it works on his machine..


Andras


Friday, February 13, 2004, 7:10:59 PM, Jon Watte wrote:


> Yeah, Windows is like that :-(

> If it's a crash, you can look into the minidump facility that's built-into
> Windows XP, but this error probably doesn't count as a catchable exception.
> Does it say what the offending library is? Can you run a debug output spy
> and capture information? If you can't even do that, I can't think of another
> way to debug it.

> Re-write your demo to load all shared libraries manually? :-)

> Good luck!

> Cheers,

>                         / h+

Re: [GD-Windows] DLL initialization (was: Loading new DLLs on old Windows)

[Brian H. <ho...@py...>]

> but now some guy told me that it breaks on his machine, giving this
> error message... So I have to figure this out blindly..

Welll...the obvious thing is to do a "diff" on his system vs. 
yours/others.  What OS, memory, etc.?

Brian

RE: [GD-Windows] DLL initialization (was: Loading new DLLs on old Windows)

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

Yeah, Windows is like that :-(

If it's a crash, you can look into the minidump facility that's built-into
Windows XP, but this error probably doesn't count as a catchable exception.
Does it say what the offending library is? Can you run a debug output spy
and capture information? If you can't even do that, I can't think of another
way to debug it.

Re-write your demo to load all shared libraries manually? :-)

Good luck!

Cheers,

			/ h+


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Andras Balogh
Sent: Friday, February 13, 2004 9:21 AM
To: gam...@li...
Subject: Re: [GD-Windows] DLL initialization (was: Loading new DLLs on
old Windows)


Hi Jon,

The DLL exists (otherways the error code would be different), and it
also doesn't mess with UNICODE. The logs report that memory is also
sufficient.

Unfortunately, I can't use a debugger, as this error doesn't happen on
my machine. Actually, this program is just my tech demo. Many people
have tried it and I got a lot of positive feedbacks so far, but now
some guy told me that it breaks on his machine, giving this error
message... So I have to figure this out blindly..

Thanks,

Andras

Thursday, February 12, 2004, 9:10:43 PM, Jon Watte wrote:


> Typically this means that you're linking with a DLL that doesn't exist, or
> you're calling UNICODE functions without unicode support, or you're plain
> running out of memory. Do you have one of the machines available for
> debugging? WinDbg sometimes helps in debugging these things.

> Cheers,

>                         / h+


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Andras Balogh
> Sent: Thursday, February 12, 2004 4:21 AM
> To: gam...@li...
> Subject: [GD-Windows] DLL initialization (was: Loading new DLLs on old
> Windows)


> My program supports dynamic loading of plugins. Every plugin
> represents a class, and resides in a separate DLL. Instead of
> exporting the class itself, I only export a factory function and
> provide a header file with the declaration of the pure virtual base
> class (ie. the interface). At runtime, I load the DLL and call the
> exported factory function, which instances an object and returns a
> pointer to the base class.

> This architecture works like a charm on most machines. However, on
> some configurations, my program reports the following: "Error Code
> 1114: A dynamic link library (DLL) initialization routine failed."

> But I have no clue why. Do I have to use DllMain? MSDN says it's only
> an optional entrypoint.. My DLLs are dynamically linked to the C/CPP
> run-time libraries.


> Thanks,

> Andras



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
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] DLL initialization (was: Loading new DLLs on old Windows)

[Andras B. <bn...@ma...>]

Hi Jon,

The DLL exists (otherways the error code would be different), and it
also doesn't mess with UNICODE. The logs report that memory is also
sufficient.

Unfortunately, I can't use a debugger, as this error doesn't happen on
my machine. Actually, this program is just my tech demo. Many people
have tried it and I got a lot of positive feedbacks so far, but now
some guy told me that it breaks on his machine, giving this error
message... So I have to figure this out blindly..

Thanks,

Andras

Thursday, February 12, 2004, 9:10:43 PM, Jon Watte wrote:


> Typically this means that you're linking with a DLL that doesn't exist, or
> you're calling UNICODE functions without unicode support, or you're plain
> running out of memory. Do you have one of the machines available for
> debugging? WinDbg sometimes helps in debugging these things.

> Cheers,

>                         / h+


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Andras Balogh
> Sent: Thursday, February 12, 2004 4:21 AM
> To: gam...@li...
> Subject: [GD-Windows] DLL initialization (was: Loading new DLLs on old
> Windows)


> My program supports dynamic loading of plugins. Every plugin
> represents a class, and resides in a separate DLL. Instead of
> exporting the class itself, I only export a factory function and
> provide a header file with the declaration of the pure virtual base
> class (ie. the interface). At runtime, I load the DLL and call the
> exported factory function, which instances an object and returns a
> pointer to the base class.

> This architecture works like a charm on most machines. However, on
> some configurations, my program reports the following: "Error Code
> 1114: A dynamic link library (DLL) initialization routine failed."

> But I have no clue why. Do I have to use DllMain? MSDN says it's only
> an optional entrypoint.. My DLLs are dynamically linked to the C/CPP
> run-time libraries.


> Thanks,

> Andras

Re: [GD-Windows] Performance timing

[<cas...@ya...>]

Brian Hook wrote:
 > Ya know, the whole damn industry would benefit if someone would
 > actually do a good, solid comprehensive write up with a code example
 > of "take three votes" method.  Just sayin'. =)

Agreed.

There's a project that provides a high resolution timer for the linux 
kernel: (yes, I know this is a windows mailing list)

http://sourceforge.net/projects/high-res-timers/

It provides an implementation of the POSIX timers using a combination of
several methods: the old 8254, the internal Pentium TSC and the ACPI 
timers. Currently there are patches for 2.4 and 2.6, but it's not on the 
main trunk jet.

However, the problem is not to have a good system timer, but to deal 
with old systems, that still have a buggy timers. As you say, a code 
example of the voting method would really help.


-- 
Ignacio Castaño
cas...@ya...

RE: [GD-Windows] DLL initialization (was: Loading new DLLs on old Windows)

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

Typically this means that you're linking with a DLL that doesn't exist, or
you're calling UNICODE functions without unicode support, or you're plain
running out of memory. Do you have one of the machines available for
debugging? WinDbg sometimes helps in debugging these things.

Cheers,

			/ h+


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Andras Balogh
Sent: Thursday, February 12, 2004 4:21 AM
To: gam...@li...
Subject: [GD-Windows] DLL initialization (was: Loading new DLLs on old
Windows)


My program supports dynamic loading of plugins. Every plugin
represents a class, and resides in a separate DLL. Instead of
exporting the class itself, I only export a factory function and
provide a header file with the declaration of the pure virtual base
class (ie. the interface). At runtime, I load the DLL and call the
exported factory function, which instances an object and returns a
pointer to the base class.

This architecture works like a charm on most machines. However, on
some configurations, my program reports the following: "Error Code
1114: A dynamic link library (DLL) initialization routine failed."

But I have no clue why. Do I have to use DllMain? MSDN says it's only
an optional entrypoint.. My DLLs are dynamically linked to the C/CPP
run-time libraries.


Thanks,

Andras



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
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] DLL initialization (was: Loading new DLLs on old Windows)

[Andras B. <bn...@ma...>]

My program supports dynamic loading of plugins. Every plugin
represents a class, and resides in a separate DLL. Instead of
exporting the class itself, I only export a factory function and
provide a header file with the declaration of the pure virtual base
class (ie. the interface). At runtime, I load the DLL and call the
exported factory function, which instances an object and returns a
pointer to the base class.

This architecture works like a charm on most machines. However, on
some configurations, my program reports the following: "Error Code
1114: A dynamic link library (DLL) initialization routine failed."

But I have no clue why. Do I have to use DllMain? MSDN says it's only
an optional entrypoint.. My DLLs are dynamically linked to the C/CPP
run-time libraries.


Thanks,

Andras

[GD-Windows] losing focus and dx8 sound volume

[Jamie F. <ja...@qu...>]

When you lose focus, dx8 stops taking notice of any volume setting you do on
sounds; does anyone know of a useful way of fixing or dealing with this
problem? (The best workaround i've thought of so far is notice when you
regain focus, and reset all the sound volumes; oh so pretty).

jamie

RE: [GD-Windows] Performance timing

[Martin S. <ms...@he...>]

Just noticed that there is an article in Windows Developer Nwetowkr
magazine that discusses the different timer mechanisms available under
windows. It gives call costs and some other analysis. Maybe interesting.

@ http://www.windevnet.com/wdn/issues/2003/0305/pdf/wdn200305.zip


Martin

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
Jon
> Watte
> Sent: Thursday, 12 February 2004 7:49 AM
> To: gam...@li...
> Subject: RE: [GD-Windows] Performance timing
> 
> 
> > As you can see, the delta is between 15-16ms. More than enough to
count
> time
> > between 60hz frames...
> 
> 
> How many frames are you talking about?
> 
> A single 60 Hz frame is 16 milliseconds. That's it. If you take
longer,
> it's
> not 60 Hz anymore.
> 
> I think we already agreed that, for timing over 100 or even 1000
frames,
> pretty much anything works (although you'll still be on the order of
1%
> off
> on GetTickCount()).
> 
> For timing over 10 frames, being off by a whole frame's worth is
pretty
> bad.
> 
> Cheers,
> 
> 				/ h+
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> 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] Performance timing

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

> As you can see, the delta is between 15-16ms. More than enough to count
time
> between 60hz frames...


How many frames are you talking about?

A single 60 Hz frame is 16 milliseconds. That's it. If you take longer, it's
not 60 Hz anymore.

I think we already agreed that, for timing over 100 or even 1000 frames,
pretty much anything works (although you'll still be on the order of 1% off
on GetTickCount()).

For timing over 10 frames, being off by a whole frame's worth is pretty bad.

Cheers,

				/ h+

RE: [GD-Windows] Performance timing

[tweety <mi...@sy...>]

Oh... Forgot to mention my specs: amd xp 2500+, windows xp professional =
sp1

----------------------------------
Peace and love,
Tweety
mi...@sy... - twe...@us...
YahooID: tweety_04_01



-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of =
chaac
Sent: February 11, 2004 5:40 AM
To: gam...@li...
Subject: Re: [GD-Windows] Performance timing

tweety wrote:

> Same here; this was what I was talking about.
> Besides, rdtsc and queryperformancetimer has some very nasty=20
> sincronization problems with multiple processors (they give the time=20
> slightly different wether the code is run on different processors).
> Good old GetTickCount does its job :)

Hi,

But then again, if I remember correcly, GetTickCount goes in steps of =
32ms.
If you need more accuracy, you are out of the game here.

And if you are just profiling on your development machine or at machine =
you
can reach or otherwise know some details about it. You can quite easily =
use
other measurement methods also.

In some cases how fast to get time is not the issue, but accuracy of =
delta
time is.

Thanks,
Vesa J=E4=E4skel=E4inen



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on =
Open
Tools Development and Integration See the breadth of Eclipse activity.
February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
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] Performance timing

[tweety <mi...@sy...>]

Disagree again :)
I wrote the following program:

-----------------------------------
#include "stdafx.h"
#include <windows.h>

int _tmain(int argc, _TCHAR* argv[])
{
	DWORD currenttick=3DGetTickCount(), oldtick=3Dcurrenttick,
starttick=3Dcurrenttick;
	while(currenttick - starttick<=3D10000)
	{
		currenttick=3DGetTickCount();
		if(oldtick!=3Dcurrenttick)
		{
			printf("%10d\n", currenttick);
			oldtick=3Dcurrenttick;
		}
	}
	return 0;
}
-----------------------------------

And part of its output is:
-----------------------------------
  70250890
  70250906
  70250921
  70250937
  70250953
  70250968
  70250984
  70251000
  70251015
  70251031
  70251046
  70251062
  70251078
  70251093
  70251109
  70251125
-----------------------------------

As you can see, the delta is between 15-16ms. More than enough to count =
time
between 60hz frames...

----------------------------------
Peace and love,
Tweety
mi...@sy... - twe...@us...
YahooID: tweety_04_01


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of =
chaac
Sent: February 11, 2004 5:40 AM
To: gam...@li...
Subject: Re: [GD-Windows] Performance timing

tweety wrote:

> Same here; this was what I was talking about.
> Besides, rdtsc and queryperformancetimer has some very nasty=20
> sincronization problems with multiple processors (they give the time=20
> slightly different wether the code is run on different processors).
> Good old GetTickCount does its job :)

Hi,

But then again, if I remember correcly, GetTickCount goes in steps of =
32ms.
If you need more accuracy, you are out of the game here.

And if you are just profiling on your development machine or at machine =
you
can reach or otherwise know some details about it. You can quite easily =
use
other measurement methods also.

In some cases how fast to get time is not the issue, but accuracy of =
delta
time is.

Thanks,
Vesa J=E4=E4skel=E4inen



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on =
Open
Tools Development and Integration See the breadth of Eclipse activity.
February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
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] Loading new DLLs on old Windows

[Andras B. <bn...@ma...>]

Ah, thanks! Huge amount of info there! You were right, my DLLs are all
having subversion 4.0. So my problem is probably somewhere else..

Thanks again,


Andras


Wednesday, February 11, 2004, 1:21:44 AM, Simon O'Connor wrote:


> Hi Andras,


> The subsystem for a DLL is controlled by the /SUBSYSTEM: linker option in
> your project settings.


> For a DLL project, this will be set to /SUBSYSTEM:WINDOWS.


> The /SUBSYSTEM: linker option has an **OPTIONAL** subsystem version
> parameter (e.g. /SUBSYSTEM:WINDOWS,5.01). This optional parameter allows you
> to specify the _minimum_ OS version that the DLL requires to be run.

> You'll find a list of OS version numbers in the documentation for
> OSVERSIONEX. Some examples are:
> Windows 95:    4.0
> Windows 98:    4.10
> Windows ME:    4.90
> Windows 2000:  5.0
> Windows XP:    5.1 (5.01)

> Note that the OS version number comes as two parts, major (4, 5 etc) and
> minor (0, 10, 90, 1 etc). The point isn't a decimal point so 5.1 is the same
> as 5.01 (the "minor" number is 1).


> If you (or your development tools) do *not* specify the optional version
> parameter at the end of the /SUBSYSTEM:WINDOWS option, a default subsystem
> of 4.00 will be used, regardless of your development tool or OS. [NB: only
> for x86  code targets, for Itanium code targets this is 5.01]

> So a DLL created with Visual Studio .NET 2003 on a WindowsXP machine for
> example will still have a subsystem of 4.00.


> The only time you'll encounter a DLL under Win32 OSes that has a subsystem
> that is different than 4.00 is if that DLL absolutely requires that version
> of Windows.


> You can view the subsystem of a DLL using Dependency Walker (it comes with
> the platform SDK, depends.exe). DUMPBIN should tell you this too.


> To change the subsystem of an existing DLL that you don't have the
> sourcecode to (i.e. when you aren't able to alter the /SUBSYSTEM option),
> you can change it using EDITBIN.


> So in short, all that part of the documentation is saying is "if the DLL
> specifies that it needs a newer version of Windows than the one currently
> installed (if 9x) then the LoadLibrary() call will fail".


> HTH

> Cheers,

> Simon O'Connor
> Programmer @ Acclaim
> & Microsoft DirectX MVP

>> -----Original Message-----
>> From: gam...@li...
>> [mailto:gam...@li...] On
>> Behalf Of Andras Balogh
>> Sent: 10 February 2004 16:31
>> To: gam...@li...
>> Subject: [GD-Windows] Loading new DLLs on old Windows
>>
>> MSDN says:
>>
>> "Windows Me/98/95: If you are using LoadLibrary to load a
>> module that contains a resource whose numeric identifier is
>> greater than 0x7FFF, LoadLibrary fails. If you are attempting
>> to load a 16-bit DLL directly from 32-bit code, LoadLibrary
>> fails. If you are attempting to load a DLL whose subsystem
>> version is greater than 4.0, LoadLibrary fails. If your
>> DllMain function tries to call the Unicode version of a
>> function, LoadLibrary fails."
>>
>> Now, I believe that my DLLs' subsystem version is greater
>> than 4.0 (how can I check?). How can I make it work on
>> Win95/98/ME?? Is there a linker option? Or some other workaround?
>>
>>
>> Thanks,
>>
>> Andras
>>

RE: Re[4]: [GD-Windows] Performance timing

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

That's interesting!

As others have said: the accuracy of GetTickCount() varies highly depending
on your system in general, as it polls some variable that gets updated once
in a while; that's why it's the fastest. For a FPS counter, it's probably
accurate enough.

When you run micro-benchmarks like this, 10,000 calls might not be enough.
Get interrupted once by a task switch, or just network packet/mouse
movement, and your measurement is off. That's why I prefer measuring the
BEST sample out of many samples. That, for RDTSC, is on the order of 40
cycles, if you don't care about temporal serialization (which you typically
don't).

Hard to say more without more details about the benchmark, though. (I've
been burned by benchmarks measuring something other than I thought they did
SOOO many times it's not even funny anymore).

Cheers,

			/ h+


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Carl Bevil
Sent: Tuesday, February 10, 2004 5:27 PM
To: Simon O'Connor
Subject: Re[4]: [GD-Windows] Performance timing


Did that, and they have a nice utility that performs some timing tests on
your machine and spits out a report (it's at
http://developer.nvidia.com/object/timer_function_performance.html).

The report had interesting results:

-----

QueryPerformanceFrequency() freq  = 0  2593560000


method 0:
  QueryPerfCntr..()  10000 times
  tot:   0 6720740
  avg:   672.074000
  avg time:			 2.59132e-007


method 1:
  GetTickCount()  10000 times
  tot:   0 260708
  avg:   26.070800
  avg time:			 1.00521e-008


method 2:
  TimeGetTime()  10000 times
  tot:   0 1420712
  avg:   142.071200
  avg time:			 5.47785e-008



method 3:
  Pentium internal high-freq cntr()  10000 times
  tot:   0 840856
  avg:   84.085600
  avg time:			 3.24209e-008

-----

I've left out the data for less than 10,000 iterations for sake of length;
the averages were similar for these cases (and I ran the test a couple times
with similar results).

It looks like GetTickCount is the fastest, at least for this test setup on
my machine.  Am I reading the results wrong?  I would have expected RDTSC to
be the fastest.  What could this mean?  Is this because of the cache effects
that Jon mentioned?  Just curious.  :-)

Tbanks!

Carl


------------------------------------------
Tuesday, February 10, 2004, 4:44:01 PM, you wrote:


> Hi Carl,


> Have a search around nVidia's developer website
> (http://developer.nvidia.com), IIRC they did presentation surveying each
of
> the major timing methods with regard to using them to profile code and the
> advantages and disadvantages plus latencies of each.



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
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: Re[4]: [GD-Windows] Performance timing

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

> Besides, rdtsc and queryperformancetimer has some very nasty
sincronization
> problems with multiple processors (they give the time slightly different
> wether the code is run on different processors).

QueryPerformanceCounter() typically uses the chip set, rather than CPU,
counters, to avoid this problem.

It is up to the OS to synchronize RDTSC on boot-up. If it doesn't, the OS is
broken. Luckily, I've never used an OS where it was broken. (We had all
kinds of fun getting them in sync in the BeOS kernel, but we did it.)

Cheers,

			/ h+

Re[6]: [GD-Windows] Performance timing

[Carl B. <car...@ya...>]

OK, so what I'm getting is that while GetTickCount has an exceptionally fast execution time, it's not as precise (by quite a bit) as RDTSC or QueryPerformanceCounter.  Of the latter two, RDTSC is generally faster.  So if I could only pick one for general use, I'd pick RDTSC.  Although the most reliable solution is to use more than one and have them "vote".

------------------------------------------
Wednesday, February 11, 2004, 9:16:09 AM, you wrote:

> (To be more precise, it does a fixed-point multiply and shift to convert the
> count to milliseconds.)

> -----Original Message-----
> From: Donavon Keithley 
> Sent: Wednesday, February 11, 2004 11:02 AM
> To: 'gam...@li...'
> Subject: RE: Re[4]: [GD-Windows] Performance timing


> GetTickCount is just a tiny function that reads a variable that's
> incremented in the system timer interrupt handler.  In situations where this
> timer is useful, the extra speed is insignificant.


> -----Original Message-----
> From: Carl Bevil [mailto:car...@ya...]
> Sent: Tuesday, February 10, 2004 7:27 PM
> To: Simon O'Connor
> Subject: Re[4]: [GD-Windows] Performance timing


> Did that, and they have a nice utility that performs some timing tests on
> your machine and spits out a report (it's at
> http://developer.nvidia.com/object/timer_function_performance.html).

> The report had interesting results:

RE: Re[4]: [GD-Windows] Performance timing

[Donavon K. <DKe...@io...>]

(To be more precise, it does a fixed-point multiply and shift to convert the
count to milliseconds.)

-----Original Message-----
From: Donavon Keithley 
Sent: Wednesday, February 11, 2004 11:02 AM
To: 'gam...@li...'
Subject: RE: Re[4]: [GD-Windows] Performance timing


GetTickCount is just a tiny function that reads a variable that's
incremented in the system timer interrupt handler.  In situations where this
timer is useful, the extra speed is insignificant.


-----Original Message-----
From: Carl Bevil [mailto:car...@ya...]
Sent: Tuesday, February 10, 2004 7:27 PM
To: Simon O'Connor
Subject: Re[4]: [GD-Windows] Performance timing


Did that, and they have a nice utility that performs some timing tests on
your machine and spits out a report (it's at
http://developer.nvidia.com/object/timer_function_performance.html).

The report had interesting results:

-----

QueryPerformanceFrequency() freq  = 0  2593560000 


method 0:
  QueryPerfCntr..()  10000 times
  tot:   0 6720740
  avg:   672.074000
  avg time:			 2.59132e-007


method 1:
  GetTickCount()  10000 times
  tot:   0 260708
  avg:   26.070800
  avg time:			 1.00521e-008


method 2:
  TimeGetTime()  10000 times
  tot:   0 1420712
  avg:   142.071200
  avg time:			 5.47785e-008



method 3:
  Pentium internal high-freq cntr()  10000 times
  tot:   0 840856
  avg:   84.085600
  avg time:			 3.24209e-008

-----

I've left out the data for less than 10,000 iterations for sake of length;
the averages were similar for these cases (and I ran the test a couple times
with similar results).

It looks like GetTickCount is the fastest, at least for this test setup on
my machine.  Am I reading the results wrong?  I would have expected RDTSC to
be the fastest.  What could this mean?  Is this because of the cache effects
that Jon mentioned?  Just curious.  :-)

Tbanks!

Carl


------------------------------------------
Tuesday, February 10, 2004, 4:44:01 PM, you wrote:


> Hi Carl,


> Have a search around nVidia's developer website
> (http://developer.nvidia.com), IIRC they did presentation surveying each
of
> the major timing methods with regard to using them to profile code and the
> advantages and disadvantages plus latencies of each.



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
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: Re[4]: [GD-Windows] Performance timing

[Donavon K. <DKe...@io...>]

GetTickCount is just a tiny function that reads a variable that's
incremented in the system timer interrupt handler.  In situations where this
timer is useful, the extra speed is insignificant.


-----Original Message-----
From: Carl Bevil [mailto:car...@ya...]
Sent: Tuesday, February 10, 2004 7:27 PM
To: Simon O'Connor
Subject: Re[4]: [GD-Windows] Performance timing


Did that, and they have a nice utility that performs some timing tests on
your machine and spits out a report (it's at
http://developer.nvidia.com/object/timer_function_performance.html).

The report had interesting results:

-----

QueryPerformanceFrequency() freq  = 0  2593560000 


method 0:
  QueryPerfCntr..()  10000 times
  tot:   0 6720740
  avg:   672.074000
  avg time:			 2.59132e-007


method 1:
  GetTickCount()  10000 times
  tot:   0 260708
  avg:   26.070800
  avg time:			 1.00521e-008


method 2:
  TimeGetTime()  10000 times
  tot:   0 1420712
  avg:   142.071200
  avg time:			 5.47785e-008



method 3:
  Pentium internal high-freq cntr()  10000 times
  tot:   0 840856
  avg:   84.085600
  avg time:			 3.24209e-008

-----

I've left out the data for less than 10,000 iterations for sake of length;
the averages were similar for these cases (and I ran the test a couple times
with similar results).

It looks like GetTickCount is the fastest, at least for this test setup on
my machine.  Am I reading the results wrong?  I would have expected RDTSC to
be the fastest.  What could this mean?  Is this because of the cache effects
that Jon mentioned?  Just curious.  :-)

Tbanks!

Carl


------------------------------------------
Tuesday, February 10, 2004, 4:44:01 PM, you wrote:


> Hi Carl,


> Have a search around nVidia's developer website
> (http://developer.nvidia.com), IIRC they did presentation surveying each
of
> the major timing methods with regard to using them to profile code and the
> advantages and disadvantages plus latencies of each.



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
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] Performance timing

[chaac <ch...@ni...>]

tweety wrote:

> Same here; this was what I was talking about.
> Besides, rdtsc and queryperformancetimer has some very nasty sincronization
> problems with multiple processors (they give the time slightly different
> wether the code is run on different processors). 
> Good old GetTickCount does its job :)

Hi,

But then again, if I remember correcly, GetTickCount goes in steps of 
32ms. If you need more accuracy, you are out of the game here.

And if you are just profiling on your development machine or at machine 
you can reach or otherwise know some details about it. You can quite 
easily use other measurement methods also.

In some cases how fast to get time is not the issue, but accuracy of 
delta time is.

Thanks,
Vesa Jääskeläinen

RE: Re[4]: [GD-Windows] Performance timing

[tweety <mi...@sy...>]

Same here; this was what I was talking about.
Besides, rdtsc and queryperformancetimer has some very nasty sincronization
problems with multiple processors (they give the time slightly different
wether the code is run on different processors). 
Good old GetTickCount does its job :)

----------------------------------
Peace and love,
Tweety
mi...@sy... - twe...@us...
YahooID: tweety_04_01

 

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of Carl
Bevil
Sent: February 10, 2004 8:27 PM
To: Simon O'Connor
Subject: Re[4]: [GD-Windows] Performance timing

Did that, and they have a nice utility that performs some timing tests on
your machine and spits out a report (it's at
http://developer.nvidia.com/object/timer_function_performance.html).

The report had interesting results:

-----

QueryPerformanceFrequency() freq  = 0  2593560000 


method 0:
  QueryPerfCntr..()  10000 times
  tot:   0 6720740
  avg:   672.074000
  avg time:			 2.59132e-007


method 1:
  GetTickCount()  10000 times
  tot:   0 260708
  avg:   26.070800
  avg time:			 1.00521e-008


method 2:
  TimeGetTime()  10000 times
  tot:   0 1420712
  avg:   142.071200
  avg time:			 5.47785e-008



method 3:
  Pentium internal high-freq cntr()  10000 times
  tot:   0 840856
  avg:   84.085600
  avg time:			 3.24209e-008

-----

I've left out the data for less than 10,000 iterations for sake of length;
the averages were similar for these cases (and I ran the test a couple times
with similar results).

It looks like GetTickCount is the fastest, at least for this test setup on
my machine.  Am I reading the results wrong?  I would have expected RDTSC to
be the fastest.  What could this mean?  Is this because of the cache effects
that Jon mentioned?  Just curious.  :-)

Tbanks!

Carl


------------------------------------------
Tuesday, February 10, 2004, 4:44:01 PM, you wrote:


> Hi Carl,


> Have a search around nVidia's developer website 
> (http://developer.nvidia.com), IIRC they did presentation surveying 
> each of the major timing methods with regard to using them to profile 
> code and the advantages and disadvantages plus latencies of each.



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open
Tools Development and Integration See the breadth of Eclipse activity.
February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=555