Alf 2: Collision Detection is Hard, Blog Posts are Harder

Remember Alf? He’s back, much sooner than I expected. In fact, I wasn’t expecting to cover this topic again. But the post on Alf has proven to be one of the most successful in the history of this blog, and it wasn’t very clear about my conclusions, and I could’ve done better, so let’s pick this up and beat this topic into the dust.

Part 1: The Conclusion

This is just a summary of the first post. Feel free to skip it.

ALF for the Sega Master System was released in 1989, exclusively in the United States. A one-megabit “mega” cartridge, it was developed by Nexa Corporation. It is widely regarded as being one of the worst games on the platform; but that’s not that important right now. What we covered before was an interesting glitch: when played on a Genesis with the Power Base Converter, a bat appears to have a larger collision detection bounding box than when played on a Japanese Master System.

What we found in the last blog post was the following:

1. ALF uses the rarely-used hardware collision detection feature of the Master System. This feature triggers a flag when two sprites collide, but does not tell you which sprites collided.
2. When that flag is set off, the game uses a software collision detection routine to determine which sprites collided. This routine is very “sloppy”, and its possible for two sprites that are just near each other to trigger a collision, if two sprites elsewhere collide.
3. On the Sega Genesis, at the point of the glitch, a second bat spawns earlier than it did on the Master System.

I presented what I felt was a reasonable conclusion: that while a bat was being spawned on-screen, its positioning seems to have involved overlapping sprites for one or two frames. This causes the software collision detection to trigger, and Alf is close enough to the other bat that the game decides to kill him off just in case.

I felt this was all plausible. But was it correct?

Spoiler Warning: No.

Onto the new stuff

So, I claimed in the last post, based off of a trace log, that when the game spawns a bat, it causes a sprite collision. This was based off of a trace log that I was careful not to collide with any enemies.

But it’s not very definitive. I mean, I don’t know when those traces happened. So instead, I turned to ROM hacking. Remember my collision detection program in the last post? I took that logic and replaced the hardware collision detection with it. Now, the border will turn red when a collision is detected.

Where did I get the space for this routine? I just overwrote the software collision detection.

The detection frames were caused by Alf’s jump animation overlapping sprites on Alf himself. I did jump while taking that trace. So it’s not very useful, though it does imply that people playing this game will find worse collision detection while jumping then while walking. Nice one.

Spawning

But wait, you say! That above screenshot doesn’t have the spawning, so that could still have collisions, right?

Let’s take a look. These graphics are a bit distorted because they’re running on a PAL Master System 2; I did this for the blog so that I could more easily determine which images came from which system, however this reproduced on my NTSC Master System 1 as well.

Cool, cool. So there goes that theory.

Now, of course, we should just confirm that this doesn’t happen on the Genesis with Power Base Converter, just to be sure. I mean, the code’s the same, and the hardware’s pretty close, so

Say what?

It all comes back around

Alf scrolls horizontally. What other game scrolls horizontally on the Master System? Well, uh, a lot. But right now we’re talking about My Hero.

As I noted in the prior blog post, the Sega Master System has a tilemap that’s only 256 pixels wide, the same as the display area. Therefore, the image is slightly off-center; the hardware lets you mask off the first eight pixels. You can see the same thing happening in ALF screenshots above; when the background color is not the same as the border color, it’s more obvious.

Now, let’s look again at my collision detection test program. Remember, the colors here are reversed compared to above. Red refers to no collision, and black refers to a collision. This is my own fault.

The border is essentially even all the way around. (It is still slightly offset, but in this case that’s the console’s fault.) You can count the square background tiles if you don’t believe me; each is 16 pixels wide. Obviously, since my collision detection test ROM doesn’t scroll, I didn’t bother masking.

But let’s try masking now. Note that since I last messed with my test ROM, I was using it to play with double-sized sprites. That has no impact on this, since double-sized sprites don’t work on the Genesis anyway. (As far as I know, no released Master System games used them) And in this test rom, a collision still changes the background to black. Sorry, sorry, I know, writing all these apologies was probably more work than changing the two bytes to make things consistent…

That’s right.

Conclusion: The Sega Genesis VDP will mark a sprite collision if it occurs in the masked region. The Master System VDP does not.

Why is this? I don’t know. Perhaps the Genesis implements the masked region internally by using the extra sprites that Genesis mode allows; I guess you’d have to decap and analyze the die to know for certain, and I don’t have the skill to determine that. In any case, if the only tradeoff here was “make ALF slightly harder”, it was probably worth it.

One last thing…

A lot of people have attributed the bug to the use of a Master Everdrive (in this case, the X7). Now, of course, this bug, if it’s what I described, shouldn’t matter. And many people would rather use an Everdrive, as for some reason ALF is kind of a rare game and goes for too much money on the aftermarket, so you might not want to put too much wear on it.

But it’s true that if you launch the game from the Everdrive menu and wait on the title screen, the demo shown kills Alf at the point. Whereas on the real cartridge, it doesn’t.

Well, that’s not quite true. If you break out the real cartridge and let the demo run twice, you can see this. If we back up one frame from the death point, we can see a single pixel of the spawning bat that causes the problem. Let’s compare a run with death with one without, stopping on that one-pixel frame.

Did I say this game was wonky? This game is wonky. To stress how timing dependent this demo is, I can’t actually take a comparison screenshot from the PAL Master System. There, Alf fails to jump onto this ledge at all.

These differences can be attributed to all sorts of things, but if I had to guess, all models of the Master System (but not the original Mark III) have a BIOS which initializes memory to zero. The Power Base Converter does not. ALF does not zero out memory on startup except for a small region, so it’s dependent on the BIOS to do so– I also don’t know what state the X7 leaves RAM in.

Take me, Alf, to the Ball-Game

This ends the saga of ALF on the blog. Okay, so I thought the last post would do that. But for real, now, I think. The Genesis VDP hardware collision detection bug in Master System mode when the leftmost eight pixels are masked is, as far as I know, undocumented and never seen before, so that’s kind of nice. On the other hand, it really is getting into the weeds.

I recommend we put this game aside. Put all games aside, and curl up with a nice book. It’s over now. A book about Alf? I mean, I guess, if you really want to…