Yesterday, I was given a task to display lots (and I mean lots) of diagnostic text on the screen, while in game, on a development build of our latest goodness. Problem was, our debug font was far too big for the job – something I (foolishly) didn’t realize until the programming work as done and I first saw the glob of overlapping, unreadable text on the screen. It was mess.
The solution to such a problem sounds simple enough: just pick another font.
But this is console game development where we render strings to the screen via pieces of a texture like this one …
Note that simply scaling the source texture won’t work, as the boundaries of each alphanumeric character must be an integral constant (in the case above, 11 pixels wide and 21 pixels high). Plus, for historical reasons, I couldn’t simply scale down the destination quad we render the texture too. That seems like an oversight, and perhaps something I could worked up about, but it’s just the way it is.
So, I’m left with three choices:
- Refactor the rendering engine to support scaled debug text geometry.
- Drop, or scale back, the feature.
- Find or make a source texture with the same character layout as the image above, but with a smaller, yet readable, font.
Option one is out -we’re just too close to ship to make any kind of risky change to a major subsystem unless it gives us functionality of the highest priority. And I’m swamped with other bugs and support issues anyway.
The second option, ditching the feature, isn’t desirable because our guys could really use the extra diagnostic information and the work for it is “done” – but often it’s better not to chase after feature creep.
What about the third option? Sounds great, but how the hell is a programmer with little artistic or typography skill going to cook up a replacement texture?
And then it hit me: Years ago I spent some time on a pet project application exploring rendering the awesome looking outlined fonts you’d find in video games from the NES days. It didn’t do anything but utilize some C# GDI functions and the .NET PropertyGrid to let me experiment with font rendering and, like most pet projects, it didn’t go anywhere.
Or I mean, it didn’t go anywhere – except my online code repository.
Now would you believe it took me mere minutes to download the source from that old do-nothing application and edit it to display the ascii characters in the order required? The application was already set up to change the font selection, size, color, and outline on the fly – so with a little mucking about I had something that looked reasonable.
And then two minutes later I had added a routine to save out that text into a texture. Not bad, eh?
Done and done. The new text even looks better too! I just love days like this when stuff falls into place so elegantly and a solution emerges.
I do a lot of pet-project programming, and often I don’t feel like bothering to prepare my code for submission (namely, just making sure I don’t check in a bunch of OBJ, SUO, and NCB files) – but I always do it, even for the most trivial of code – and examples like this are the perfect justification for doing so.