PhysX with 64-bit using VS2008

This seems to be an important feature for some to have, so I wanted to see how difficult it would be to compile and run under a 64-bit architecture. At least for NVIDIA's PhysX (both 2.8.x, and 3.2.x) it was really really easy.

Recall we needed a few dll's, which are a direct swap for the ones already copied into the project folder. 

//PhysX 2.8.4

   cudart64_30_9.dll

   PhysXCore64.dll

   PhysXLoader64.dll

//PhysX 3.2.1

   PhysX3_64.dll

   PhysXCommon_x64.dll

Of course if you have a more advanced application you may also need other libraries, but for the most basicc rigid body simulation these are essential and demonstrate the pattern for the other libraries. If you are missing any of these dll's, then it may tell you when you run the debugger (PhysX 3.2.1), or you will likely get a Null return from 

NxCreatePhysicsSDK with error code NXCE_PHYSX_NOT_FOUND.

If you use premake like me to generate Visual Studio solutions then you need to indicate these changes as well in the .lua files and specify the target platform in the .bat file. Snippets of mine looks like this :

//HelloWorld-Premake.lua

   local physXSDK = 'C:/Program Files (x86)/NVIDIA Corporation/NVIDIA PhysX SDK/v3.2.1_win'

   includedirs { physXSDK .. '/Include/foundation' }

   includedirs { physXSDK .. '/Include' }

   includedirs { physXSDK .. '/Include/common' }

   includedirs { physXSDK .. '/Include/extensions' }

   links { physXSDK .. '/lib/win64/PhysX3_x64' }

   links { physXSDK .. '/lib/win64/PhysX3Extensions' }

   links { physXSDK .. '/lib/win64/PhysX3Common_x64' }

   links { physXSDK .. '/lib/win64/PhysXVisualDebugger' }

//CreateSolutions.bat

   ..\..\premake\Premake4 --file=HelloWorld-Premake.lua --platform=x64 vs2008

If you didn't do a complete install the first time, visual studio 2008 does not come with the x64 compiler by default and you will have to re-install, adding the x64 as a custom feature. This may prompt for the location of other files, I found this solution helpful.

*Remember that you will also need to get the correct rendering libraries, or else the program will build, but fail to execute properly. See Error : "The application was unable to start correctly (0xc000007b)".*

If there is more work to be done for custom allocators, I will update this posting to include those changes as well. Until then, Happy Coding!

Getting Started : Premake

Visual Studio is a common IDE to work with, but constantly adding library dependencies can create conflicts and has not been very helpful for keeping things organized. Premake is a useful tool for generating solution and project files with the necessary dependencies. This is the method I learned, but may by no means be the best method depending on the size of complexity of project.

I have a single line batch file that creates the solution by calling Premake4.exe with a lua-script file argument. 

//CreateSolution.bat

..\..\premake\Premake4 --file=ScriptFile.lua --platform=x32 vs2008

and the associated script file contains the information for the solution as well as the project.

//ScriptFile.lua

solution "MySolution"

   configurations { "Debug" }

project "MyProject"

   kind "ConsoleApp"

   language "C++"

   local sampleSDK = 'C:/Users/Alex/Documents/sampleSDK'

   files {"**.h", "**.cpp" }

   includedirs { "include" }

   links { sampleSDK .. '/lib/sample' }

    configuration "Debug"

      flags { "Symbols" }

      defines { "WIN32", "_DEBUG" }

This is the basic structure if you are only creating one project for this solution and all the files are located in immediate subfolders. Alternatively you could create a Solution lua script file, and corresponding Project scripts that would look something like this:

//SolutionFile.lua

solution "MySolution"

   configurations { "Debug" }

   dofile('./Project0/Project0-premake.lua')

   dofile('./Project1/Project1-premake.lua')

//Project0-premake.lua

project "MyProject0"

   kind "ConsoleApp"

   language "C++"

.

.

.

In this way you can continue to use **.h and **.cpp because  all the files are in their corresponding folders. Otherwise you would have to specify which files to include in each project, which is not very practical for anything larger than a couple files. 

This is just how I'm currently doing things with my current setup, other minor tweaking for your particular setup should be evident.