How to fix MZ's sideways stompers

This will target the latest Git (and I mean latest, this relies on a commit I just made).

obj45. Some may know this as the horizontal spikes-on-pole object from early Marble Zone. It's seen use in hacks that are either just trying to be creative or attempting to restore 'beta MZ'. But did you know that the object has three subtypes, and that only the default one works properly?

Let's check them out.

Subtype 00

Spoiler

Looking good.

Subtype 01

Spoiler

Uhh.

Subtype 02

Spoiler

Well...

Things aren't looking too good for the last two, there. So, let's see what we can do about it.

Subtype 01
Let's start with fixing subtype 01. The problem here are the mappings, they're unfinished (seriously, it looks like the guy was halfway through editing a copy/paste job when he gave up).

Open up _maps/Sideways Stomper.asm, where we'll immediately see our first problem: the offset table has enough entries for six pole frames. Each pole frame is longer than the last, but the final two are the same (actually, the last three are identical, but we'll get to that later). For now, make the sixth pointer point to @pole6 (or .pole6, if you're using the AS assembler), which we'll add in a bit.

Scroll further to find @pole5 (or .pole5, you get the idea), where you'll see our next problem. I'm not gonna explain how mappings work (SCHG FTW), but let's just say that @pole5 (and technically @pole6) is identical to @pole4 because they have the same number of 'pieces'. At least, that's what the header says. In reality, there exist 10, but the header doesn't point them out, leaving them unused. Correcting this is simple: just replace the '8' with '10' (or '$A' if you want the hex equivalent).

Of course, we're not done yet. We may have fixed one frame, but we need to fix two, or the pole will still appear too short. Create a duplicate of @pole5, and name it @pole6. Duplicate its last two lines, and make it so each line's final value is $10 more than the previous line's, giving you this:

@pole6: dc.b $A
dc.b $F8, 5, 0, $41, $E0
dc.b $F8, 5, 0, $41, $F0
dc.b $F8, 5, 0, $41, 0
dc.b $F8, 5, 0, $41, $10
dc.b $F8, 5, 0, $41, $20
dc.b $F8, 5, 0, $41, $30
dc.b $F8, 5, 0, $41, $40
dc.b $F8, 5, 0, $41, $50
dc.b $F8, 5, 0, $41, $60
dc.b $F8, 5, 0, $41, $70
dc.b $F8, 5, 0, $41, $80
dc.b $F8, 5, 0, $41, $90Don't forget to set the header to $C, to reflect the two new pieces.

You should now be able to save and build, and...

Spoiler

Goddammit.

So, what's up this time? It seems, beyond $80, the last value (X-pos) wraps, hence why the first pieces start at $E0. But if we reduce all values by $20, making the last value <$80, then the pole will be $20 off centre. Lucky for us, we can make the pole -$20 off centre as well, negating this.

Open _incObj/45 Sideways Stomper.asm, and take a look at SStom_Var. You can see the value 'xpos' value of 'pole'. Add $20 to it. Now we can go through the mappings, subtracting $20 from all final values of each sprite piece (remember to only do this to @poleX, leave non-pole sprites as-is).

And with that, subtype 01 is fixed.

Subtype 02
Now how about subtype 02, that thing was a black hole!

This one's much simpler. Open _incObj/45 Sideways Stomper.asm, and take a look at SStom_Len/word_B9BE. You can see that there are three entries, one for each subtype, so this can't be our problem. Instead, look at off_BAD6. Now things are looking goofy. Again, supporting the whole 'unfinished' idea, we have a useless offset table that does not account for invalid values, and lacks a pointer for subtype 02.

To reiterate, this thing points to the same code, and only works with subtypes 00 and 01. What alternate code, if any, this would have pointed to, if it were finished, is a mystery. It seems the best we can do is just make subtype 02 point to the same code as 00 and 01. We won't be needing this pointer table, I can tell you that much. Just delete everything from (and including) SStom_Move's 'moveq' until (and including) the label 'loc_BADA'. With that, we're done.

Conclusion
Now, all three subtypes should be functional. What we're left with is...

• Subtype 00 - Short length
• Subtype 01 - Long length
• Subtype 02 - Medium length

The lengths are determined by SStom_Var.

SonLVL definitions for this object are to come.

 

I converted the guide to Hivebrain

This will target the Hivebrain 2005 disassembly.

obj45. Some may know this as the horizontal spikes-on-pole object from early Marble Zone. It's seen use in hacks that are either just trying to be creative or attempting to restore 'beta MZ'. But did you know that the object has three subtypes, and that only the default one works properly?

Let's check them out.

Subtype 00



Looking good.Subtype 01



Uhh.Subtype 02



Well...Things aren't looking too good for the last two, there. So, let's see what we can do about it.

Subtype 01
Let's start with fixing subtype 01. The problem here are the mappings, they're unfinished (seriously, it looks like the guy was halfway through editing a copy/paste job when he gave up).

Open up _maps/obj45.asm, where we'll immediately see our first problem: the offset table has enough entries for six pole frames. Each pole frame is longer than the last, but the final two are the same (actually, the last three are identical, but we'll get to that later). For now, make the sixth pointer point to byte_BCFA2, which we'll add in a bit.

