This weekend, I intended to tinker with a small Space Invaders style game.

I had already developed a basic function to display sprites, but this time I needed something cleaner, faster, more optimized.

In theory, the idea was simple.

I wanted a rendering function capable of handling transparency, meaning it would not touch the background color, and a clean function that would only need to write 0 into the shape bank to erase the sprite, without ever modifying the color bank.

On paper, everything was crystal clear.

In practice… much less.

Script adaptation and transparency constraint

I modified my Python script that converts a PNG into a C structure, adding a --transparent parameter.

With this parameter, the script guarantees that only the FB color bank is used to draw the sprite, concretely this means I can no longer use two colors per block of 8 pixels, I can only use one color in addition to the background color.

The goal was clear, allow fast rendering compatible with a simple erase mechanism based only on the shape bank.

AI debugging weekend

To help me with this optimization, I asked Claude.

We discussed it, I explained what I wanted to do, he provided code, it looked consistent.

Unfortunately, putting it into practice was not easy.

Impossible to get a clean result when moving the sprite.

At first, I thought it was coming from my optimized movement function. So I bypassed it and replaced it with a simpler approach, erase the sprite, then display it at the new position.

Still trails.

I didn’t know whether the issue came from the clean function or from the sprite drawing itself. Everything seemed logical, the background color was normally never modified.

An obvious bug, but impossible to understand where it came from.

I put Claude, ChatGPT and Gemini on the case.

They all came up with theories, incorrect background color reads, memory alignment issues, synchronization problems.

ChatGPT thought I had an issue when reading the background color. So I decided to store the background color in memory before modifying anything. No change.

I even went as far as forcing the background color to C_WHITE, just to remove any ambiguity.

Still the same trail.

Breaking down the problem

I decided to calmly go step by step.

Background display, ok.

Sprite display, sometimes an orange color appeared as background color, but only at the top of the sprite.

Sprite clear, the background was replaced by orange, but not everywhere, only in certain spots.

Nothing consistent.

And I understood even less the explanations generated by the AIs, which sounded plausible but didn’t match reality.

Frustrating.

Testing on the real machine

After a well deserved break, I had a simple idea.

Test on a real MO5.

And then…

No more trails.
No more artifacts.
Sprite displayed perfectly.
Movement was flawless.

I had already been fooled once with colors that were different between the emulator and the real machine.

This time, it wasn’t about the palette, but about behavior.

DCMOTO does not emulate the rendering exactly in this specific case.

From now on, I’ll avoid trusting it too much. I’ll probably use an online emulator like this one https://scemino.github.io/yame_wp/mo5.html

Or even better, test directly on the real machine whenever possible.

Positive end of the weekend

In the end, the weekend finished on a good note.

I updated my SDK with this new feature, rendering a sprite with a transparent background, compatible with fast erasing based only on the shape bank.

I think I now have everything I need to seriously start my game.

Now I just need to get started 😉