Gavin Pugh - A Videogame Programming Blog

So, I alluded to the fact I wanted to begin writing about XNA in my last post. Over the Christmas break I began getting to grips with C# and XNA, and wrote some code to have a go at prototyping a game idea I had. I think it’s pretty cool that you can execute your code on a retail 360 as well. It’s not quite as nice as using a devkit with native code, but it’s pretty close.

Note to Microsoft: Make it easier to launch the XNA connect app from the dashboard. I know it’s not meant to crash, and it doesn’t that often. But I’ve been attempting some dodgy things and I’ve had it fall over several times. It would be great if it appeared at the top of your ‘Game Library’, as the XNA apps themselves do. For the connect app I have to always scroll to the ‘community games’ section and pick it from there.

Environment

Anyway, I thought the best place to start would be to describe the environment I’m working with:

• I’m targeting both 360 and PC for the moment, but there’s every chance I might drop one platform in the future. I have no plans to write anything for the Zune.
• I’ve setup two extra build configurations in addition to the existing ‘debug’ and ‘release’. One named ‘final’, which would be the intended executable for the final version of the game to be dished out to the public. ‘release’ is the configuration which would have optimizations enabled; but would still have some debugging code which I wouldn’t want in the final game executable. ‘release’ would also enable assertion code, which is omitted completely in ‘final’. The second new configuration is ‘profile’, which is the same as ‘final’ for all intents and purposes, but compiles in profiling code. I wrote my own basic profiler, as I had nothing but trouble with nprof on PC.
• I have the code in two portions: I have a library in which I put what I’d deem as my ‘engine’ code, the stuff in there is (relatively-speaking) clean and what I’d want to keep if I scrapped a game idea and went with something else. The other portion is the game-side code, here I’m less fussy about organization whilst I’m just prototyping some ideas. Any code samples I put on this site though will be in a simple form which just an executable target, no libraries.
• The code I do post will be namespaced ‘Cute’. Why? Well, I’m focusing on doing a graphically primitive cutesy style game, with bright colors and simple geo. I’m no artist. Rather than come up with some other namespace for code I put here, I’ll just post the one I use.

Build Configurations

So, on to the build configurations. Here’s an explanation of each, and the extra compilation symbols I define:

Debug: Code optimization is turned off, TRACE and DEBUG are defined. The same as a new project in devstudio would be for it’s debug configuration. I also define the symbols ASSERT and PROFILE for this build. This would be the build I’d drop down to diagnose any problems that were tricky on a release build, due to the code optimizations.

Release: The same as debug, except with code optimizations turned on. TRACE is defined only on Xbox for debug output (see later note), DEBUG is not defined on either platform. This is generally the build I work with most. It runs at a good frame rate, I have assertions and profiling. As mentioned I’d only drop down to the debug build to work more accurately with the debugger.

Final: This is the ‘shipping’ build. Compared to release, the ASSERT and PROFILE defines are removed. Essentially all development ‘fluff’ is out the window; the executable is expected to behave perfectly. The frame rate should also be somewhat better than release too because of this. Though right now given the early stage of my work, there’s really no difference to see just yet.

I define a FINAL symbol here as well, in case I want to conditionally compile in or out pieces of code specifically for this build.

Profile: For this build I use the same setup as final, but with the PROFILE define enabled. I lose the overhead of assert checking from the release build, so have pretty similar performance to my final build. However my profiler is usable, so this build is perfect for testing any optimizations I might perform on the game. I also enable TRACE on Xbox, which is explained a little later.

I’ve shoved some screenshots at the bottom of this post, for clarity too.

Defined Symbols, Debug Output on 360

ASSERT and PROFILE defines? I’ll post in future covering how I use those. It’s pretty straightforward what they do when turned on and off though.

I define the symbols just a tad differently on 360 though. The Xbox 360 only has working debug output with the TRACE or DEBUG defines turned on. Here’s a table showing the debug output functions that are available, and how they behave on the two platforms:

PC

360

So, the defines differ on my 360 build. I have TRACE enabled on my release and profile builds, so I can get output. My profiler though, I hope to eventually get to render to the screen. Instead of it just dumping captured data in text form to the debug window. So I may be able to disable TRACE on my 360 profile build at some point in future.

On PC I route my printouts through System.Console.Write, on XBOX through System.Diagnostics. Trace.Write. I have a locally namespaced function that behaves correctly for both platforms. Yes, I could just have TRACE defined on the appropriate builds for parity… But I just don’t trust that it has zero other detrimental effects on performance.

Phew…

That’s it for the moment. Dry preparation is out of the way, this is more of a primer than anything. Something I can link back to in future to explain my #ifdef madness. Somewhat more useful stuff to come next…

Oh, here’s those configuration screenshots I mentioned:

PC: Debug, release, final, profile.

360: Debug, release, final, profile.