Last year I worked on a game engine, and I used PhysX 3.3.1 at the time. As suggested in the guide, I included precompiled …CHECKED.lib’raries in my project for debug configuration. I had to switch “Runtime Library” setting of my project in Visual Studio from “Multi-threaded Debug DLL” (dynamic, /MDd) to “Multi-threaded Debug” (static, /MTd), but that was OK. Everything worked fine.
Now I returned to that project, and as nVidia generously released PhysX 3.3.3 with sources, I decided to update to this new version. But I’ve encountered a problem. In project settings for PhysX 3.3.3 only DEBUG configuration has “Runtime Library” set to debug one (/MTd). All other build configurations has no-debug setting (/MT). So, if I try to include CHECKED lib’s, built with default settings, into my project, I get LNK2038 error (MD - MDd mismatch).
So my question is - how is version 3.3.3 supposed to be build and used for production configuration of another project (i.e. debug builds)? Manual strongly recommends, as I mentioned before, to use CHECKED builds of PhysX. Am I supposed to change my project’s “Runtime Library” setting to non-debug (for example, /MT or /MD)? I tried to build PhysX CHECKED configuration with /MDd setting, but got “_DEBUG / NDEBUG” errors, which I wasn’t able to fix via preprocessor definitions. I was able to include PhysX DEBUG build in my project’s debug configuration and RELEASE build in release configuration respectively without any problems. But have no idea how as I supposed to include CHECKED one. I don’t want to use it for release builds obviously, but wasn’t able to make it work with debug builds with debug RTLs.
I guess I may not understand something very simple as other people happily use PhysX without such questions. But anyway big thanks in advance for any response.
Hi @WinterDog, I used DEBUG lib for debug configuration and CHECKED lib for release configuration, and they both worked well. For some reason, error occurred when I used CHECKED lib for debug configuration, I don’t know why. btw, my platform is win7 & VS 2010.
Hello, @Horswing! Yeah, that’s probably because of the same reason - CHECKED is built with non-debug Runtime Library, so it won’t work in debug configuration (with debug RTL). I use DEBUG PhysX lib for debug builds now and RELEASE for my release builds.
So the main question I still have - why does PhysX manual recommend to use CHECKED version “for day-to-day development and QA” (quote)? I should use debug components and environment settings for day-to-day development, right? But why is CHECKED configured for non-debug ones?
For day-to-day development you shouldn’t need debug versions of PhysX, and most game development projects don’t use debug builds during production. ‘CHECKED’ configuration is about halfway between a debug build and a release build. RELEASE does not do any validation on inputs, but CHECKED does; RELEASE does not provide hooks for PhysX Visual Debugger, but CHECKED does. The DEBUG build of PhysX adds a lot of asserts and expensive tests on internal data structures that are usually useful only when trying to analyze a crash bug.
As an example, if you build the ‘Development Editor’ configuration of Unreal Engine 4, it links to the CHECKED version of PhysX; the ‘Debug Editor’ build of Unreal Engine 4 links to the DEBUG version of PhysX. If you try to run ‘Debug Editor’ for any amount of time during game development, you will probably find that the performance is not adequate. Game coders use debug builds when they are actually debugging code, but development teams use something other than a debug build, like the ‘Development’ configuration of UE4, for production. This means that the typical level designer, animator, technical artist, game tester, and other production workers will run the ‘Development’ build, while programmers developing new code may run the ‘Debug’ build more often.
Thank you very much, Mike! You clarified much of the theme for me. I’m really unexperienced in all this cause I am not working as a game developer - this is just my hobby. Now I get it.
Thanks again!
You’re welcome! Glad to help.