This worked out fine, but I didn’t find the time to actually do anything with Ogre. Finally, during the past weekend, I took a closer look at Mogre, a C++/CLI-based wrapper that enables you to use Ogre in .NET languages.
I’m always a bit saddened if I see AAA games installing 3 different versions of the Visual C++ runtime and requiring 4 versions of the D3DX libraries at once. That means the developers simply used what binaries they could find, without investing a little bit of time to do a consistent build.
So I decided to do better and get me some good builds of all of Mogre’s dependencies. I decided to use the Visual C++ Multithreaded DLL runtime, which means all C/C++ library code is loaded from msvcr100.dll (C) and msvcp100.dll (C++) only once and all libraries share a single heap. That sounds better to me than having half a dozen different runtimes in memory, some compiled into their DLLs statically, others loaded from various msvc*.dlls
The most difficult part was FreeImage due to its tons of image loading libraries it contains: ilmbase, openexr, libjpeg, zlib (for libpng), libpng, libmng, libtiff, libraw and libungif. After some effort, I ended up with this nice set of binaries: FreeImage 3.15.1 binaries.
Next was Boost. Not too difficult to compile, but one gigantic collection of C++ headers that takes minutes to download from a Subversion repository. Luckily, Boost consist of individual libraries, so I checked which libraries I really wanted (regex, datetime and math) and only included the minimal amount of headers needed for those libraries. Instead of 8597 headers, I ended up with 902.
After some other minor efforts (FreeType almost compiles itself) it finally was Ogre’s turn!
Ogre and Mogre
This proved a bit more difficult again because Ogre seemed to have abandoned its Visual Studio solutions and went with CMake. Not wanting to settle for that, I recreated all of the solutions in Visual Studio 2010 (the advantage is that in the end I can add the Ogre projects to my game, edit Ogre’s sources and press F5 without having to worry about building Ogre all over again, copying DLLs around and stuff).
The problem with Mogre was that it has a rather complex set of build steps and upon searching the forums, there were various sets of patches and modified sources in several repositories. I wasn’t sure whether I should start with the official sources or pick one of the personal forks, so I just chose whatever promised me to work against the most up-to-date version I could find while also supporting Ogre’s terrain plugins.
To make it short, it took a lot of fiddling and analyzing what Mogre’s "AutoWrap" does to eventually end up with a clean build. It was really exciting seeing Mogre running in a 64-bit .NET 4.0 executable, rendering the example scene to the screen for the first time 😀
I then spent some time building some other libraries I thought I could use, like OIS/MOIS (Ogre’s input device manager), Newton/MogreNewt (Newton physics integration – that developer has seriously messed up his build configurations) and Bullet/BulletSharp (Bullet physics integration). It took some more time to track down a crash issue I had when shutting down Mogre, but it all worked out in the end!
I think this is a good place to say thanks to the Mogre community as well who were nothing but helpful in my endeavor
After all was said and done, I wrote down detailed instructions on what I’ve done to build each project involved and packaged the final binaries into my own little SDK which enables anyone to download a single .zip archive, open the contained solution in Visual Studio and press F5 to get a working Mogre application running on his screen.
All binaries (including all their dependencies down to the smallest library) have been compiled with Visual C++ 2010 SP1 targeting the multi-threaded DLL runtime, so this is a completely homogeneous build that only requires the Visual C++ 2010 SP1 redistributable (download in 32 bit or 64 bit) and nothing else. I took the liberty of enabling SSE2 optimizations everywhere because I can’t think of any system you’d want to run Ogre on that doesn’t have an SSE2-capable CPU.
The Ogre and Mogre binaries for use in your own projects can be found in the References directory. I included all Ogre and Mogre headers, so you can also use this package as an SDK to compile other Mogre extensions or even as a plain Ogre SDK if the homogeneous build or SSE2 goodness piqued your interest!