https://nicole.express/2021/alf-2-alf-harder.html

Nicole Express [ ]
All Posts Games @ itch.io

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

Aug 14, 2021

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 title screen

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.

Alf dies

Alf does not die, though the bat comes close

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.

Alf jumps. The background flashes red at certain frames.

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.

This is a France-region Master System 2 with Alex Kidd in Miracle
World built-in; because the French systems were RGB but had no
composite output, I'm using this with HD Retrovision composite cables
and the special adapter they sell. This is my first time using HD
Retrovision cables; screenshots were captured with a cheap USB 3.0
card using the OSSC.

Alf stands there while a bat spawns. The background is never red.

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

Alf stands there while a bat spawns. The background is red.

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.

My Hero intro cinematic

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.

There are four Ava sprites. One is close but does not overlap the
other. The border is red.

There are four Ava sprites. One does overlap the first one. The
border is black.

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...

There are four Ava sprites. One is on the edge. The border is black.

There are four Ava sprites. One is on the edge. The border is red.

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...

Two Master System cartridges. One is the Everdrive X7 flash cart, the
other is ALF.

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.

Alf stands in the spot

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.

Alf stands in the spot, he is slightly lower

Alf stands in the spot, he is slightly higher

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...

Once upon a time there was an alien life form. His home planet
exploded leaving him stranded in space with his friend Skip and his
girlfriend Rhonda. Rhonda and Skip went to Mars. Alf crash-landed on
Earth where he became friends with a wonderful family. Life was
great... even though they would not let him eat any cats. Then one
day Alf decided to fix his spaceship so he could visit his friends on
Mars. Being very smart, he decided to sell the story of his adventure
to Sega so they could make it a game. They did and decided that ig
anybody ever read this book they would have to go back to the
beginning of the game. Suprise... ha.

Nicole Express

  * Nicole Express
  * nicole at nicolebranagan dot com

  * nicole_express
  * nicolebranagan
  * Patreon

Nicole Express: Video game development, examinations into old
consoles, and more! Filmed in front of a live studio audience.