Project

General

Profile

Wiki »

Windows Builds

After a brief attempt at targeting x64 for Windows, I found it’s probably best to go with win32 for now (at least for the first stab at the port). Some of the dependencies, notably the Gnome back-end, report only 'experimental’ support for x64. Other dependencies are simply not configured out of the box for x64 (OpenEXR, zlib - uses a different calling convention on x64). Additionally, CEGUI is no slated for official x64 support till v0.8 primarily due to the lack of x64 support from its host of dependencies.

Environment Preparation

  • Install MS Visual Studio 2013 Community edition (SP5). https://www.visualstudio.com/en-us/downloads/download-visual-studio-vs.aspx. As of this writing, many pre-compiled dependencies are not available for the VS 2015 runtimes, so 2013 is highly recommended. Anything less than SP5 on VS 2013 will have linker issues on boost libraries
  • Retrieve OpenGL extension header (glext.h) from http://www.opengl.org/registry and save it to the Windows SDK include directory. This will vary upon the installed version of the SDK; i.e. C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include\gl.
  • Install CMake (tested version 3.5.1)

Precompiled Dependencies

A large number of lower level dependencies (i.e. freetype, fribidi, png, tiff, jpg, zlib, etc.) can be satisfied by downloading these precompiled from GDAL maintainers, http://www.gisinternals.com/sdk/, and CEGUI maintainers, http://www.cegui.org.uk/wiki/index.php/Downloads. Between the two, they cover a number of dependencies that would otherwise consume a huge amount of time building for Win32. Be sure to get the version matching you MSVC version and build target (i.e. Win32 or x64).

Building/Installing Top Level Dependencies

  • zlib - OpenEXR is expecting zlib built with different calling conventions than the one available in the prebuilt binary packages above. Get the WINAPI version here; http://www.winimage.com/zLibDll/index.html. Note, this version need only be linked against OpenEXR.
  • OpenEXR - Be sure to unpack Ilmbase and OpenEXR to the same parent directory. That is, the Ilmbase and OpenEXR source directories should be siblings. This is important because both projects will install libs to a 'Deploy’ directory that needs to be the same relative path distance from both projects. Both projects contain vc7 and vc8 solution files. If using vc10 then convert the vc8 solutions. I found that the vc7 solution conversion succeeded but the OpenEXR build failed in that case. http://www.openexr.com/downloads.html. For the OpenExr solution to build, you may need to copy the zlibwapi lib and dll to the Deploy directory created by the ilmbase build. Note, as of this writing ilmbase version 1.0.2 and openexr version 1.7.0 successfully compile. The newer 2.1.x and 2.0.x fail compilation on Windows.
  • ffMpeg - A developer package for Windows can be downloaded at http://ffmpeg.zeranoe.com/builds/. These are prebuilt libs, dll and headers for either win32 or x64. Note, to build the ffMpeg plug-in for OpenSceneGraph, you’ll also need a header file that is not standard in a MSVC environment. It can be found here; http://code.google.com/p/msinttypes.
  • OpenAL - OpenAL-soft appears to be the only OpenAL fork maintained for Windows; http://kcat.strangesoft.net/openal.html#download. The binary package contains the lib and headers for linking against osgAudio (and optionally OpenSceneGraph).
  • Lua - It’s most strait forward to use the Lua binaries from the CEGUI prebuilt pack. Lua 5.1.x lib and headers are also available at http://sourceforge.net/projects/luabinaries/files/5.1.4/Windows%20Libraries/.
  • toLua++ - CEGUI can build this module rather than building it externally.
  • boost library - Pre-built Windows binaries for various MSVC versions are available at http://www.boostpro.com/download/.
  • libNova - A fork supporting CMake is found at https://github.com/JohannesBuchner/libnova.
  • Redis - MS maintains a Windows port of Redis at https://github.com/MSOpenTech/redis/.
  • HiRedis - https://github.com/Microsoft/hiredis. HiRedis is also part of the MSOpenTech tree but does not properly link.
  • libEvent - https://github.com/libevent/libevent.

Building CEGUI

This is relatively strait forward since the pre-built dependencies are proivided by the CEGUI team with the exception of fribidi, which is required for bi-directional text support. Luckily, the GDAL pre-built dep. package supplies this. Copy fribidi.lib from the GDAL package to the location of the CEGUI dependencies and rename it to fribidi_dll.lib. Depending on where you unpacked the dependencies, you may need to adjust the project settings in MSVC to locate the libs and headers. Note, CEGUI uses an external tool (not CMake) to generate MSVC solution files. Follow the instructions in the source distribution. As of version 0.7.7, MSVC 2008 projects are generated but they convert to 2010 without any errors.

Building OpenSceneGraph

