This article is intended as an alternative to the Practical Application. With this article you'll learn how to combine several different ideas and features floating around on the wiki to create a blank project that can serve as the beginnings of a real project or just a staging ground for your own learning exercises.

This article assumes a windows platform. The basic idea is universal to all platforms, but you'll need to change the details in a few places to get things working under Linux or Mac.

Introduction

Aside from the Practical Application articles, there aren't many resources on setting up a real project using Ogre. There are other considerations, too. Such as organizing your source code, assets, and binaries to allow you to easily release your game as it stands. This article presents the amalgamation of ideas presented on the wiki with some of my own ideas to create a robust framework for new projects.

Features:

• Organized directory allows you to easily strip developmental files and create a releasable .zip
• Input manager for each window handles multiple listeners. Also handles anonymous polling
• Threaded architecture allows for multiple threads
• Packing binaries to decrease their physical size without changing
• Game state stacks - organize your game states in a clean manner
• Debugging controls
• Controls the main game loop

 
Limits:

• No GUI is set up at the moment. I'm not a fan of CEGUI, and there are so many alternatives that you'll want to explore all the options and set up your own.

Creating the directories

The directory structure I present here is based on how I've seen real games do it, and is based on the following requirements:

• You need to be able to easily delete any intermediate files (ie: .obj files).
• You need to create separate directories for your debug, release, console, and other compilation modes.
• You need to be able to create a release of your game at a moment's notice.
• You need to be able to add or remove assets by modifying a single file..

 
Based on these requirements, I came up with this structure:

• Your Game Directory
  • System - contains your "real" game binaries and dependancies
    • Plugins - contains your render systems and other binaries as needed
  • Debug - contains your "debug" game binaries and dependancies
    • Plugins - yep, contains your debug render systems
  • Any other binary modes and dependancies follow likewise
  • Assets - Parent directory for all your assets. You create all the sub directories as you go.
  • DontInclude - A dumping ground for any intermediate files that get created during the build process. Don't include this directory with any release. It's just not needed.
  • Source - Contains all the source for your project.
    • Trunk - To allow you to easily start a source control method, all the source code is placed in this sub directory. Your workspace and sub projects go here.

 
To create a release of your game, just include the System and Assets directory. To create a source SDK for your game, to let other programmers start programming with you, just include the Source, Assets, System, and Debug directories.

This leaves the primary directory of your game empty of everything but some folders. You might want to add a shortcut to your game in this directory, so players know how to start playing your game. You can also add a Readme.

The following is the code for a .bat under windows that will set up all your directories like I describe above. Just place the text in a .bat file in your game directory and run it.
Alternative: open console in target directory and copy&paste the code by context menu.

md Debug
 md Debug\Plugins
 md System
 md System\Plugins
 md DontInclude
 md Assets
 md Source
 md Source\Trunk

What binaries do you need?

Ogre comes with a lot of binaries in its bin folder. Thankfully, most of them aren't necessary. And half of them are debug releases of the same binaries.

Static linking vs. dynamic

With newer versions of Ogre, licensing lets you statically link Ogre into your commercial project without "linking in" the LGPL. For this article, I'll be dynamically linking (ie: the program will need the Ogre binaries (.dll in windows) to run).

Pros for dynamic linking:

• Your main executable size is reduced considerably. With the proper linker settings, you can get your final binary down to just a couple of kilobytes.

Cons of dynamic linking:

• Your final release will be much bigger because you're dependencies have code for things you don't use.

The bare bones

What binaries do you actually need?

Ogre by itself just needs two: OgreMain.dll and a render system (usually either OpenGL or DirectX). Since it requires the same amount of work, I'll just be including both render systems. You can pick and change the render system as you please. OIS, Ogre's defacto input library, requires its own binary too. OIS.dll

All of the other binaries are for different plugins and behaviors. You can add them in as you need them.

The following is the .bat code for automatically copying the binaries in to your directories (set up in the last section) from teh Ogre SDK. The OGRE_HOME environment variable will need to be defined. If you installed from an Ogre SDK, this will have already been done. Again, just copy the text into a .bat file in your game's directory and run it. You can also rerun this script to recopy Ogre's binaries if you recompile Ogre or install a new SDK.

