I’m pleased to say the command line version of MogreBuilder is now complete. A lot of blood, sweat and tears has gone dealing with the various issues, but I guess that’s what happens towards the end of a project as you run out of the easy things to do.

The first thing I tried to do with week was get the GUI sitting on top. I had big plans to pull the whole thing out of the Console and output everything to a nice window. At the same time, I didn’t want to remove the ability to run it on the command line because that is useful too.

I was now faced with a half working GUI version and half working command line version. What I needed to do is combine the best bits of both. So, the first step is to do a bit of a redesign and make the code easier to work with.

The Redesign

My goal with the redesign was to pull all of the hard coded paths out of the tasks and into a common location. The existing OutputManager seemed like a reasonable approach, so I created an InputManager to keep it company. I also refactored the OutputManager to an interface with the intention that the Console and GUI would implement it.

Everything went as planned until I ran to some threading issues while running it in a GUI. At this point I’d already spent a load of time on it and I started to think about just how important a GUI is for this application. While it would be nice, there are far more important tasks that need to take higher priority. There’s a to-do list at the end of the post.

The Config File

So, instead of doing the GUI I came up with the next best thing. Pull all of the configuration out into a simple human editable text file. This way, you can setup different build configurations and run them whenever you like with every little effort. This approach doesn’t replace the GUI so much as it sits along side it nicely.

// build
BuildConfiguration = "Debug";

// clr
ClrDirectory = @"Main\Ogre\";
ClrConfigHeaderFile = @"Main\OgreSrc\ogre\OgreMain\include\CLRConfig.h";
ClrObjectsBuildFile = @"Main\OgreSrc\build\include\CLRObjects.inc";
ClrObjectsAutoFile = @"Main\include\auto\CLRObjects.inc";

// mogre
MogreSolutionFile = @"Main\Mogre_vs2010.sln";
MogreRepository = @"https://bitbucket.org/mogre/mogre/";
MogreBranch = @"default";

// ogre
OgreRootDirectory = @"Main\OgreSrc\ogre\";
OgreBuildDirectory = @"Main\OgreSrc\build\";
OgreMainDirectory = @"Main\OgreSrc\ogre\OgreMain\";
OgreIncludeDirectory = @"Main\OgreSrc\ogre\OgreMain\include\";
OgreSourceDirectory = @"Main\OgreSrc\ogre\OgreMain\src\";
OgreProjectFile = @"Main\OgreSrc\build\OgreMain\OgreMain.vcxproj";
OgreSolutionFile = @"Main\OgreSrc\build\OGRE.sln";
OgreRepository = @"https://bitbucket.org/sinbad/ogre/";
OgreBranch = @"v1-7";

// cmake
CMakeExecutable = @"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe";
CMakeCachePath = @"Main\OgreSrc\build\CMakeCache.txt";

// dependencies
DependenciesURL = "http://surfnet.dl.sourceforge.net/project/ogre/ogre-dependencies-vc%2B%2B/1.7/OgreDependencies_MSVC_20100501.zip";
DependenciesZip = @"Main\OgreSrc\ogre\Dependencies.zip";
DependenciesDirectory = @"Main\OgreSrc\ogre\Dependencies\";
DependenciesSolutionFile = @"Main\OgreSrc\ogre\Dependencies\src\OgreDependencies.VS2010.sln";

// patch
PatchExecutable = "pat-ch.exe";
PatchFile = @"Main\Ogre Patches\58266f25ccd2.patch";

// cpp2java
Cpp2JavaDirectory = @"Codegen\cpp2java";
Cpp2JavaMetaDataFile = @"Codegen\cpp2java\build\all.xml";

// autowrap
AutoWrapExecutable = @"Codegen\AutoWrap\bin\Debug\AutoWrap.exe";
AutoWrapSolutionFile = @"Codegen\AutoWrap\AutoWrap_vs2010.sln";
AutoWrappedCodeDirectory = @"Main\src\auto\";
AutoWrapWorkingDirectory = @"Codegen\AutoWrap\bin\Debug\";

The Patch Issue

Solving the issue with the patch file had be a little stumped for a while. I hadn’t really played with patch files much, nor have I had much experience using hg. So into the documentation I dove and slowly pieced together a solution. In the end it was fairly easy, change the file manually, do a diff and update the patch file with the changes. Everything else stays the same and the patch file now applies correctly. I’m confident that future issues like this can be solved fairly easily too.

Hg Clone Tasks

Cloning the repositories used to a be a manual step, now the tasks have been added to the builder and the whole thing can be run from an empty directory to a fully build Mogre.dll with one command. Very nice :)

The Result

You can get the source code to MogreBuilder on bitbucket.

You can download the binaries here.

What’s next?

Here’s the new to-do list prioritised on importance.

  1. MOIS – include in the build process
  2. Samples – upload the souce code to the repository
  3. Terrain and Paging – get this working somehow
  4. GUI – sit the on top of the input manager

The last 3 weeks have been long and tiring. At this point I’m going to take a break for a while and get back to working on our game.

  • http://www.umityildiz.tk/ Ümit YILDIZ

    This would be nice corrected.
    [assembly: AssemblyVersion(“″)]


    • http://www.craftworkgames.com glue

      Yeah, it would be nice to correct this issue. There are a few options I can think of.

      1. As quick and dirty hack you could edit the AssemblyInfo.cs file manually. I haven’t tried this, but I guess it’d be easy enough.
      2. The next simplest approach would be to add another config option. You’d still have to manually change for each new version, but it’d get the job done in one pass.
      3. The best method I can think of would be to detect the version of Ogre and make Mogre’s version match.

    • http://www.craftworkgames.com glue

      I fixed this issue on the weekend using option 3. So, it detects the Ogre version and ensures that the Mogre version matches.

      These changes have been loaded into bitbucket, but I’m trying to get Terrain and Paging in before the next set of binaries.