Support building on Windows with vcpkg

[xvrc]

Following the plan outlined in #33, here is the vcpkg integration PR. Now, Windows users don't have to bother with compiling a million other things to get StuntRally to build!

Here's what the Windows build process looks like with these changes:

1. Install Visual Studio 2019.
2. Install vcpkg.
3. Clone the repository: git clone --single-branch --branch vcpkg https://github.com/xvrc/stuntrally.git
4. Open up a Visual Studio Developer Command Prompt, go into the repository's root directory and run cmake -B build -S . -G"Visual Studio 16 2019" -DCMAKE_TOOLCHAIN_FILE=<path to vcpkg root>/scripts/buildsystems/vcpkg.cmake.
   Note: if this steps fails while building Ogre, it's most likely because it couldn't find the D3DX9 utility library, which is no longer part of the Windows 10 SDK. To fix this, you'll need to do the following, then re-run the CMake command afterwards:
   1. Install the Microsoft DirectX Runtime (June 2010).
   2. Go to C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include\ and copy all the files that start with d3dx9 into the Windows 10 SDK (with a default Visual Studio installation, this should be at C:\Program Files (x86)\Windows Kits\10) include folder.
   3. Go to C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Lib\<target architecture>\ and copy d3dx9.lib to the respective Windows 10 SDK library folder (from the SDK's root, go to Lib\<version>\um\<target architecture>\). This should be done for both x86 and x64 folders if unsure of the targeted architecture.
5. Open build/StuntRally.sln with VS 2019 and build it.
6. Done. The executables are in a subfolder of build/bin/.

To run StuntRally from the bin directory, where the executable is located:

1. Copy all the necessary Ogre plugins (Codec, ParticleFX, D3D9 render system, etc.), which are located at build/vcpkg_installed/<triplet>/bin/ for non-debug builds and build/vcpkg_installed/<triplet>/debug/bin/ for debug builds, into the bin directory.
2. Copy the repository's config and data folders into the bin directory.
3. Get a copy of the StuntRally tracks and place them in data/tracks inside the bin directory.

Finally, you can start the game.

Some other details about the changes:

• vcpkg's bullet3 package doesn't build BulletFileLoader nor BulletWorldImporter, so these were added to the source tree.
• vcpkg's mygui package only builds the MyGUI Engine core library, so its Ogre rendering backend code was also added to the source tree.
• SDL2main kept getting linked into the binaries (since we're linking to SDL2_LIBRARIES which includes it), so I just added an extra check in main.cpp.
• I removed the MyGUI_D3D11 files because there's already the MyGUI Ogre render backend.
• I tried as much as possible to avoid buildsystem modifications that could've broken building on other platforms, but I only tested this new Windows build setup so non-Windows platforms may need to be checked.

[cryham]

Okay so I tried building this on Debian 10, like usual, to test if it still works.
I'm getting such 2 errors:

[  3%] Building CXX object source/BulletFileLoader/CMakeFiles/BulletFileLoader.dir/btBulletFile.cpp.o
/home/ch/_dev/sr/1/source/BulletFileLoader/btBulletFile.cpp: In member function ‘virtual void bParse::btBulletFile::parseData()’:
/home/ch/_dev/sr/1/source/BulletFileLoader/btBulletFile.cpp:164:27: error: ‘BT_CONTACTMANIFOLD_CODE’ was not declared in this scope
     if (dataChunk.code == BT_CONTACTMANIFOLD_CODE)
                           ^~~~~~~~~~~~~~~~~~~~~~~
/home/ch/_dev/sr/1/source/BulletFileLoader/btBulletFile.cpp:164:27: note: suggested alternative: ‘BT_CONSTRAINT_CODE’
     if (dataChunk.code == BT_CONTACTMANIFOLD_CODE)
                           ^~~~~~~~~~~~~~~~~~~~~~~
                           BT_CONSTRAINT_CODE
/home/ch/_dev/sr/1/source/BulletFileLoader/btBulletFile.cpp:173:27: error: ‘BT_MB_LINKCOLLIDER_CODE’ was not declared in this scope
     if (dataChunk.code == BT_MB_LINKCOLLIDER_CODE)
                           ^~~~~~~~~~~~~~~~~~~~~~~
/home/ch/_dev/sr/1/source/BulletFileLoader/btBulletFile.cpp:173:27: note: suggested alternative: ‘BT_SBNODE_CODE’
     if (dataChunk.code == BT_MB_LINKCOLLIDER_CODE)
                           ^~~~~~~~~~~~~~~~~~~~~~~
                           BT_SBNODE_CODE
make[2]: *** [source/BulletFileLoader/CMakeFiles/BulletFileLoader.dir/build.make:102: source/BulletFileLoader/CMakeFiles/BulletFileLoader.dir/btBulletFile.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:444: source/BulletFileLoader/CMakeFiles/BulletFileLoader.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

I'm guessing a version mismatch of bullet between the one I got from apt-get on Debian (is 2.87) and that required for BulletFileLoader?

[xvrc]

Alright, so it was indeed a version mismatch that was causing the problem.
It should work now, I downgraded the fetched Bullet to match your version. At least now I know it won't be a problem to upgrade to the latest Bullet when the time comes, since I already tested it.

[xvrc]

@cryham were you able to successfully build it with the latest changes I made?

[cryham]

Well I tried and it looked promising but I ran into issues, and seems that it is trying to use my old installed mygui build from older try and not the system installed one which I want.

[xvrc]

That's weird... I barely touched FindMyGUI.cmake. Did you clear the project's CMake cache when you tried again? I don't think CMake will check for newly installed libraries if it already found an entry for it in its cache.

[xvrc]

@cryham would you still be interested in this pull request? I can continue working on this; I'd just like to know if you were working on this separately or if you had an alternative build method.

[cryham]

Well I am still interested in any working alternative for building on Windows (other than building evth from sources like I did).
I looked at the conan PR #39 lately and I think I looks better because it has github Actions producing builds. Best scenario would be having nightly builds with this. But, unfortunately it didn't work for me, and I don't know if it will work on github anyway.

I don't have much knowledge about vcpkg or conan. So I can't just make any work.
But I can test if it works (on Windows 10, given clear instructions), and if it doesn't break building on Linux (I'm on Debian 11) - if so I'd be happy to merge.

[xvrc]

Alright, I believe I fixed everything this time. Tested building on Debian 11 (using WSL)¹ and on Windows 10 with Visual Studio 2022 (the original steps are identical, you would just need to substitute -G"Visual Studio 16 2019" with -G"Visual Studio 17 2022" in the CMake configuration step); all the binaries compiled without errors.

Regarding Conan: I personally have not used it so I can't really say much about it, but if the Conan integration PR works out then that's fine too, as long as there's an easy way to compile StuntRally from sources on Windows.

Footnotes

1. Fully updated, so if there are issues maybe a apt update && apt upgrade will help. ↩