Managed World

Personally, I think logging is something that is often overlooked by hobbyist developers. I personally have found good logging at work to help tremendously. So, whenever I get a chance, I like to try to do "The Right Thing" on my home projects.

When developing games, I think it is especially important to be able to get insight into the application while it's running. Sometimes you need to poke under the hood and see how the ole' girl is running, right? Well, in that vein, I hooked up my logging system for the game engine a couple of days ago (I should say, I hooked up my *viewer* a couple of days ago because I've been logging since day one (then again, what good is a log if it's never used, eh?)).

First of all, I had to make a few decisions when building my logging framework. Whenever possible, I like to avoid rolling my own. Call me old or pr3t3nd3r or whatever you young kids do these days, but I happen to enjoy spending my time doing the important things, rather than re-inventing the wheel. With that in mind, I decided to piggy-back on the existing framework that's already in place for Trace. All I had to do was write a custom Trace listener (and the only reason I did that is I wanted some custom formatting) and add it to Trace. Then throughout my application when I want to log messages, I simply write them to Trace. The code doesn't know anything about a logging framework whatsoever (well, sort of, it does introduce a dependency on Trace which I'm using *as* a logging framework; so I suppose you could semantically argue that it does know about the logging framework).

By hooking onto Trace, I can also reuse all the functionality that is already in place. For instance, if I want to log to both a log file, and an in-game log viewer, no problem, just add two listeners. I'm rather proud of this (I don't know why, perhaps the simple things are the things that make me happy), so I figure I'd share what it looks like. As you will notice, my log file is color-coded. That is achieved by using an application called BareTail (it's absolutely free of charge and no install necessary). I was exposed to this at work and have been using it since in my personal projects. You can change the coloring of different lines based on "keywords" that exist within the line.

And a close up of what a snippet of the log actually says:

Any of you hobbyist game developers out there, I HIGHLY suggest you hook in a logging system if you haven't already. Trust me (or don't if you wish (although I would have a few choice words for you in THAT situation)), it will really help you gain an insight into what's happening when (although you should largely know this already). It's almost a form of "eXtreme Debugging" for game developer (a term I believe originally coined by Andre Le Mothe in the game development sense).

Well, it looks like the Game Development track that I'm heading up for Portland's Code Camp (you registered yet?). Here is the tentative lineup (it might still change, but I'm hoping that it won't too much).

- Introduction To Managed DirectX, David Weller

- Message-Oriented Game Development, Jason Olson

- Warplanner - Post Mortem of a Managed DirectX Game, Chris Goldfarb

- Implementing Creature AI, Chris Williams

- Behold My Bouncing Balls, Jason Mauer

- The Power of Scripting - Tribes RPG - Robert Under

- Introduction to Shaders - Andy "Zman" Dunn

It looks like a real fun line up for a Code Camp (especially the first one). I'm just hoping that it turns out to be a hit. SOOOOO, if you aren't coming (or you know people that aren't coming), tell them to get their tookis into gear and register already!!! (and if you're feeling especially well, go buy some of Rory's crap punk (I will too soon Rory, it's just too bad you don't have Size Lard Bucket))

For some reason, the maintenance downtime message for bloglines absolutely made me laugh. Perhaps I'm just in a stupid mood:

[Update: I added the assets directory to the source zip and re-uploaded so y'all should have everything you need to actually compile and run the code.]

Well, the rudimentary scene graph is done and hooked into Tanks! Below is a quick and dirty screenshot (remember this is still programmer art).

I was asked the other day if I was going to release source code and I figure, what the hell. Just keep in mind that this is FAR from being a finished product (hell, it's even FAR from being any kind of product at all). So, if you are interested in seeing the source code (albeit totally undocumented source code), you can download it from here. SOOOO, don't even try to ask for documentation because there's no way you're getting it until the articles are written :).

Mykre recently sent out a reminder that there is an IRC channel for Managed DirectX on EFNet. So, if you want to come around some time, feel free to (it seems like it is pretty quiet (hopefully we can change that)). I'm on there, Mykre is on there, Tom Miller hangs out there (although I hear he's pretty silent), and ZMan says that he'll start checking it out. So, grab an IRC client and head on over anytime (I personally use ChatZilla for FireFox).

When an exception occurs while running the sample framework, even if it is handled in a global exception try-catch block, the sample framework will throw an unhandled exception on Dispose. To replicate this issue, simply open up the empty project template and change line 238 in EmptyProject.cs from:

effect.SetValue("appTime", (float)appTime);

to (in order to force an exception):

effect.SetValue("appTm", (float)appTime);

Although it perhaps is not the best fix, the quick and dirty fix for this is to change lines 3948-3957 in the Dispose method in Common\dxmut.cs from:

if (Window != null)
{
// If we have a window, use BeginInvoke to start shutdown
Window.BeginInvoke(new DisposeDelegate(this.Shutdown));
}
else
{
// Otherwise, call it directly
Shutdown();
}

to just:

Shutdown();

Happy Programming!