Scroll further to find byte_BCFA, where you'll see our next problem. I'm not gonna explain how mappings work (SCHG FTW), but let's just say that byte_BCFA (and technically byte_BCFA2) is identical to byte_BCD1 because they have the same number of 'pieces'. At least, that's what the header says. In reality, there exist 10, but the header doesn't point them out, leaving them unused. Correcting this is simple: just replace the '8' with '10' (or '$A' if you want the hex equivalent).

Of course, we're not done yet. We may have fixed one frame, but we need to fix two, or the pole will still appear too short. Create a duplicate of byte_BCFA, and name it byte_BCFA2. Duplicate its last two lines, and make it so each line's final value is $10 more than the previous line's, giving you this:

byte_BCFA2: dc.b $A
dc.b $F8, 5, 0, $41, $E0
dc.b $F8, 5, 0, $41, $F0
dc.b $F8, 5, 0, $41, 0
dc.b $F8, 5, 0, $41, $10
dc.b $F8, 5, 0, $41, $20
dc.b $F8, 5, 0, $41, $30
dc.b $F8, 5, 0, $41, $40
dc.b $F8, 5, 0, $41, $50
dc.b $F8, 5, 0, $41, $60
dc.b $F8, 5, 0, $41, $70
dc.b $F8, 5, 0, $41, $80
dc.b $F8, 5, 0, $41, $90Don't forget to set the header to $C, to reflect the two new pieces.

You should now be able to save and build, and...



Goddammit.

So, what's up this time? It seems, beyond $80, the last value (X-pos) wraps, hence why the first pieces start at $E0. But if we reduce all values by $20, making the last value <$80, then the pole will be $20 off centre. Lucky for us, we can make the pole -$20 off centre as well, negating this.

Open sonic1.asm, and take a look at word_B9BE. You can see the value 'xpos' value of the third entry. Add $20 to it. Now we can go through the mappings, subtracting $20 from all final values of each sprite piece (remember to only do this to the poleX, {fourth byte onwards} leave non-pole sprites as-is).

And with that, subtype 01 is fixed.

Subtype 02
Now how about subtype 02, that thing was a black hole!

This one's much simpler. Open sonic1.asm, and take a look at word_B9BE. You can see that there are three entries, one for each subtype, so this can't be our problem. Instead, look at off_BAD6. Now things are looking goofy. Again, supporting the whole 'unfinished' idea, we have a useless offset table that does not account for invalid values, and lacks a pointer for subtype 02.

To reiterate, this thing points to the same code, and only works with subtypes 00 and 01. What alternate code, if any, this would have pointed to, if it were finished, is a mystery. It seems the best we can do is just make subtype 02 point to the same code as 00 and 01. We won't be needing this pointer table, I can tell you that much. Just delete everything from (and including) Obj45_Move's 'moveq' until (and including) the label 'loc_BADA'. With that, we're done.

Conclusion
Now, all three subtypes should be functional. What we're left with is...

• Subtype 00 - Short length
• Subtype 01 - Long length
• Subtype 02 - Medium length

The lengths are determined by Obj45_Var.

SonLVL definitions for this object are to come.