A diagram titled "Texture Pitch" representing a 64-pixel texture shown as a 8×8 image and as a 16×4 image. They both have the same number of pixels, but one looks better for some reason.

Funny bugs: textures be hard

2024-11-29 / Development, Emulator

A few years ago, I ventured into the wonderful world of textures as a way for my emulator to render actual graphics.

More recently, I had a go at it again to develop a simplistic UI for Goholint, which I might write about at some point.

SDL has plenty of useful tools and functions to create, manipulate and draw onto textures. Yet, in some specific cases, I’ve had to write raw bytes to a texture buffer myself.

I mentioned some potential gotchas back then:

We have to know the texture’s exact dimensions in pixels (obviously).
SDL must be told what the texture’s “pitch” is (that is, how many bytes are needed to draw one horizontal line the full width of that texture).
The texture’s internal bytes representing red, blue, green and alpha components must be in the right order (Endianness Is A Pain™).

Exhibit A

So, this is what happens when you get some (or all) of those things wrong. Some of those bugs, I think I can explain¹. Others… not so much. There have definitely been moments where nothing made sense anymore and I just had to revert changes to try again.

I’ll just put those screenshots down below.

One of my very first attempts at drawing pixels to an SDL window. I didn’t even have a name for the emulator back then. The pixel format and texture pitch must have been wrong, and judging from the black pixels at the bottom right, so was the buffer size. But I was still really excited to recognize the Nintendo logo!

I got this screenshot while writing the code for The first (real) pixel and in this instance I definitely got the texture pitch and RGBA order wrong, hence the magenta lines.

A screenshot showing a very garbled Nintendo logo in red over a magenta background. — Another great example of the pitch and RGBA order being wrong. The second picture was obtained by multiplying the pitch value by 4, since pitch is counted in bytes, not in pixels. Those red and magenta hues are what you get when your texture is set to use ABGR and you write RGBA into it.

A screenshot showing the expected Nintendo logo in red over a magenta background. — Another great example of the pitch and RGBA order being wrong. The second picture was obtained by multiplying the pitch value by 4, since pitch is counted in bytes, not in pixels. Those red and magenta hues are what you get when your texture is set to use ABGR and you write RGBA into it.

A screenshot of Goholint showing various labels and bits of text over a partially opaque background. The overlapping labels seem to spell “QuitMe”. — This is the one case where the bug isn’t due to me writing bytes directly into a texture. This is due to me not using the renderer properly and corrupting its state between two drawing operations. The emulator was supposed to show a Goholint header, and two options: Resume or Quit. Here it just looks like it’s begging to be closed.

A screenshot showing the Goholint start screen rendered twice at the top left and top right while the bottom half of the picture if plain green with a few sparse pixels. — Goholint normally renders the Game Boy screen to a 160×144 texture, which is then stretched to the window’s size — usually twice that. In the course of refactoring, I think I must have been writing directly into a 320×288 texture by mistake, but then I’m not quite sure why this doesn’t look more garbled.

A screenshot of a Goholint window that’s almost entirely gray except for a few sparse and random-looking pixels. — I really have no idea what was going on at this time. It was late, I was tired, I think it was an improperly sized buffer. I don’t know.

Lessons learned

I have since learned to use the proper RGBA32 setting for my textures, and I also try to avoid directly writing a texture’s raw bytes, using SDL’s dedicated functions instead. I still occasionally forget that there is only one renderer and I need to be careful with the order I draw things in.

In the mean time, I got some funny-looking bugs. Textures be hard, I swear!

Although to be honest, I don’t always remember exactly what caused the earlier bugs, apart from “I screwed up writing those texture bytes”. The good thing is that those bugs got fixed by Past Me, somehow. Good job, Past Tiger! ↩︎