05
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
Subtype 01
Subtype 02
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:
Don'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 _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...
The lengths are determined by SStom_Var.
SonLVL definitions for this object are to come.
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
Subtype 01
Spoiler
Subtype 02
Spoiler
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, $90
Don'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.
This post has been edited by Clownacy: 23 May 2015 - 09:16 AM
