Categories
Development Graphics

Digital test cards for games

Don’t you hate it when you’re writing some new image loading or texture drawing code but don’t have any suitable test images? I always waste lots of time looking for a “nice” image to test with, and often end up drawing something with distict pixel values so I can pinpoint where any given image loading bug is. With that in mind I’ve spent a few evenings working on a proper “test card”.

TV test cards are a rare sight on broadcasts these days, with most digital channels choosing to just have a blank screen when a channel is off air, but pretty much everyone in the uk will have the famous Test Card F burnt into their retina at some point. Test card design is rather facinating, as all the various elements (blocks of colour, diagonal stripes, etc.) are designed to allow particular elements of a broadcast or tv configuration to be tested and tweeked.

Most of them aren’t relevent to games though, since we don’t have to worry about scan amplitudes and all that mumbo jumbo. Mostly we’re concerned about getting binary data off disk and accurately displaying that on the screen (dealing with file formats, endianness, and display surface formats in the process). So while Test Card F is nice and iconic, it’s not really suitable for our use.

Here’s a couple of my old (crude) test images:

They’re not bad, but by todays standards they’re a little small, the nicer Tails one is an awkward 48×48 and neither of them are good when you’re trying to debug file format, image pitch or similar issues since the borders and colours aren’t terribly helpful.

With those issues in mind, here’s my new test card:

This breaks down as:
1. Well defined an unique border pixels make it easy to see if you’re displaying the whole image or if you’ve sliced off an edge accidentally.
2. The main circle shows is for judging aspect ratio, and making sure you’ve not accidentally streched or squashed it.
3. The checkered edge markings are every 8 pixels, so you can line things up easily.
4. Various pixel patterns in the corners for checking 1:1 pixel drawing.
5. Colour and greyscale bars and gradients for general colour/gamma correction and to highlight colour precision issues.
6. Ticks mark the center of each edge for alignment.
7. Tails is always cool. [grin] Replace with your own favorite character as you see fit. The image and the text make sure you’re displaying it at the correct orientation and not flipping or mirroring it.
8. The empty box at the bottom is left blank for you own logo or text.

One nice “feature” is the very outer border, here’s a close up of the top left corner:

The start of the scanline starts with easily identifiable red, green and blue pixels (which show up as nice round non-zero, non-FF, hex numbers in a debugger’s memory window) which are similar to a text file’s byte-order mark. Just after that the desaturated colours spell out (again, when viewed in a debugger’s memory view) “RedGreenBlue TestCardA 256×256”. Of course if you’re actually loading from a BGR image format that’ll just be a row of junk characters, so directly after that the message is repeated (this time “BlueGreenRed TestCardA 256×256). This allows you to easily identify if you’ve actually calculated the start position of the image header from your image file and that you’re reading it in in the right format and endianness – if you can read “BlueGreenRed” when you were trying to load a RGB image, you know you’ve messed something up somewhere. 🙂

The top right has a similar terminating series of characters:

This time it’s a slightly different hex pattern for the numbers so you can distinguish the start of one scanline from the next. Similarly the rest of the image has two distinct colours all the way down the edges. These are particularly useful when debugging misaligned image data or pitch issues. The bottom row contains the same encoded messages for those crazy image formats which are stored bottom up rather than top down.

So there you go. Use it, modify it, abuse it however you see fit. If I get chance I think I’m going to produce a few variants for lower resolutions (maybe 128×128 and 64×64) plus RGBA versions for testing alpha channels. And suggestions for improvements or tweeks are welcome.

Licensed under Creative Commons 2.0.