To share or not to share…

So, I’m gradually working towards making a simple fighting game, using my Kinect as the input sensor. I think initially it’ll be one person punching a punching bag, then two people competing, and then probably some sort of computer controlled AI which looks at your pose, and chooses the right pose/move accordingly (although since I don’t really know how to fight, that will be interesting).

The Experiment

Anyhow, a few weeks ago I got a very rudimentary scripting host working, where I have my rendering infrastructure written in C++, and I have a mono .NET window displaying the output etc. Well I have since improved it to allow me to create entities on-screen in a (somewhat) adhoc manner (they’re all the same entity at the moment). In doing this I decided to do an experiment to discover what we all know is true: if you have more than one instance of the same model on screen, it better be the same vertices et al in memory. My Naive version loaded the model from disk, and packed it into my renderable format in memory each time the scrip requested an entity from the engine. I wanted to do 1000 entities, but the Naive approach crashed my computer at ~380, so for my performance comparisons I only went up to 200. My second approach uses boost::flyweights to share the model amongst all the entities that use it. I performance tested this one up to 200 as well, but as you can see below it gets up to 1000 dwarves on screen quite happily.

Snow-white couldn’t cook for all these guys.

Continue reading “To share or not to share…”

Portable C++ on Windows: Part 2 – Libraries

In the previous post in my series on Portable C++ on Windows, Compilers and Command Lines, we walked through the steps required to set yourself up with a windows-based C++ development environment which doesn’t rely on the Microsoft platform. We walked through getting set up with MinGW (GCC for Windows), MinGW-MSYS (BASH for Windows) and more recent versions of the GNU Autotools for your shiny BASH shell.

This time, we will walk through building the Boost libraries and the Xerces C++ XML library. Now, I know I mentioned in the first part that we would cover SFML as well, but this comes pre-built for windows, so we don’t need to worry about that (we will cover installing it and building a small example with it in the next part of this series).

Boost

First things first, you need to get hold of the Boost libraries, and also Boost Jam, which is the Boost build system. Use the links below. If you’re from the future you might want to go to boost.org and get the latest versions, but at the time of writing the links below were to the latest versions.

I unzipped the Boost JAM archive so that bjam.exe was in c:boostjam, and then used WEVE to edit my PATH environment variable so that the boostjam folder was on it. The next thing you’ll want to do is extract the Boost 1.37.0 archive so that you end up with a folder like c:librariesboost_1_37_0.

Next, fire up MSYS (make sure you are running as an administrator, especially if you are on Vista, with UAC turned on). Change directory to /c/libraries/boost_1_37_0 and then run ./configure. After this has completed you should have a file called user-config.jam. Mine looked like this:

# Boost.Build Configuration
# Automatically generated by Boost configure

# Compiler configuration
using gcc ;

Now open up a windows command prompt (cmd.exe) and navigate to c:librariesboost_1_37_0 and invoke the following commands:

copy user-config.jam toolsbuildv2user-config.jam
bjam debug -toolset=gcc stage

You’ll have to sit and wait for some time, but eventually you’ll have about 4GB of lib and dll files in the stagelib folder.

Xerces

We’re going to cover building the Xerces 3.0.0 XML library for C++. First, you’ll need to grab the source code and unzip it into the c:libraries folder as well. You should end up with a folder like c:librariesxerces-c-3.0.0. Fire up MSYS again if you closed it, and change directory to /c/libraries/xerces-c-3.0.0 and run:

./configure LDFLAGS=-no-undefined && make && make install

Again, you will have to sit for a while. When everything has completed you should be able to find the Xerces libraries in c:msys1.0locallib unless you installed MinGW-MSYS somewhere else.

That’s all for this part and I hope that everything went smoothly – if it didn’t, drop me a comment and I’ll try to help you out – next time we’ll be covering setting up the Eclipse CDT to use the tools we installed in Part 1, and also how to choose which libraries to link to.