Hi there, I''ve been working on a game for a while and have small dll called local.dll, which resides in the directory of the game. This dll has all the functions that only need to be run once at the beggining of the game so they can be unloaded from memory as soon as we''re actually playing, allowing for a tighter pack of stuff in the memory. So right now, when the game starts it shows a small 128x128 splash screen in the middle of the screen which can be any graphics (BMP) out of the resource file included in the DLL, while this splash screen is up it checks the cpu (Using the CPUID command) for Pentium level, wheather it supports MMX and FPU, then it checks the Operating System to see if it will run (Might not be necessary in the future if it runs properly on NT) then it will check your memory to see if you''ve got enough memory. This is where I''ve run into troubles. I''d like to first estimate how much memory my game will need (System Requirements) then check if I have that much, and if I don''t alert the user and ask if they would like to continue anyway, if they feel it to be a mistake. Make sense? One thing I admired about StarCraft was that it seemed to have reasonably well done error trapping, it would alert you concerning your CPU, memory or missing files politely and nicely with possible solutions to the problems. This was nice, so I''d like the same type thing rather than the game copping out half way through because there ain''t enough ram or something. So I''m using "GlobalMemoryStatus" to retrieve the memory information and it returns a bunch of stuff. My question is should I be checking Physical Memory, Virtual Memory or something else? I understand the concept behind virtual memory (I think) so I''m guessing that I''d check the vitual memory, but I''m not sure. Any help? Thanks, Ben __________________________ Mencken's Law: "For every human problem, there is a neat, simple solution; and it's always wrong."
"Computers in the future may weigh no more than 1.5 tons." - Popular Mechanics, forecasting the relentless march of science in 1949

Ok, first of let me just say that I ain''t a windows expert. However, normally you don''t want to do this sort of thing (DLL for setup data) on modern computers. I think it''s very cool that you are thinking about things like memory, but I think your aproach may not work. The thing is a DLL is a shared libary, and even though nothing else uses it, the OS has no way to know this. Again, if there is some form of UnloadDLL call in windows then you are doing the right thing. However, the DLL will probibly be treated as a seperate pool of pages, and the os could (correctly) swap things out of your program''s pool before it looks to take pages from other processes.

If the init code is in your main program, and you run out of phisical memory, then it will almost certainly be in the Least Recently Used frames, and it''s clean so it doesn''t have to be swapped out. Windows has just gotta pick it for your first victims. The only thing you might want to do, if you want to be really _really_ anal about the whole thing is make sure all your init code ends on a 2k boundry. This would involve getting to know your linker on a way to personal level, and probibly confuse it to the point that it wastes more than 2k somewhere else, yuck.

As far as testing available memory is conserned, if you don''t have enough virtual memory, your screwed. You can start mapping large structures with the windows version of mmap (called something like "file memory" or some junk in windows) You can also assume that any pages marked "read only" don''t really count against the virtual memory limit, though again, I don''t know if windows is smart/brave enough to allow this. It might very well assume that at any time you could modify your entire code segment, and thus reserve space in the swapfile "just in case".

What you really need to do is figure out the "working set" of your program. The easyest (Ha!) way of doing this is to first off make sure your program can play a demo, and that it runs the same way from a demo as from the console. Then write a program that locks progressively more pages, and runs your program. Then go to bed, this will take a while. In the morning you will note that at some point your FPS tanks, and the game starts thrashing. In your setup make sure you have enough _phisical_ memory as you had before the game started to degrade. This would also be an actual realistic box spec, but don''t worry about that, before a box ships a marketing weasel will come along and change the box to say your game runs in just 8K or requires 256 megs of DDR SDRAM, depending on the current trends.

I say to test there physical memory... virtual maybe... the problem with virtual memory is that its swaping back and forth between the HD and the physical memory... thats slow... and if I remeber right windows will resize the virtual swap on the HD if it needs more/less...

as far as using a dll.... I say go for it... its going to reduce your avabliable memory(a little)... under windows because of virtual memory things will get screwed up anyways so use the dll... GlobalMemoryStauts will give you both total and avalible memory... so determen how much memory you game needs... check to make sure they have at least that much physical total( plus 8mb for windows... windows doesn''t like to swap its self out =)... because the total physical is more important than the avlible mem because if your game needs more then windows will swap out whats not needed.... but if your game needs 8mb and they only have 2mb free then I''d give them a warning.... windows might not find enough room for the rest of the game...

Great Milenko

Words Of Wisdom:
"Never Stick A Pretzel In Your Butt It Might Break Off In There."

http://www.crosswinds.net/~milenko
http://www.crosswinds.net/~pirotech