Jump to content

View more

Image of the Day

#indiedev  #indiegame #screenshotsaturday https://t.co/IwVbswGrhe
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

DirectX Release build

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 AlexRus   Members   


Posted 18 May 2014 - 10:05 AM

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?



#2 mhagain   Members   


Posted 18 May 2014 - 03:08 PM

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.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

#3 Adam_42   Members   


Posted 19 May 2014 - 12:12 PM

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.

#4 MJP   Moderators   


Posted 19 May 2014 - 11:52 PM

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.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.