Building Ox

Nov 5, 2008 at 6:12 AM
Edited Nov 6, 2008 at 10:17 PM
The first thing you need to know is that the process for building Ox is quite different. Now there are 3 main solutions that you have to think about when building your application -

1) The Ox.CommonScripts solution.
2) The Ox.CommonContent solution.
3) The Ox source solution (which you already know about from previous versions).

What I've done here is separate the building of scripts, content, and source code into their own separate solutions. This is a good thing. It allows you to re-build your scripts or content without rebuilding the engine.

Additionally, any project that uses Ox.Example now utilizes script and content solutions that depend on the forementioned script and content solutions. CharacterDemo, TerrainAndBallDemo, and WorldDemo all utilize Ox.Example. These new script and content solutions are called Ox.ExampleScripts and Ox.ExampleContent respectively. These solutions must be built in order to run those applications.

Your Ox application doesn't magically know where to look for the script .dll and content generated by the script and content solutions. It retrieves this pathing information from your project's OxConsts.txt file. By default, OxConsts.txt is set up correctly for the windows build for all projects. The tricky part is that there are multiple OxConsts.txt files that may be built when building an application. The question is; which one will be used? The answer is pretty simple; The OxConsts.txt file that is built last will be the one that is used. So for example, the OxConsts.txt in the Ox.Example project will be built after the one in Ox.Core; the OxConsts.txt in the Ox.Example project will be used because it overwrites the one built by Ox.Core.

If you want to deploy to the 360, you have some hoops to jump through. You have to get your script .dll, your content, and your engine exe and .dlls onto the 360. This can be done by putting all of the needed stuff into the script solution's bin directory, pointing the OxConsts.txt to it, then deploying from the script solution. It's a pain, but I'm sure it works fine (nope, I've not tested it yet...).