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

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

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

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.

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

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

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'. =3D)

Brian

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

[Simon O'C. <si...@sc...>]

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.


If you decide to use any of the Windows OS timing functions, be sure to
search the KnowledgeBase on MSDN for the function names. There are a number
of known issues (many Jon has covered in his post already) detailed in the
KB; including which OSes and hardware the issues show up on and any known
work-arounds.

IIRC QueryPerformanceCounter() will perform its timing in different ways
depending on the OS version, whether SMP is in use, whether speed stepping
is present, what motherboard hardware is present etc. ISTR a post from one
of the MS guys on DirectXDev in about 1999 mentioning this (should still be
in the archives for that list).


Cheers,

Simon O'Connor
Programmer @ Acclaim
& Microsoft DirectX MVP  

> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Carl Bevil
> Sent: 11 February 2004 00:01
> To: Jon Watte
> Subject: Re[2]: [GD-Windows] Performance timing
> 
> Hi Jon,
> 
> > "Intel specific" as in specific to x86 architecture, specific to 
> > Windows, or specific to Intel chips?
> 
> Specific to Intel chips.  For some reason I had it in my head 
> that some of these methods only worked on "genuine Intel" 
> chips, but not on, say, AMD chips.
> 
> [...]
> > timeGetTime() and QueryPerformanceCounter() must go out on 
> the (I/O) 
> > bus, and thus take like a microsecond each. RDTSC is just a 
> flush and 
> > register read; on the order of 30-100 CPU clocks depending 
> on how anal 
> > you are about serializing when measuring. VASTLY preferrable :-)
> 
> Wow, thanks for this information.  More than I expected, and 
> very helpful!
> 
> Carl
> 
> 
> 
> -------------------------------------------------------
> 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
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.572 / Virus Database: 362 - Release Date: 27/01/2004
>  
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.572 / Virus Database: 362 - Release Date: 27/01/2004
 

RE: [GD-Windows] Loading new DLLs on old Windows

[Simon O'C. <si...@sc...>]

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
> 
> 
> 
> -------------------------------------------------------
> 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
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.572 / Virus Database: 362 - Release Date: 27/01/2004
>  
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.572 / Virus Database: 362 - Release Date: 27/01/2004
 

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

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

Hi Jon,

> "Intel specific" as in specific to x86 architecture, specific to Windows, or
> specific to Intel chips?

Specific to Intel chips.  For some reason I had it in my head that some of these methods only worked on "genuine Intel" chips, but not on, say, AMD chips.

[...]
> timeGetTime() and QueryPerformanceCounter() must go out on the (I/O) bus,
> and thus take like a microsecond each. RDTSC is just a flush and register
> read; on the order of 30-100 CPU clocks depending on how anal you are about
> serializing when measuring. VASTLY preferrable :-)

Wow, thanks for this information.  More than I expected, and very helpful!

Carl

RE: [GD-Windows] Performance timing

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

GetTickCount() has the same problem as timeGetTime(). RDTSC is MUCH faster.

Cheers,

			/ h+


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
tweety
Sent: Tuesday, February 10, 2004 12:43 PM
To: gam...@li...
Subject: RE: [GD-Windows] Performance timing


I preffer gettickcount, by far the fastest way to get the time, besides
rdtsc. And even so, they're very comparable and you don't need to do the
tick->milisecond transformation. It has a decent enough resolution, too.

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



-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of Jon
Watte
Sent: February 10, 2004 2:21 PM
To: gam...@li...
Subject: RE: [GD-Windows] Performance timing


"Intel specific" as in specific to x86 architecture, specific to Windows, or
specific to Intel chips?

RDTSC is available on all x86 CPUs, from Intel or elsewhere, from the
Pentium generation onwards. I e, you can't be a "level 5 CPU" without RDTSC.
That's back when CPUs were running in the 100-200 MHz range, so I think it's
safe to assume presence (we do, for sure).

QueryPerformanceCounter() typically reads some clock counters in the north
bridge (PCI bus clocks? I forget). However, it's a Windows specific call,
and does not exist on UNIX (where you can use gettimeofday() and variants,
instead) of Macs.

Speaking of Macs (and GameCube), the PPC has a time stamp counter very
similar to the time stamp counter on x86, so the concept is portable, even
though the specific assembly is not.

Now, the problems with all three of these methods:

timeGetTime() will sometimes "lose" about 20 milliseconds. This happens
quite frequently under heavy bus and interrupt load, such as when running a
computer game that taxes the IO subsystems and not just the CPU.

QueryPerformanceCounter() will sometimes "jump ahead" by a fair bit, on the
order of 1-3 seconds. Again, this happens under heavy system load, but is
less frequent than the timeGetTime() slip.

RDTSC is fine on desktops, but SpeedStep CPUs that vary their CPU speed from
moment to moment will screw you over here. Our solution is to spawn busywork
to keep the CPU busy, fooling the system into not slowing down the CPU.
However, the Pentium-M has Extra Trickiness in this area, which they
threaten might make it into future desktop chips (like the Extreme Edition)
as well.

So, if you want a perfectly stable clock, you have to run all three, and
have 'em vote.

For micro-benchmarks, we use RDTSC, carefully controlled for cache effects.

timeGetTime() and QueryPerformanceCounter() must go out on the (I/O) bus,
and thus take like a microsecond each. RDTSC is just a flush and register
read; on the order of 30-100 CPU clocks depending on how anal you are about
serializing when measuring. VASTLY preferrable :-)

Cheers,

			/ h+



-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of Carl
Bevil
Sent: Tuesday, February 10, 2004 10:17 AM
To: gam...@li...
Subject: [GD-Windows] Performance timing


Hello all.  I'm wondering what people use these days for timing their code.
From what I know, timeGetTime is not so good.  In the past I've used
QueryPerformanceCounter, and I remember an old Game Developer article about
RDTSC timing.  But I think at least one of those is Intel-specific.  Are
there better options I haven't heard about?

Thanks,

Carl



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



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



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

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