REM Copy Ogre binaries
 copy %OGRE_HOME%\bin\Release\OgreMain.dll System\OgreMain.dll
 copy %OGRE_HOME%\bin\Debug\OgreMain_d.dll Debug\OgreMain_d.dll
 
 REM Copy OIS binaries
 copy %OGRE_HOME%\bin\Release\OIS.dll System\OIS.dll
 copy %OGRE_HOME%\bin\Debug\OIS_d.dll Debug\OIS_d.dll
 
 REM DirectX binaries
 copy %OGRE_HOME%\bin\Release\RenderSystem_Direct3D9.dll System\Plugins\RenderSystem_Direct3D9.dll
 copy %OGRE_HOME%\bin\Debug\RenderSystem_Direct3D9_d.dll Debug\Plugins\RenderSystem_Direct3D9_d.dll
 
 REM OpenGL binaries
 copy %OGRE_HOME%\bin\Release\RenderSystem_GL.dll System\Plugins\RenderSystem_GL.dll
 copy %OGRE_HOME%\bin\debug\RenderSystem_GL_d.dll Debug\Plugins\RenderSystem_GL_d.dll

 
Last, we need to define a plugins.cfg file. Copy these contents to a file called plugins.cfg in the System/Plugins directory:

# Defines plugins to load
 
 # Define plugin folder
 PluginFolder=.\Plugins
 
 # Define plugins
 Plugin=RenderSystem_Direct3D9
 Plugin=RenderSystem_GL

And copy these contents into a plugins.cfg file in your debug/plugins directory:

# Defines plugins to load
 
 # Define plugin folder
 PluginFolder=.\Plugins
 
 # Define plugins
 Plugin=RenderSystem_Direct3D9_d
 Plugin=RenderSystem_GL_d

Assets

Last, we'll need to set up the assets directory. First, copy the OgreCore.zip file from the OgreSDK to your assets directory. This zip contains the graphics and fonts for the basic Ogre debug overlay.

Next, create a file called resource.cfg and copy this text in to it:

# Resource locations to be added to the 'boostrap' path
 # This also contains the minimum you need to use the Ogre example framework
 [Bootstrap]
 Zip=OgreCore.zip
 
 # Resource locations to be added to the default path
 [General]

 
You'll add in other entries as you add directories and packages to your game.

Creating the project workspace

Create the solution

Open up MSVC and go to file->new->project. Go to VC++, and at the very bottom click on Win32. Create a Win32 Project as follows:

