Jump to content
  • Advertisement
Sign in to follow this  
Aleks Le

DirectX Release build

This topic is 1666 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 currently finalizing a project I am working on. (racing game)

This project uses libraries as DirectX 11, Bullet physics, Oculus rift.

 

This is the first project an actual release build will be made. 

I would like to hear some tips, about what kid of setting should be set in the project properties.(Visual studio)

 

currently i only have enabled SSE2, and runtime library is (/MD)

is there any other vital settings i shall change? 

 

I also found a post saying "Next thing is check for any uninitialized memory being used. That's where almost 80% of all release bugs come from."

i am not sure about why this is specific to release build, is memory managed differently in release build?
 

Thanks.
 

 

Share this post


Link to post
Share on other sites
Advertisement

Yes, typically debug builds will initialize memory on the stack (i.e local variables) whereas release builds won't.  Unitialized local variables in release builds will therefore have random (not really, but as good as) stack garbage in them, and if you try to use such a variable without initializing it you'll get weird behaviour.  Sometimes your program might even work, sometimes it won't and sometimes when it crashes it may crash in a random place rather than at the actual faulty code.

 

The best way to avoid this is to get in the habit of always initializing local variables when you declare them.  The sooner you get in this habit the better, and you'll find that once you start seeing the benefit of it, an unitialized local variable will really jump out at you while you're reading code.

 

So, instead of:

 

int i;

mytype *foo;

 

You need to be using:

 

int i = 0;

mytype *foo = NULL;

 

You should have probably not waited so long before setting up a release build either.  Making it a regular - though not necessarily frequent - part of your testing process can help catch a lot of release build bugs at an earlier stage.

Share this post


Link to post
Share on other sites

Visual Studio will by default catch most uninitialized usage of local variables in a debug build. It has both compile time warnings and runtime checks for that.

 

However what it won't catch is uninitialized heap memory. Fixing that is mainly down to making sure your constructors initialize all necessary member variables. Also note that if a program is started through the debugger Windows will give it a slow debug allocator, so test both cases. You can always attach the debugger to the process after launching it to debug it.

Share this post


Link to post
Share on other sites

Usually the most difficult part for beginners to get right is handling dependencies. In Windows it is usually up the individual application to create an installer that will package up any required DLL's (along with any other files), and then copy them to the appropriate locations. Since you're using /MD your app will depend on the MSVC++ runtime DLL, which you can't assume will be present on an end-user's machine. This means you either need to package it with your program, or have the user install the DLL using the redistributable package that Microsoft provides (which you can also package instead your installer if you wish, and then launch silently). The redistributable that you use depends on the version of Visual Studio being used, so you'll have to make sure that you use the right one.

 

External libraries may also require DLL's or runtime redistributables to be installed, depending on what you're using. For D3D11 you will need to install the redistributable package if you're using any version D3DX. Also if you're using a version of D3DCompiler from the Windows SDK, then you'll want to package that DLL with your app. I'm not sure if the version of bullet you're using is a DLL, but if it is you'll need to package that as well. Same goes for the Oculus SDK.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!