I preffer gettickcount, by far the fastest way to get the time, besides
rdtsc. And even so, they're very comparable and you don't need to do the
tick->milisecond transformation. It has a decent enough resolution, too.

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

 

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of Jon
Watte
Sent: February 10, 2004 2:21 PM
To: gam...@li...
Subject: RE: [GD-Windows] Performance timing


"Intel specific" as in specific to x86 architecture, specific to Windows, or
specific to Intel chips?

RDTSC is available on all x86 CPUs, from Intel or elsewhere, from the
Pentium generation onwards. I e, you can't be a "level 5 CPU" without RDTSC.
That's back when CPUs were running in the 100-200 MHz range, so I think it's
safe to assume presence (we do, for sure).

QueryPerformanceCounter() typically reads some clock counters in the north
bridge (PCI bus clocks? I forget). However, it's a Windows specific call,
and does not exist on UNIX (where you can use gettimeofday() and variants,
instead) of Macs.

Speaking of Macs (and GameCube), the PPC has a time stamp counter very
similar to the time stamp counter on x86, so the concept is portable, even
though the specific assembly is not.

Now, the problems with all three of these methods:

timeGetTime() will sometimes "lose" about 20 milliseconds. This happens
quite frequently under heavy bus and interrupt load, such as when running a
computer game that taxes the IO subsystems and not just the CPU.

QueryPerformanceCounter() will sometimes "jump ahead" by a fair bit, on the
order of 1-3 seconds. Again, this happens under heavy system load, but is
less frequent than the timeGetTime() slip.

RDTSC is fine on desktops, but SpeedStep CPUs that vary their CPU speed from
moment to moment will screw you over here. Our solution is to spawn busywork
to keep the CPU busy, fooling the system into not slowing down the CPU.
However, the Pentium-M has Extra Trickiness in this area, which they
threaten might make it into future desktop chips (like the Extreme Edition)
as well.

So, if you want a perfectly stable clock, you have to run all three, and
have 'em vote.

For micro-benchmarks, we use RDTSC, carefully controlled for cache effects.

timeGetTime() and QueryPerformanceCounter() must go out on the (I/O) bus,
and thus take like a microsecond each. RDTSC is just a flush and register
read; on the order of 30-100 CPU clocks depending on how anal you are about
serializing when measuring. VASTLY preferrable :-)

Cheers,

			/ h+



-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of Carl
Bevil
Sent: Tuesday, February 10, 2004 10:17 AM
To: gam...@li...
Subject: [GD-Windows] Performance timing


Hello all.  I'm wondering what people use these days for timing their code.
From what I know, timeGetTime is not so good.  In the past I've used
QueryPerformanceCounter, and I remember an old Game Developer article about
RDTSC timing.  But I think at least one of those is Intel-specific.  Are
there better options I haven't heard about?

Thanks,

Carl



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



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

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

"Intel specific" as in specific to x86 architecture, specific to Windows, or
specific to Intel chips?

RDTSC is available on all x86 CPUs, from Intel or elsewhere, from the
Pentium generation onwards. I e, you can't be a "level 5 CPU" without RDTSC.
That's back when CPUs were running in the 100-200 MHz range, so I think it's
safe to assume presence (we do, for sure).

QueryPerformanceCounter() typically reads some clock counters in the north
bridge (PCI bus clocks? I forget). However, it's a Windows specific call,
and does not exist on UNIX (where you can use gettimeofday() and variants,
instead) of Macs.

Speaking of Macs (and GameCube), the PPC has a time stamp counter very
similar to the time stamp counter on x86, so the concept is portable, even
though the specific assembly is not.

Now, the problems with all three of these methods:

timeGetTime() will sometimes "lose" about 20 milliseconds. This happens
quite frequently under heavy bus and interrupt load, such as when running a
computer game that taxes the IO subsystems and not just the CPU.

QueryPerformanceCounter() will sometimes "jump ahead" by a fair bit, on the
order of 1-3 seconds. Again, this happens under heavy system load, but is
less frequent than the timeGetTime() slip.

RDTSC is fine on desktops, but SpeedStep CPUs that vary their CPU speed from
moment to moment will screw you over here. Our solution is to spawn busywork
to keep the CPU busy, fooling the system into not slowing down the CPU.
However, the Pentium-M has Extra Trickiness in this area, which they
threaten might make it into future desktop chips (like the Extreme Edition)
as well.

So, if you want a perfectly stable clock, you have to run all three, and
have 'em vote.

For micro-benchmarks, we use RDTSC, carefully controlled for cache effects.

timeGetTime() and QueryPerformanceCounter() must go out on the (I/O) bus,
and thus take like a microsecond each. RDTSC is just a flush and register
read; on the order of 30-100 CPU clocks depending on how anal you are about
serializing when measuring. VASTLY preferrable :-)

Cheers,

			/ h+



-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Carl Bevil
Sent: Tuesday, February 10, 2004 10:17 AM
To: gam...@li...
Subject: [GD-Windows] Performance timing


Hello all.  I'm wondering what people use these days for timing their code.
From what I know, timeGetTime is not so good.  In the past I've used
QueryPerformanceCounter, and I remember an old Game Developer article about
RDTSC timing.  But I think at least one of those is Intel-specific.  Are
there better options I haven't heard about?

Thanks,

Carl



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

[GD-Windows] Performance timing

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

Hello all.  I'm wondering what people use these days for timing their code.  From what I know, timeGetTime is not so good.  In the past I've used QueryPerformanceCounter, and I remember an old Game Developer article about RDTSC timing.  But I think at least one of those is Intel-specific.  Are there better options I haven't heard about?

Thanks,

Carl

[GD-Windows] Loading new DLLs on old Windows

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

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: [GD-Windows] How to determine total physical memory available ?

