Intel's Destroy the Castle Threading Demo Application

"Destroy the Castle" is an application Intel engineers created to "show how games can take advantage of multi-core processors." The program was first shown at the 2006 Game Developers Conference. A version of Destroy the Castle that implements Threading Building Blocks is available, in addition to the original version which uses traditional threads. This makes comparison of the code a useful endeavor for developers who would like to see the differences between an application that was originally coded using traditional threads and the same application programmed using Threading Building Blocks.

Running Destroy the Castle


I downloaded the original Destroy the Castle (DtC) version onto my Intel quad-core system, unzipped it, and tried running the prebuilt executable (Main_Release.exe, located in the ParallelDemo subdirectory). I immediately received an error message:

"This application has failed to start because d3dx9_30.dll was not found..."


I intentionally keep my system pretty bare, so I assumed this had nothing to do with the actual DtC software build. Sure enough, a quick search told me that this file is part of DirectX. So, I clicked on a link, which brought me to the GamesForWindows.com DirectX page, which then sent me to Microsoft's DirectX download page. After becoming extremely annoyed about being required to have my very clean copy of Windows "validated," I was able to download and install DirectX.

... hmm ... oh, I see how it works, arrow keys and mouse ... interesting ... what are all those red things? ... dum de dum dum ... take that, you helpless hapless tottering tower!!!

Oops! my apologies for the delay. Now that the game works, I got carried away... Seriously, does anyone know what those little creatures that scramble around on the ground are? Fortunately, it doesn't look like they are hurt by any of the damage...

Oh no! I was wrong. They can indeed be squashed by the cannonballs. Cool! Moving targets!

And not only that, but you can shoot new cannonballs into old ones, and watch them ricochet around.

Fortunately, your cannon is impervious to rocks that fall on it and everything else. So you can just play away!

An interesting and fun semi-serious thing to do with DtC is to switch on the Statistics Graph (hit the "G" key), then get some action going (for example, hold down the left arrow key), and toggle between the single-threaded and multi-threaded versions (hit the "T" key), while watching the graph. Also, note the performance change. It's quite dramatic on my quad-core machine.

I have one tiny suggestion for the DtC development team: can you make it so the cannon can shoot straight up? Then the player could shoot a cannonball up, and then skeet shoot at it while it's on its way down. That would add even more fun! Actually, I've got the code, so maybe I'll make that change that myself!

So? It's just a game. Who cares?


To be honest, I'm not a gaming fanatic, myself. But most of my professional work has been in the area of scientific modeling of complex systems, so I have a pretty good understanding of the type and volume and complexity of calculations that have to be occurring to make the physics of motion and momentum realistic in this game. The ability to pan your view, with the images remaining seamlessly drawn, requires enormous amounts of computation as well. Not to mention hundreds of little red creatures scurrying around, sometimes agitated, sometimes calm.

So, in playing Destroy the Castle, I'm running a very serious computationally-intensive piece of software. In my view, DtC is a great example of an application where multithreading techniques can be applied to make software run faster on modern multicore systems; and hence, make the user's experience that much better.

A quick code grep and grep | wc


The total number of *.cpp code lines in the traditionally threaded version (directory ParallelDemo) is 9555. The total number of *.cpp lines in the Threading Building Blocks version (directory ParallelDemoTBB) is 9759. A grep for "thread" in the traditional threading version cpp files returned 168 lines of code. A grep for "tbb" in the TBB version returned 56 lines. The "grep -i tbb" lines included atomic, queuing_mutex, task, and task_scheduler_init constructs.

Simple Unix grep and wc overviews of the code don't tell us much, of course. The line counts are actually a bit of a surprise. I plan to do a line-by-line differencing study of this code, and I'll report what I find in an upcoming post.

Conclusion


I really do feel sorry for the funny red creatures, now that I realize my cannonballs -- and the falling boulders -- can squash them; but it also kind of looks like they may have pretty nasty teeth, so I don't feel too too bad...

For more complete information about compiler optimizations, see our Optimization Notice.