Jump to content
  • Advertisement
Sign in to follow this  
captain_crunch

Separate 32 Bit And 64 Bit Versions

This topic is 785 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am developing an XNA game for Windows and have it available on Steam Early Access. I have a problem where the largest of my sandbox maps always run out of memory at one point and crash.

 

Since I am at the end of the road with optimizing, and the maps are popular, I have made a plan to migrate the project to MonoGame and offer a 64 bit version that will include larger maps than the 32 bit version, since a 64 bit program has a lot more memory available.

 

Visual Studio Express can compile to x86 (32 bit), x64 (64 bit) and "Any CPU".

My guess is I should avoid "Any CPU" and instead compile 2 times, one for x86 and one for x64?

 

On Steam, should I make the 64 bit version the default, and offer a 32 bit version as a separate branch, that can only be accessed from the "betas" menu? Or can the Steam store offer separate links for 32 bit and 64 bit, like they do for different OS versions?

Share this post


Link to post
Share on other sites
Advertisement

You can do either, as I imagine most of your customer base is using 64-bit OS.  

But if you plan on keeping the 32-bit version around as an option you will need to fix your underlying issue of using more than your address space.  

 

PC games frequently rely heavily on virtual memory and it lets programmers get lazy when it comes to resource management.  You need to keep your memory under control so it fits in available space. Exactly how you end up doing that is up to you, probably using methods to stream content in and out as needed, flushing old or unused data.

Share this post


Link to post
Share on other sites

This is a simulation game where the entire world is simulated at all times. So it is not possible to get rid of content. The only feasible way is to limit the size of maps and/or entities/agents.

 

Are you saying it is possible to compile 1 version instead of 2? Because that would make many things easier.

Edited by captain_crunch

Share this post


Link to post
Share on other sites
I've seen some programs install both: program.exe and program_64.exe. Program.exe is 32-bit, does a quick start-up check to detect if the OS is 64-bit, and then launches the 64-bit EXE if it is. If it's not, program.exe continues with the normal program startup. Edited by Nypyren

Share this post


Link to post
Share on other sites

This is a simulation game where the entire world is simulated at all times. So it is not possible to get rid of content.

 

I would be surprised at any game that could generate that much world simulation data.  I can easily imagine models and textures crossing that, as we routinely do.  Models and textures are among the easiest things to swap out. 

 

But you say your simulation is huge.  The size of our largest world segments with several hundred thousand objects is double-digit megabytes, most stay in single-digit megabytes. 

 

If your simulator objects are a significant volume on a PC game I'm certain you just discovered an area where a little cleanup could go a long way.  Keeping the game world small and streamlined doesn't just save memory, but also reduces processing time and improves cache effects.

Share this post


Link to post
Share on other sites

I found this discussion on compiling for "Any CPU" vs. 64/32 bit:
 
http://stackoverflow.com/questions/516730/what-does-the-visual-studio-any-cpu-target-mean
 
It seems I can get away with offering 1 version. I just have to detect the system ingame so I can restrict the large maps to 64 bit systems and thereby prevent out of memory crashes.


As long as all of your DLLs are also 'Any CPU' it will work. If any of your DLLs are 32-bit, you'll crash if your EXE launches in 64-bit mode (and vice versa). You'll get a BadImageFormatException when the process discovers that it can't load the DLL.

There might be a way to provide alternate DLLs per architecture using the manifest, but I haven't tried that. Edited by Nypyren

Share this post


Link to post
Share on other sites

I tested "Any CPU", then looked at Environment.Is64BitProcess in the debugger and it shows the process is a 32 bit process. It probably prefers 32 bit because it gives higher performance.

 

I unchecked the "Prefer 32 bit" option, so it now runs in 64 bit. But now the Steamworks.NET dll fails to load with a BadImageFormatException.

Edited by captain_crunch

Share this post


Link to post
Share on other sites
It looks like Steamworks.Net has separate x86 and x86_64 versions (which load steam_api.dll or steam_api64.dll respectively). You'll need to figure out a way to make your EXE load the matching CPU architecture version of the Steamworks.NET dll, which in turn will load the correct steam_api*.dll.

Share this post


Link to post
Share on other sites

If your game doesn't actually run in 32-bit mode, shipping a 32-bit client doesn't make any sense.  It's just going to generate negative reviews, refund requests, and cost you new customers/goodwill with existing customers.  If you aren't going to fix your memory usage, just don't ship an x86 client.

 

I believe you indicated you are targeting windows-only.  If so, an easy solution might be to enable PAE.  However, that's a band-aid.

 

I would be surprised at any game that could generate that much world simulation data.  I can easily imagine models and textures crossing that, as we routinely do.  Models and textures are among the easiest things to swap out. 

 

I echo this sentiment.  Unload your geo, and leave only your simulation in memory.  If you can't do that, separate your render targets from your simulation targets, and then do it.  

For expensive simulations that can't be maintained in real-time, it's pretty common to to execute interleaved updates; IE - even frames only update half of the world, and odd frames update the other half.  You get half as many updates, so use twice as big of a time-slice per update (and obviously you could split that into 3, 4, n... groups as needed).  It's also a common practice for exceptionally large simulations to save off parts of the simulation to disk which are not currently interactive (in your case, not visible on the screen), and stream those in periodically for their update.  You may only get one update per second on a given section of the simulation, but the end user isn't going to notice that for things that aren't currently interactive anyways.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!