(This is going to seem a little weird, but it's necessary to get the directories set up properly.)

• Name: [Desired project name]
• Location: [YourGameDirectory]\Source
• Solution Name: Trunk (make sure Create Directory For Solution is checked)

 
Click OK to enter the wizard. Click next. Check "empty project", then the Finish button. Right click on your "Trunk" project in the solution browser in MSVC, and rename it to whatever would be more appropriate (or just leave it as trunk if you wish).

Congratulations, your source directory is set up properly. It should look like this:

• Source - Contains your .sln file
  • [Project Name] - contains your .vcproj files

 
To add in a new project to the solution (for, say, unit tests), right click on your solution in the solution browser. Add->new project. Set it up however you wish, but for location make sure it says [YourGameDirectory]\Source\Trunk.

Settings

Right click on your project, and go to Configuration Properties. Make sure the configuration is on 'release'. Change the following properties in the following tabs:

General:
Output Directory: $(SolutionDir)\..\..\System
Intermediate Directory: $(SolutionDir)\..\..\DontInclude\$(ConfigurationName)

Debugging:
Working Directory: $(OutDir)

Library->input:
Additional Dependancies: OgreMain.lib OIS.lib

Library->Debugging:
Generate program Database File: $(IntDir)$(TargetName).pdb

Now change the configuration to '''debug'''. Change the following properties in the following tabs:
General:
Output Directory: $(SolutionDir)\..\..\Debug
Intermediate Directory: $(SolutionDir)\..\..\DontInclude\$(ConfigurationName)

Debugging:
Working Directory: $(OutDir)

Library->input:
Additional Dependancies: OgreMain_d.lib OIS_d.lib

Library->Debugging:
Generate program Database File: $(IntDir)$(TargetName).pdb

 
__Last:
__You'll want to set a preprocessor symbol so OIS knows you want to compile it as a dynamic link library (aka DLL). Got to C/C++->Preprocessor. For preprocessor definitions, add OIS_DYNAMIC_LIB

Important Note

This is what I've learned from trial and error. I'll try updating this section as necessary.

MSVC creates a .user file with the .csproj file. This .user file contains information on paths, such as which working directory to use, etc. For you to easily give your game directory to someone else so they can compile and modify your program, they'll need their own .user file to be set up properly. Ordinarily this won't happen. Go to your project directory. You should see a .user file that looks something like [Project Name].vcproj.[Your computer's name].[Your user profile name].user.

This file contains all the information we set up in the last section. Other people's computers won't read this information when they open the solution. This will result in all sorts of headaches. Rename this file to [Project Name].vcproj.user. This is now a universal "seed" file. If a user opens up the solution and MSVC can't find a specific user file, it will use this "seed" file to create a specific user file from.

Just remember from now on if you want to change any of the project's settings, you'll need to delete any specific user files and edit the "seed" file in a text editor. Other people on your project will need to delete their specific user files when they get your updated copy.

Boilerplate code

The following download is a zip of the roughly 1000 lines of boiler plate code that comes with this article. You are free to do pretty much whatever you want with it. You'll also need to understand how it works eventually if you want to add extra features.

Link is dead - no code - no dice.

http://www.mediafire.com/?1yhwznmjg49 - Download the source code

Where to start

If you just want to start typing, add your code to MainGameState.cpp. Update, HandleEvents, and Draw are all executed in different threads. See Game states and Threading for information on how this works. To add something to look at, add code to the Initialization function.

Try code

You don't want windows telling the user when you have a problem, so all the code is try-catch'ed in a central way through the TryCode class. Errors are caught and sent to a dialog box through Ogre. Ogre comes with some built-in, cross platform dialog boxes, but you'll want to make your own eventually as your project gets more serious. At the moment, if there's an error it should get caught and sent to a proper dialog box (divide-by-0 is a notable exception).

Game states

Inspired by this article and [[Managing Game States with OGRE|another on this site]], the code includes the idea of a game state, defined in AbstractGameState.h. Game states are simple abstractions that define an Initialization function, a Shutdown function, a HandleEvents function, and an Update and Draw function. To define a new game state, inherit from the AbstractGameState class, and implement the pure virtual functions.

Game states are loaded into a list by the GameStateManager, defined in GameStateManager.h. Slightly different from how the above articles use game states, the GameStateManager just maintains a list of GameStates to run through. This way, to run several different game states at once, all you need to do is call your GameStateManagerInstance.Update, etc. The game state manager will handle any initialization or shutdown of game states, but it won't delete them. If you create a game state on the heap, you'll need to delete it yourself.

Threading

All the threading code is contained in main.cpp at the moment. Threading is strongly tied in with the idea of game states. The input thread polls for new input data from OIS and makes the data available to the game states through their HandleEvents function. The game engine thread handles core game logic, like AI, basic gameplay, etc. It calls a game state's Update function. Last, the primary thread is responsible for all the Ogre related graphics, and calls the game states' Draw function.

Input data

The InputData class handles all the specifics of keeping the input data synced properly. Use the isDown or isUp functions to test for keys being down or up. The justDown and justUp functions only return true if a key was pressed or released this last cycle (useful for things like toggles). The last MouseState is also recorded into a buffer to let you access the mouse data from the last cycle.

Packing the binaries (and why)

Binaries for your Ogre project can take up a lot of space. An Ogre project folder that does nothing can take up 30 MB (that's including the debug OgreMain DLL that takes up 15 MB). What does this matter, right? What's 30MB in the modern world where we have hundreds of gigs of hard drive space? Well, honestly it doesn't make that big of a difference. But it's nice when things are small, and it isn't hard to set things up to pack your binaries, so why not do it?

Enter UPX. There are other binary packing utilities out there, but I've found this to be the easiest to use. Using it I managed to compress most of the binaries down to under 10MB.

You will need to add the directory you "installed" UPX to your system path for the following bat to work. This can be accomplished by pressing windows key + break, navigating to the Advanced tab, and clicking on Environment Variables. For user variables, scroll down to "path", and edit the entry. Add a semicolon (;) to the end, and then type in the directory where UPX is.

Warning: UPX packed files relatively often will be detected as male software by some Virus scanners (false positive). Even http://www.virustotal.com virustotal.com give no bad result, this can happen in the future. So it's better to don't use it to avoid trouble with some users.

 
The following bat file will compress Ogre's binaries. Feel free to add any of your own binaries at the end.

UPX -9 System\OgreMain.dll
 UPX -9 System\OIS.dll
 UPX -9 System\Plugins\RenderSystem_Direct3D9.dll
 UPX -9 System\Plugins\RenderSystem_GL.dll
 
 UPX -9 Debug\OgreMain_d.dll
 UPX -9 Debug\OIS_d.dll
 UPX -9 Debug\Plugins\RenderSystem_Direct3D9_d.dll
 UPX -9 Debug\Plugins\RenderSystem_GL_d.dll