Run CMake GUI just as you would on Linux and select the VC 12 compiler target. Run 'configure’ and then set the variable 'ACTUAL_3RDPARTY_DIR’ to the location of all the binary dependencies needed by OSG. For instance, E:\OSGBuildDeps if your dependencies are structured as E:\OSGDependencies\lib and E:\OSGDependencies\include. Ensure that the OpenEXR includes and libs are copied here, otherwise the EXR plug-in will not be built. It may be necessary to explicitly provide the location of the OpenEXR files.

The 'generate’ button will output the MSVC solution and project files under the build directory. Open the solution file and built the entire solution.

Building osgEarth

As of this writing, osgEarth 2.9 is the latest and required version; https://github.com/gwaldron/osgearth/tags. Unpack the source, run CMake GUI and press configure once. Set the 'OSG_DIR’ variable to the location of the OSG build tree. Also, set the 'OSG_GEN_INCLUDE_DIR’ variable to the include directory generated under the OSG build location (i.e. the [CMake build location for OSG]/include).

Run configure again and verify the OSG libraries are now found. Manually set the location of the curl, zlib, and GDAL libraries/headers. Curl and zlib are included in the GDAL pre-built binary package. Do another configure and Verify there are no additional warnings/errors. If error free, do the Generate and then build the solution in MSVC.

Building osgCairo and osgPango

The GTK+ stack is needed to build these components. As of this writing, there’s is still not great support for building GTK+ 2.x modules from source. So far, we’ve been able to get away with using a pre-compiled version. The availability of pre-compiled versions has changed over time and the Gnome/GNK maintainers no longer provide one directly. Most recently, I’ve obtained a working build of 2.x here http://www.tarnyko.net/repo/gtk_win32.htm. Note that 3.x builds are verified to link successfully but result in no text displayed via osgPango.

Use the sources for both osgPango and osgCairo at https://github.com/robspearman?tab=repositories.

Building osgAudio

Use forked sources at https://github.com/robspearman?tab=repositories. The OpenAL dependency is satisfied by the openal-soft package, but the following additional dependencies are required. The OpenAL-Soft package needs to be build from source. The precompiled binaries are compiled against the MinGW platform and will not properly link.

There are MSVC solutions ready made in the win32 subdirectory of the source trees for ogg and vorbis, so these are easy.

When running CMake on osgAudio, setting the OSG_ROOT and OSG_SOURCE variables will aid in automatic location of the OSG includes and libs. The location of OpenAL, ALUT, and ogg/vorbis includes and libs will likely require manual entry. When building the osgAudio solution, one example project will fail on an undefined M_PI. MSVC’s version of the cmath header lacks this definition but it is defined in math.h. Simply add an #include <math.h> to moving.cpp fix the problem.

Building Nightshade NG

Copy all required header and library files to a common root directory, i.e. NS12BuildDeps/include and NS12BuildDeps/lib. Run CMake and set the variable 'NIGHTSHADE_DEP_PATH’ to this root directory. The minimal set is going to be the libraries and include files for OSG, osgEarth, SQLlite3, CEGUI, osgAudio and osgPango. Once these are copied, run configure and verify nothing’s missing.

Boost is a special case. If you installed via BoostPro then create a new variable in CMake called BOOST_ROOT and set it to the root installation path of your boost installation. Run configure again and the required boost dependencies should be located.

Packaging Nightshade NG

Troubleshooting

Integrated Graphic Cards

Some graphics cards in some configurations may give an incorrect VRAM amount in the output of the command line. When this happens usually the shaders will fail to compile and the engine will have visual problems. This can usually be resolved by going to the graphics control panel and selecting the dedicated graphics card instead of the integrated graphics card.

Debugging Nightshade NG

In order to debug Nightshade you will need to have a number of assets and dependencies. One approach is to let the installer builds builld the installers, and you grab the files from the temporary directory (data “SolutionDir\_CPack_Packages\win32\NSIS\Nightshade Data Pack-1.0-win32\”, and the engine “SolutionDir\_CPack_Packages\win32\NSIS\Nightshade-18.4.1-win32\” ). You could simply copy these files manually or automate it with batch commands in a post build step in your project.

Debugging the dreaded 0xc000007b

This error comes up when 32-bit modules are mixed with 64-bit modules. You’ve arrived in dll hell and your only friend is http://www.dependencywalker.com/. One convoluted occasion when this can occur is when 3rd party apps register themselves in the PATH. Their 64 bit dll may load when you really need a 32-bit version (or visa versa) in your app’s directory. Dependency walker makes it relatively easy to track down the offending module. By sure to run the 64-bit version of the walker for 64-bit apps and the 32-bit version for 32-bit apps.