[Simon O'C. <si...@sc...>]

A follow up in case anyone still needs to do this:


I've had a play around with WMI this weekend and it is indeed the way to =
go
for getting this kind of thing on 2K/XP machines. Win32_PhysicalMemory =
gets
its info from the system BIOS.


For simplicity I've been using VB/VBScript, but the C++ method is the =
same,
albeit with a lot of extra COM handling.=20


Here's a simple VBS example of returning true physical memory info (to =
run
it, copy what's below into a text file and give the file a .VBS =
extension):

For Each Mem in =
GetObject("winmgmts:").InstancesOf("Win32_PhysicalMemory")
  WScript.Echo("Bank=3D" & Mem.BankLabel & " Size=3D" & Mem.Capacity /
(1024*1024) & "MB")
Next


Cheers,

Simon O'Connor
Programmer @ Acclaim
& Microsoft DirectX MVP=20


> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...] On=20
> Behalf Of Simon O'Connor
> Sent: 27 January 2004 00:38
> To: gam...@li...
> Subject: RE: [GD-Windows] How to determine total physical=20
> memory available ?
>=20
>=20
> Although I've not tried it myself, WMI (assuming 2K/XP) seems=20
> to have a few things for getting lots of information about=20
> the hardware - not sure how much of that info is available on=20
> all systems though - I'll give it a try when I get a free=20
> moment - there's a lot of very intriguing stuff you can query=20
> in there such as:
>=20
> "Win32_PhysicalMemoryArray"
> "Win32_PhysicalMemoryLocation"
> "Win32_PhysicalMemory"
>=20
> Which seem to have stuff as hardcore as the chip package=20
> type, speed in ns, chip manufacturer, bank layout.
>=20
> Simon O'Connor
> Programmer @ Acclaim
> & Microsoft DirectX MVP =20
>=20
> > -----Original Message-----
> > From: gam...@li...
> > [mailto:gam...@li...]=20
> On Behalf Of=20
> > Yannick Letourneau
> > Sent: 26 January 2004 21:15
> > To: gam...@li...
> > Subject: RE: [GD-Windows] How to determine total physical memory=20
> > available ?
> >=20
> > Both ;-)
> >=20
> > Yeah, right now I'm doing as you're suggesting but I still=20
> would like=20
> > to display the right value to the user.  I guess I'll have to live=20
> > with it unless I find a better way.
> >=20
> > Yannick
> >=20
> > -----Original Message-----
> > From: Simon O'Connor [mailto:si...@sc...]
> > Sent: Monday, January 26, 2004 4:07 PM
> > To: gam...@li...
> > Subject: RE: [GD-Windows] How to determine total physical memory=20
> > available ?
> >=20
> >=20
> >=20
> > BTW:
> >=20
> > Do you actually need the value for presentation to the user?
> >=20
> > Or is this to determine whether the user has enough=20
> physical memory to=20
> > run your game or use advanced memory hungry features?
> >=20
> >=20
> > If it's the latter, then you should only really use the value as a=20
> > rough guide (much the same as with total video memory), e.g.:
> >=20
> > if (memorysize < 500000000)
> > {
> >   alert( "sorry this game requires a minimum of 512MB" );
> >   return;
> > }
> >=20
> > m_enableMemoryHoggingFeature =3D false;
> >=20
> > if (memorysize >=3D 1000000000)
> > {
> >   m_enableMemoryHoggingFeature =3D true; }
> >=20
> >=20
> > Of course, you can never assume all of that physical memory=20
> is yours=20
> > to play with anyway (kernel allocations, AGP reservation etc).
> >=20
> >=20
> > Simon O'Connor
> > Programmer @ Acclaim
> > & Microsoft DirectX MVP=20
> >=20
> > > -----Original Message-----
> > > From: gam...@li...
> > > [mailto:gam...@li...]=20
> > On Behalf Of=20
> > > Yannick Letourneau
> > > Sent: 26 January 2004 20:21
> > > To: gam...@li...
> > > Subject: RE: [GD-Windows] How to determine total physical memory=20
> > > available ?
> > >=20
> > > Actually it would be a little more complicated since memory=20
> > can be a=20
> > > sum of different power of 2 (for example if you have one=20
> > memory chip=20
> > > of 128 MB and another of 64 MB totaling 192MB which is=20
> not power of=20
> > > 2).
> > >=20
> > > I'd rather not make this kind of assumption myself and let=20
> > the system=20
> > > give me the exact numbers ;-)
> > >=20
> > > -----Original Message-----
> > > From: Timur Davidenko [mailto:ti...@cr...]
> > > Sent: Monday, January 26, 2004 3:16 PM
> > > To: gam...@li...
> > > Subject: RE: [GD-Windows] How to determine total physical memory=20
> > > available ?
> > >=20
> > >=20
> > > I guess System Information tool just rounds this number=20
> to the next=20
> > > "reasonable" number.
> > > It knows that memory chips don't come in 1022Mb setups..
> > > So it`s quite easy to round number you get to closest power of 2..
> > >=20
> > > _____________________
> > > Timur Davidenko.
> > > Crytek (http://www.crytek.com)
> > >=20
> > > -----Original Message-----
> > > From: Yannick Letourneau [mailto:yle...@ub...]
> > > Sent: Monday, January 26, 2004 8:47 PM
> > > To: gam...@li...
> > > Subject: [GD-Windows] How to determine total physical=20
> > memory available=20
> > > ?
> > >=20
> > > I need to determine how much memory is installed on the=20
> > user's system=20
> > > somehow.
> > >=20
> > > I used GlobalMemoryStatus but the values returned in the member=20
> > > dwTotalPhys is always underestimating a bit.  For example=20
> on my dev=20
> > > machine it returns
> > > 1022 MB although I have 1024 MB installed.  Same thing=20
> > happens on all=20
> > > systems I've tested.
> > >=20
> > > Same thing is reported in dxdiag.exe so they seem to use=20
> > that function=20
> > > as well.
> > >=20
> > > However, when I use the System Information tool in the=20
> > system tools of=20
> > > Windows, it correctly reports 1024 MB.
> > >=20
> > > So anyone knows how I can get the exact information ?
> > >=20
> > > Yannick L=E9tourneau
> > > UBISOFT
> > >=20
> > >=20
> > >=20
> > > -------------------------------------------------------
> > > The SF.Net email is sponsored by EclipseCon 2004 Premiere=20
> > Conference=20
> > > on Open Tools Development and Integration See the breadth=20
> > of Eclipse=20
> > > 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_idU5
> > >=20
> > >=20
> > >=20
> > > -------------------------------------------------------
> > > The SF.Net email is sponsored by EclipseCon 2004 Premiere=20
> > Conference=20
> > > on Open Tools Development and Integration See the breadth=20
> > of Eclipse=20
> > > 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_idU5
> > >=20
> > >=20
> > > -------------------------------------------------------
> > > The SF.Net email is sponsored by EclipseCon 2004 Premiere=20
> > Conference=20
> > > on Open Tools Development and Integration See the breadth=20
> > of Eclipse=20
> > > 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_idU5
> > >=20
> > > ---
> > > Incoming mail is certified Virus Free.
> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > Version: 6.0.560 / Virus Database: 352 - Release Date: 08/01/2004
> > > =20
> > >=20
> >=20
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.560 / Virus Database: 352 - Release Date: 08/01/2004
> > =20
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004 Premiere=20
> > Conference on Open Tools Development and Integration See the=20
> > 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_idU5
> >=20
> >=20
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004 Premiere=20
> > Conference on Open Tools Development and Integration See the=20
> > 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_idU5
> >=20
> > ---
> > Incoming mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.560 / Virus Database: 352 - Release Date: 08/01/2004
> > =20
> >=20
>=20
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.560 / Virus Database: 352 - Release Date: 08/01/2004
> =20
>=20
>=20
>=20
> -------------------------------------------------------
> 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_idU5
>=20
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.560 / Virus Database: 352 - Release Date: 08/01/2004
> =20
>=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.572 / Virus Database: 362 - Release Date: 27/01/2004
=20

[GD-Windows] Faking Input on Clients

[Eric M. <ema...@um...>]

Hello All,
  I'm really stuck on this one and can't seem to find a good answer on the
web. I have several clients and one server computer. The clients are all
running the same game/app/demo/whatever. I would like to capture the input
from the control computer (not a problem), send it to each client (not a
problem), and then simulate the keyboard and mouse events on each client as
if a local user did them. (big problem) For a little context, each client
renders a separate screen and I want to synchronize their input so that all
screens line up. I can do this without a problem running my own applications
since the app is setup to handle external input streams. However, I can't
seem to find a way to do it for a generic demo or game. I spotted the
SendInput() command, but that seems to only work on the current window. Any
insight would be appreciated.

Thanks

E.

P.S. All are running XP.

Re: [GD-Windows] Going fullscreen

[Eero P. <epa...@ko...>]

Simon O'Connor wrote:

> If you use CreateWindowEx() instead of CreateWindow(), there is am extended
> style called WS_EX_TOPMOST which should get you more reliable results.
> 

Thanks, that looks promising. Looking at the MSDN docs, it appears I could get
the same effect using SetWindowPos?  (Checking this because it might
be easier to integrate to freeglut)

> You probably also want to add some extra code to handle cases where your
> window isn't the focus though so that things like Alt-Tab work don't crash
> your program or reduce the usability of the OS. This can be as simple as
> handling the WM_ACTIVATE message in your message procedure and keeping an
> "am_I_the_active_app" flag to decide whether to update your stuff.
> 
> Returning HTCLIENT for WM_NCHITTEST messages when in fullscreen is a good
> idea too. That fools Windows into not detecting clicks on non-client areas
> of the window such as the menu at the top left.
> 

I will see how the TOPMOST change affects Alt-tab behavior (currently it works
  ok). For this specific case there there wont be  a significant problem anyways,
the end user won't probably even have access to the keyboard/mouse...



		Eero

RE: [GD-Windows] Going fullscreen

[Simon O'C. <si...@sc...>]

If you use CreateWindowEx() instead of CreateWindow(), there is am extended
style called WS_EX_TOPMOST which should get you more reliable results.

You probably also want to add some extra code to handle cases where your
window isn't the focus though so that things like Alt-Tab work don't crash
your program or reduce the usability of the OS. This can be as simple as
handling the WM_ACTIVATE message in your message procedure and keeping an
"am_I_the_active_app" flag to decide whether to update your stuff.

Returning HTCLIENT for WM_NCHITTEST messages when in fullscreen is a good
idea too. That fools Windows into not detecting clicks on non-client areas
of the window such as the menu at the top left.


Simon O'Connor
Programmer @ Acclaim
& Microsoft DirectX MVP  

> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Eero Pajarre
> Sent: 01 February 2004 15:35
> To: gam...@li...
> Subject: [GD-Windows] Going fullscreen
> 
> 
> I am setting up my program using the freeglut library, but I 
> have one problem. My program starts up in a fullscreen window 
> using the (free)glut gamemode. The problem is: sometimes the 
> Windows (XP) system/menu/status bar at the bottom of the 
> screen stays on top of my fullscreen window. In addition to 
> the visible problem, this causes problem for my sound system, 
> as apparently requires that my window must be the one "with focus".
> (If there are other windows on screen, they will also be on 
> top of my gamemode window, when the problem happens)
> 
> The freeglut library seems to enter gamemode, by first 
> setting the requested display parameters, and then creating 
> the new window using the following flags:
>          flags = WS_POPUP | WS_CLIPSIBLINGS | WS_CLIPCHILDREN 
> | WS_VISIBLE;
> 
> 
> I am currently using Nvidia display cards, and my desktop and 
> fullscreen window is 2048x768 pixels, spanning both of the 
> video outputs of the card.
> 
> Any ideas on how to make freeglut behave more reliably?
> Alternatively, is there a function which I could call to 
> force my window to be on top of the window stack?
> 
> 
> 
> 		Eero
> 
> 
> 
> 
> -------------------------------------------------------
> 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
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.572 / Virus Database: 362 - Release Date: 27/01/2004
>  
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.572 / Virus Database: 362 - Release Date: 27/01/2004
 

[GD-Windows] Going fullscreen

[Eero P. <epa...@ko...>]

I am setting up my program using the freeglut library,
but I have one problem. My program starts up in a fullscreen
window using the (free)glut gamemode. The problem is: sometimes
the Windows (XP) system/menu/status bar at the bottom of the
screen stays on top of my fullscreen window. In addition
to the visible problem, this causes problem for my sound system,
as apparently requires that my window must be the one "with focus".
(If there are other windows on screen, they will also be on top
of my gamemode window, when the problem happens)

The freeglut library seems to enter gamemode, by first setting the
requested display parameters, and then creating the new window using the
following flags:
         flags = WS_POPUP | WS_CLIPSIBLINGS | WS_CLIPCHILDREN | WS_VISIBLE;


I am currently using Nvidia display cards, and my desktop and
fullscreen window is 2048x768 pixels, spanning both of the video
outputs of the card.

Any ideas on how to make freeglut behave more reliably?
Alternatively, is there a function which I could call to force
my window to be on top of the window stack?



		Eero

[GD-Windows] RE: DX8 Vertex Shader Fixed Function emulation

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

First, sorry to use the wrong title initially, and thanks for the answer!

The second link (PDF) seems to be NV_vertex_program and claims it's a work
in progress, and looking at the code, I agree :-) Although the PDF declares
that a final version is forthcoming,  I couldn't find it, so I suppose that
project was dropped. I can translate, but I already have my own shaders --
the gist of my request is to get "another implementation" to look at for
comparision.

I'll run the first link through CG and see what comes out; that might be
more like what I'm looking for.

Cheers,

			/ h+


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Simon O'Connor
Sent: Friday, January 30, 2004 8:24 PM
To: gam...@li...
Subject: RE: [GD-Windows] DLL location



There are a few on the nVidia site that may be of interest:

http://developer.nvidia.com/object/cg_fixed_function.html

http://developer.nvidia.com/object/fixed_function_pipeline.html

I'm sure (ISTR) there are are more direct pages too...

Simon O'Connor
Programmer @ Acclaim
& Microsoft DirectX MVP

RE: [GD-Windows] DLL location

[Simon O'C. <si...@sc...>]

There are a few on the nVidia site that may be of interest:

http://developer.nvidia.com/object/cg_fixed_function.html

http://developer.nvidia.com/object/fixed_function_pipeline.html

I'm sure (ISTR) there are are more direct pages too...

Simon O'Connor
Programmer @ Acclaim
& Microsoft DirectX MVP  

> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Jon Watte
> Sent: 31 January 2004 01:26
> To: gam...@li...
> Subject: [GD-Windows] DLL location
> 
> 
> Does anyone know a reference for standard vertex lighting in 
> DirectX 8 level vertex shader code? It seems like it should 
> be available on MSDN, or perhaps on one of many good 
> reference sites out there, but I can't find any! The closest 
> I have come is the ARB_vertex_program OpenGL specification, 
> which contains code for many pieces of the standard OpenGL 
> lighting equation.
> (Yes, I can translate, and also write my own, but I'd like a 
> reference)
> 
> Cheers,
> 
> 			/ h+
> 
> 
> 
> -------------------------------------------------------
> 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
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.572 / Virus Database: 362 - Release Date: 27/01/2004
>  
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.572 / Virus Database: 362 - Release Date: 27/01/2004
 

[GD-Windows] DLL location

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

Does anyone know a reference for standard vertex lighting in DirectX 8 level
vertex shader code? It seems like it should be available on MSDN, or perhaps
on one of many good reference sites out there, but I can't find any! The
closest I have come is the ARB_vertex_program OpenGL specification, which
contains code for many pieces of the standard OpenGL lighting equation.
(Yes, I can translate, and also write my own, but I'd like a reference)

Cheers,

			/ h+

RE: [GD-Windows] DLL location

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

These days, Microsoft recommends that each application install the DLLs with
the EXE. The reason for this is that DLL versioning problems have bit too
many programs too many times.

For an ActiveX control or .NET Assembly module, that's not doable, of
course, although the .NET hierarchy seems to have space for third party
code, and ActiveX controls can go in Program Files/YourNameHere and use
RegSvr32 to tell the system where to find it.

Cheers,

			/ h+


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Pierre Terdiman
Sent: Tuesday, January 27, 2004 8:16 AM
To: gam...@li...
Subject: [GD-Windows] DLL location


Hi,

Is there a standard place where third party libraries can store their DLLs ?

We want to release a SDK whose DLLs should be accessible by both the demos
(exes in their own \demos directory) and the programmers compiling the
examples or doing their own.

The obvious solution is to copy our DLLs in the System or System32 directory
at installation time, but it doesn't sound very nice to pollute that place
with extra DLLs (it's messy enough...)

Is it better to store the DLLs in some private directory (say Program
Files\MyProduct\MyDlls), and add that directory to the path env variable ?
If yes, is there a recommended way to do that ?

Else, is there an "official" way to do that ?

Pierre




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

[GD-Windows] DLL location

[Pierre T. <pie...@no...>]

Hi,

Is there a standard place where third party libraries can store their DLLs ?

We want to release a SDK whose DLLs should be accessible by both the demos
(exes in their own \demos directory) and the programmers compiling the
examples or doing their own.

The obvious solution is to copy our DLLs in the System or System32 directory
at installation time, but it doesn't sound very nice to pollute that place
with extra DLLs (it's messy enough...)

Is it better to store the DLLs in some private directory (say Program
Files\MyProduct\MyDlls), and add that directory to the path env variable ?
If yes, is there a recommended way to do that ?

Else, is there an "official" way to do that ?

Pierre

RE: [GD-Windows] How to determine total physical memory available ?

[Simon O'C. <si...@sc...>]

Although I've not tried it myself, WMI (assuming 2K/XP) seems to have a =
few
things for getting lots of information about the hardware - not sure how
much of that info is available on all systems though - I'll give it a =
try
when I get a free moment - there's a lot of very intriguing stuff you =
can
query in there such as:

"Win32_PhysicalMemoryArray"
"Win32_PhysicalMemoryLocation"
"Win32_PhysicalMemory"

Which seem to have stuff as hardcore as the chip package type, speed in =
ns,
chip manufacturer, bank layout.

Simon O'Connor
Programmer @ Acclaim
& Microsoft DirectX MVP =20

> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...] On=20
> Behalf Of Yannick Letourneau
> Sent: 26 January 2004 21:15
> To: gam...@li...
> Subject: RE: [GD-Windows] How to determine total physical=20
> memory available ?
>=20
> Both ;-)
>=20
> Yeah, right now I'm doing as you're suggesting but I still=20
> would like to display the right value to the user.  I guess=20
> I'll have to live with it unless I find a better way.
>=20
> Yannick
>=20
> -----Original Message-----
> From: Simon O'Connor [mailto:si...@sc...]
> Sent: Monday, January 26, 2004 4:07 PM
> To: gam...@li...
> Subject: RE: [GD-Windows] How to determine total physical=20
> memory available ?
>=20
>=20
>=20
> BTW:
>=20
> Do you actually need the value for presentation to the user?
>=20
> Or is this to determine whether the user has enough physical=20
> memory to run your game or use advanced memory hungry features?
>=20
>=20
> If it's the latter, then you should only really use the value=20
> as a rough guide (much the same as with total video memory), e.g.:
>=20
> if (memorysize < 500000000)
> {
>   alert( "sorry this game requires a minimum of 512MB" );
>   return;
> }
>=20
> m_enableMemoryHoggingFeature =3D false;
>=20
> if (memorysize >=3D 1000000000)
> {
>   m_enableMemoryHoggingFeature =3D true;
> }
>=20
>=20
> Of course, you can never assume all of that physical memory=20
> is yours to play with anyway (kernel allocations, AGP=20
> reservation etc).
>=20
>=20
> Simon O'Connor
> Programmer @ Acclaim
> & Microsoft DirectX MVP=20
>=20
> > -----Original Message-----
> > From: gam...@li...
> > [mailto:gam...@li...]=20
> On Behalf Of=20
> > Yannick Letourneau
> > Sent: 26 January 2004 20:21
> > To: gam...@li...
> > Subject: RE: [GD-Windows] How to determine total physical memory=20
> > available ?
> >=20
> > Actually it would be a little more complicated since memory=20
> can be a=20
> > sum of different power of 2 (for example if you have one=20
> memory chip=20
> > of 128 MB and another of 64 MB totaling 192MB which is not power of=20
> > 2).
> >=20
> > I'd rather not make this kind of assumption myself and let=20
> the system=20
> > give me the exact numbers ;-)
> >=20
> > -----Original Message-----
> > From: Timur Davidenko [mailto:ti...@cr...]
> > Sent: Monday, January 26, 2004 3:16 PM
> > To: gam...@li...
> > Subject: RE: [GD-Windows] How to determine total physical memory=20
> > available ?
> >=20
> >=20
> > I guess System Information tool just rounds this number to the next=20
> > "reasonable" number.
> > It knows that memory chips don't come in 1022Mb setups..
> > So it`s quite easy to round number you get to closest power of 2..
> >=20
> > _____________________
> > Timur Davidenko.
> > Crytek (http://www.crytek.com)
> >=20
> > -----Original Message-----
> > From: Yannick Letourneau [mailto:yle...@ub...]
> > Sent: Monday, January 26, 2004 8:47 PM
> > To: gam...@li...
> > Subject: [GD-Windows] How to determine total physical=20
> memory available=20
> > ?
> >=20
> > I need to determine how much memory is installed on the=20
> user's system=20
> > somehow.
> >=20
> > I used GlobalMemoryStatus but the values returned in the member=20
> > dwTotalPhys is always underestimating a bit.  For example on my dev=20
> > machine it returns
> > 1022 MB although I have 1024 MB installed.  Same thing=20
> happens on all=20
> > systems I've tested.
> >=20
> > Same thing is reported in dxdiag.exe so they seem to use=20
> that function=20
> > as well.
> >=20
> > However, when I use the System Information tool in the=20
> system tools of=20
> > Windows, it correctly reports 1024 MB.
> >=20
> > So anyone knows how I can get the exact information ?
> >=20
> > Yannick L=E9tourneau
> > UBISOFT
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004 Premiere=20
> Conference=20
> > on Open Tools Development and Integration See the breadth=20
> of Eclipse=20
> > 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_idU5
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004 Premiere=20
> Conference=20
> > on Open Tools Development and Integration See the breadth=20
> of Eclipse=20
> > 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_idU5
> >=20
> >=20
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004 Premiere=20
> Conference=20
> > on Open Tools Development and Integration See the breadth=20
> of Eclipse=20
> > 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_idU5
> >=20
> > ---
> > Incoming mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.560 / Virus Database: 352 - Release Date: 08/01/2004
> > =20
> >=20
>=20
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.560 / Virus Database: 352 - Release Date: 08/01/2004
> =20
>=20
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004 Premiere=20
> Conference on Open Tools Development and Integration See the=20
> 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_idU5
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004 Premiere=20
> Conference on Open Tools Development and Integration See the=20
> 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_idU5
>=20
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.560 / Virus Database: 352 - Release Date: 08/01/2004
> =20
>=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.560 / Virus Database: 352 - Release Date: 08/01/2004
=20

RE: [GD-Windows] How to determine total physical memory available ?

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

I'm pretty sure that's not what it's doing. DRAM comes in 1 MB modules, and
2MB modules, and 4 MB modules, and ...

There is no law that memory comes installed in powers of two, and in fact,
two out of my five machines have non-power-of-two configurations (384 and
768).

Note that some machines set aside more memory for frame buffer use (Intel
Extreme, etc) -- it's un-clear whether you'd WANT to count this towards
available memory. If the machine has 256 MB of RAM, but 64 MB of that is
taken up for framebuffer and texture memory, then you're really running on a
192 MB machine for all intents and purposes, with a 64 MB graphics card.
Except the graphics card and CPU fight for the single memory bus, causing
slower performance than you'd otherwise expect out of the "rated" memory
subsystem (i e DDR266 performs like PC133).

Cheers,

			/ h+


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Timur Davidenko
Sent: Monday, January 26, 2004 12:16 PM
To: gam...@li...
Subject: RE: [GD-Windows] How to determine total physical memory
available ?


I guess System Information tool just rounds this number to the next
"reasonable" number.
It knows that memory chips don't come in 1022Mb setups..
So it`s quite easy to round number you get to closest power of 2..

_____________________
Timur Davidenko.
Crytek (http://www.crytek.com)

-----Original Message-----
From: Yannick Letourneau [mailto:yle...@ub...]
Sent: Monday, January 26, 2004 8:47 PM
To: gam...@li...
Subject: [GD-Windows] How to determine total physical memory available ?

I need to determine how much memory is installed on the user's system
somehow.

I used GlobalMemoryStatus but the values returned in the member dwTotalPhys
is always underestimating a bit.  For example on my dev machine it returns
1022 MB although I have 1024 MB installed.  Same thing happens on all
systems I've tested.

Same thing is reported in dxdiag.exe so they seem to use that function as
well.

However, when I use the System Information tool in the system tools of
Windows, it correctly reports 1024 MB.

So anyone knows how I can get the exact information ?

Yannick Létourneau
UBISOFT



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



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

RE: [GD-Windows] How to determine total physical memory available ?

[Yannick L. <yle...@ub...>]

Both ;-)

Yeah, right now I'm doing as you're suggesting but I still would like =
to
display the right value to the user.  I guess I'll have to live with it
unless I find a better way.

Yannick

-----Original Message-----
From: Simon O'Connor [mailto:si...@sc...]
Sent: Monday, January 26, 2004 4:07 PM
To: gam...@li...
Subject: RE: [GD-Windows] How to determine total physical memory
available ?



BTW:

Do you actually need the value for presentation to the user?

Or is this to determine whether the user has enough physical memory to =
run
your game or use advanced memory hungry features?


If it's the latter, then you should only really use the value as a =
rough
guide (much the same as with total video memory), e.g.:

if (memorysize < 500000000)
{
  alert( "sorry this game requires a minimum of 512MB" );
  return;
}

m_enableMemoryHoggingFeature =3D false;

if (memorysize >=3D 1000000000)
{
  m_enableMemoryHoggingFeature =3D true;
}


Of course, you can never assume all of that physical memory is yours to =
play
with anyway (kernel allocations, AGP reservation etc).


Simon O'Connor
Programmer @ Acclaim
& Microsoft DirectX MVP=20

> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...] On=20
> Behalf Of Yannick Letourneau
> Sent: 26 January 2004 20:21
> To: gam...@li...
> Subject: RE: [GD-Windows] How to determine total physical=20
> memory available ?
>=20
> Actually it would be a little more complicated since memory=20
> can be a sum of different power of 2 (for example if you have=20
> one memory chip of 128 MB and another of 64 MB totaling 192MB=20
> which is not power of 2).
>=20
> I'd rather not make this kind of assumption myself and let=20
> the system give me the exact numbers ;-)
>=20
> -----Original Message-----
> From: Timur Davidenko [mailto:ti...@cr...]
> Sent: Monday, January 26, 2004 3:16 PM
> To: gam...@li...
> Subject: RE: [GD-Windows] How to determine total physical=20
> memory available ?
>=20
>=20
> I guess System Information tool just rounds this number to=20
> the next "reasonable" number.
> It knows that memory chips don't come in 1022Mb setups..
> So it`s quite easy to round number you get to closest power of 2..
>=20
> _____________________
> Timur Davidenko.
> Crytek (http://www.crytek.com)
>=20
> -----Original Message-----
> From: Yannick Letourneau [mailto:yle...@ub...]
> Sent: Monday, January 26, 2004 8:47 PM
> To: gam...@li...
> Subject: [GD-Windows] How to determine total physical memory=20
> available ?
>=20
> I need to determine how much memory is installed on the=20
> user's system somehow.
>=20
> I used GlobalMemoryStatus but the values returned in the=20
> member dwTotalPhys is always underestimating a bit.  For=20
> example on my dev machine it returns
> 1022 MB although I have 1024 MB installed.  Same thing=20
> happens on all systems I've tested.
>=20
> Same thing is reported in dxdiag.exe so they seem to use that=20
> function as well.
>=20
> However, when I use the System Information tool in the system=20
> tools of Windows, it correctly reports 1024 MB.
>=20
> So anyone knows how I can get the exact information ?
>=20
> Yannick L=E9tourneau
> UBISOFT
>=20
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004 Premiere=20
> Conference on Open Tools Development and Integration See the=20
> 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_idU5
>=20
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004 Premiere=20
> Conference on Open Tools Development and Integration See the=20
> 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_idU5
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004 Premiere=20
> Conference on Open Tools Development and Integration See the=20
> 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_idU5
>=20
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.560 / Virus Database: 352 - Release Date: 08/01/2004
> =20
>=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.560 / Virus Database: 352 - Release Date: 08/01/2004
=20



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

RE: [GD-Windows] How to determine total physical memory available ?

[Simon O'C. <si...@sc...>]

BTW:

Do you actually need the value for presentation to the user?

Or is this to determine whether the user has enough physical memory to =
run
your game or use advanced memory hungry features?


If it's the latter, then you should only really use the value as a rough
guide (much the same as with total video memory), e.g.:

if (memorysize < 500000000)
{
  alert( "sorry this game requires a minimum of 512MB" );
  return;
}

m_enableMemoryHoggingFeature =3D false;

if (memorysize >=3D 1000000000)
{
  m_enableMemoryHoggingFeature =3D true;
}


Of course, you can never assume all of that physical memory is yours to =
play
with anyway (kernel allocations, AGP reservation etc).


Simon O'Connor
Programmer @ Acclaim
& Microsoft DirectX MVP=20

> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...] On=20
> Behalf Of Yannick Letourneau
> Sent: 26 January 2004 20:21
> To: gam...@li...
> Subject: RE: [GD-Windows] How to determine total physical=20
> memory available ?
>=20
> Actually it would be a little more complicated since memory=20
> can be a sum of different power of 2 (for example if you have=20
> one memory chip of 128 MB and another of 64 MB totaling 192MB=20
> which is not power of 2).
>=20
> I'd rather not make this kind of assumption myself and let=20
> the system give me the exact numbers ;-)
>=20
> -----Original Message-----
> From: Timur Davidenko [mailto:ti...@cr...]
> Sent: Monday, January 26, 2004 3:16 PM
> To: gam...@li...
> Subject: RE: [GD-Windows] How to determine total physical=20
> memory available ?
>=20
>=20
> I guess System Information tool just rounds this number to=20
> the next "reasonable" number.
> It knows that memory chips don't come in 1022Mb setups..
> So it`s quite easy to round number you get to closest power of 2..
>=20
> _____________________
> Timur Davidenko.
> Crytek (http://www.crytek.com)
>=20
> -----Original Message-----
> From: Yannick Letourneau [mailto:yle...@ub...]
> Sent: Monday, January 26, 2004 8:47 PM
> To: gam...@li...
> Subject: [GD-Windows] How to determine total physical memory=20
> available ?
>=20
> I need to determine how much memory is installed on the=20
> user's system somehow.
>=20
> I used GlobalMemoryStatus but the values returned in the=20
> member dwTotalPhys is always underestimating a bit.  For=20
> example on my dev machine it returns
> 1022 MB although I have 1024 MB installed.  Same thing=20
> happens on all systems I've tested.
>=20
> Same thing is reported in dxdiag.exe so they seem to use that=20
> function as well.
>=20
> However, when I use the System Information tool in the system=20
> tools of Windows, it correctly reports 1024 MB.
>=20
> So anyone knows how I can get the exact information ?
>=20
> Yannick L=E9tourneau
> UBISOFT
>=20
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004 Premiere=20
> Conference on Open Tools Development and Integration See the=20
> 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_idU5
>=20
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004 Premiere=20
> Conference on Open Tools Development and Integration See the=20
> 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_idU5
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004 Premiere=20
> Conference on Open Tools Development and Integration See the=20
> 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_idU5
>=20
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.560 / Virus Database: 352 - Release Date: 08/01/2004
> =20
>=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.560 / Virus Database: 352 - Release Date: 08/01/2004
=20

RE: [GD-Windows] How to determine total physical memory available ?

[Simon O'C. <si...@sc...>]

Jeffrey Richter's excellent Programming Appplications for Windows (MS =
Press)
has the following to say about the missing memory in the physical total:

"The dwTotalPhys member indicates the total number of bytes of physical
memory (RAM) that exist. On this 128-MB Pentium II machine, this value =
is
133,677,056, which is just 540,672 bytes under 128 MB.
The reason GlobalMemoryStatus does not report the full 128 Mb is that =
the
system reserves some storage as a nonpaged pool during the boot process.
This memory is not even considered available to the kernel. The =
dwAvailPhys
member indicates the total number of bytes of physical memory available =
for
allocation."

> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...] On=20
> Behalf Of Carsten Orthbandt
> Sent: 26 January 2004 20:08
> To: gam...@li...
> Subject: RE: [GD-Windows] How to determine total physical=20
> memory available ?
>=20
> IIRC, GlobalMemoryStatus returns the actual amount of RAM=20
> minus the DOS-inherited 640 kB base memory.
> After actually checking that: Yep, add 640 kB (=3D655360 byte)=20
> to the value in xMS.dwTotalPhys and you got the real value.
> When doing anything of this kind, please consider using=20
> GlobalMemoryStatusEx on Win2k/XP systems. We're not that far=20
> from systems having the full 4GB space equipped.
>=20
> Carsten Orthbandt
> Founder + Development Director
> SEK SpieleEntwicklungsKombinat GmbH
> http://www.sek-ost.de
>=20
> Wenn ich Visionen habe, gehe ich zum Arzt. - Helmut Schmidt
> =20
>=20
> > -----Original Message-----
> > From: gam...@li...
> > [mailto:gam...@li...]=20
> On Behalf Of=20
> > Yannick Letourneau
> > Sent: Monday, January 26, 2004 8:47 PM
> > To: gam...@li...
> > Subject: [GD-Windows] How to determine total physical=20
> memory available=20
> > ?
> >=20
> >=20
> > I need to determine how much memory is installed on the=20
> user's system=20
> > somehow.
> >=20
> > I used GlobalMemoryStatus but the values returned in the member=20
> > dwTotalPhys is always underestimating a bit.  For example on my dev=20
> > machine it returns
> > 1022 MB although I have 1024 MB installed.  Same thing=20
> happens on all=20
> > systems I've tested.
> >=20
> > Same thing is reported in dxdiag.exe so they seem to use=20
> that function=20
> > as well.
> >=20
> > However, when I use the System Information tool in the=20
> system tools of=20
> > Windows, it correctly reports 1024 MB.
> >=20
> > So anyone knows how I can get the exact information ?
> >=20
> > Yannick L=E9tourneau
> > UBISOFT
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004 Premiere=20
> Conference=20
> > on Open Tools Development and Integration See the breadth=20
> of Eclipse=20
> > 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_idU5
> >=20
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004 Premiere=20
> Conference on Open Tools Development and Integration See the=20
> 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_idU5
>=20
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.560 / Virus Database: 352 - Release Date: 08/01/2004
> =20
>=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.560 / Virus Database: 352 - Release Date: 08/01/2004
=20