Tentative Explanation for the Tails Life Box

Quickman · Aug 26, 2005

Tweaker and I were engaged in a conversation in the chatroom regarding the green emerald in HPZ. He was sticking to his guns that it was intended to be a breakable object, while I played devil's advocate and looked at the evidence against that theory.

It seemed odd to me that they would compile and use an unfinished object in the beta (especially when the complete object is simple enough that it's easy to make in one sitting). So I decided to grab a disassembly from the final (I assumed that little work had been done on the object between our beta and the final), work through commenting it, and see if there was any code which might indicate a breakable object in development.

It turns out there wasn't, but what I did find was interesting and raised a question.

The object is the simplest of formats - just two functions, the initialisation and the display function.

Code (Text):

SolidObject  EQU $19718

DisplaySprite  EQU $164F4

DeleteObject  EQU $164E6

TwoPlayCompat  EQU $16D6E

HPZ_Emerald:

 moveq #0,d0  ; clear d0

 move.b $24(a0),d0 ; grab the current function call

 move.w FunctionOffset(pc,d0.w),d1; grab the entry from the offset index...

 jmp FunctionOffset(pc,d1.w); ...and jump to it

FunctionOffset: dc.w Initialise-FunctionOffset; initialisation function

 dc.w Display-FunctionOffset; display function

Initialise:

 addq.b #2,$24(a0) ; increment the function call

 move.l #Mappings,4(a0) ; grab the mappings

 move.w #$6392,2(a0) ; set the VRAM to use

 bsr.w TwoPlayCompat_Jump ; subroutine call ()

 move.b #4,1(a0) ; set action flags

 move.b #$20,$19(a0) ; set object width (20 pixels)

 move.b #4,$18(a0) ; set sprite priority

Display:

 move.w #$20,d1  ; collision area width

 move.w #$10,d2  ; collision area height

 move.w #$10,d3  ; action area height

 move.w 8(a0),d4 ; X playfield coordinate

 bsr.w SolidObject ; subroutine call (solidity implementation)

 move.w 8(a0),d0 ; move X playfield coordinate into d0

 andi.w #-$80,d0 ; eliminate negatives

 sub.w ($FFFFF7DA).w,d0; subtract unknown RAM value

 cmpi.w #$280,d0 ; is the result equal to $280?

 bhi.w DeleteObject_Jump; if it's higher than $280, branch

 bra.w DisplaySprite_Jump; else branch to a different offset

Mappings:

 dc.w FirstSprite-Mappings; mappings offset index

FirstSprite: dc.w 2  ; 1x2 sprite

 dc.w $F00F,    0,    0,$FFE0; first block

 dc.w $F00F,  $10,    8,    0; second block

DisplaySprite_Jump:

 jmp DisplaySprite ; subroutine call (display sprite onscreen)

DeleteObject_Jump:

 jmp DeleteObject ; subroutine call (delete object)

TwoPlayCompat_Jump:

 jmp TwoPlayCompat ; subroutine call (make address compatible with 2P)

Now, I had some trouble identifying the 2P compatibility subroutine (I identify most subroutines by comparison with Hivebrain's S1 disassembly, and S1 doesn't have 2P). I found the identification by searching for "sub_16D6E" on this very forum, which pulled up this post by LOst.

This illuminates two things:
1) We need a commented S2 disassembly.
2) HPZ may have been considered for 2P mode.

2) could be an explanation for the Tails life box (as guess_who suggested in the chatroom).

Discuss. (And could someone try and put together an S2 disassembly?)
EDIT: "2PCompat" is not a valid label. Hivebrain told me off for that, so I fixed it.

Aurochs · Aug 26, 2005

Quick Man said:

And could someone try and put together an S2 disassembly?
Click to expand...

Both Hivebrain and myself are working on improving the S2 disassembly.

As for the "Tails 1-up" explanation, no comment. Because I can't add anything. =P

Ultima · Aug 26, 2005

That 2P Compat thing is called by most objects. Including the title screen menu.

Quickman · Aug 26, 2005

It only does anything in 2P mode, as you yourself pointed out.

Code (Text):

tst.w ($FFFFFFD8).w

beq.s locret_16D88

It strikes me as odd that they'd call it in all objects, but that's what they did.

LOst · Aug 26, 2005

First of all, all the objects uses a macro to divide the VRAM address by 2 if in 2P VS mode, because the mappings format in Sonic 2 has 3P VS support no matter what object it is.

Second, the green stone in HPZ is the exact same object as the purple stone in Sonic 1 GHZ. If it was supposed to be breakable it would have been breakable from the beginning. It is just supposed to be a block, and only appear once in that level, a land mark shown from level select.

Ultima · Aug 26, 2005

Or maybe it was a level designer brain-fart.

Rika Chou · Aug 26, 2005

To me, it has always been obvious that it wasn't going to be breakable. Because if it was, it would be the same sprite as the rock in HTZ, or the block in CPZ. (both these are the same sprite)

but it's not.

Tweaker · Aug 26, 2005

Saxman revealed that the Tails 1-up box was meant to be a Super Ring box. Subtype 10 for the monitor is the tails 1-up in S2, and the Super Ring in S1. Seeing as they didn't correct this either, it questions what they intended to change with the level. If they were too lazy to update an object ID, who says they aren't too lazy to make the Emerald breakable? Craig Stitt confirms it to be a breakable object; I don't see much proving things otherwise.

EDIT: Might not be subtype 10. I forget, but my point remains the same.

Quickman · Aug 26, 2005

As I said initially, it doesn't make sense for them to use a nonbreakable object as a base for an object intended to be breakable when a perfectly good breakable object (the rock from HTZ) exists already.

EDIT: That doesn't work! The subtype value for a Super Ring box in S1 is 06. The subtype value in S2B is 04, like in the final. 06 in the beta is a speed shoes box.

LOst · Aug 26, 2005

Quick Man said:

As I said initially, it doesn't make sense for them to use a nonbreakable object as a base for an object intended to be breakable when a perfectly good breakable object (the rock from HTZ) exists already.

At least that resolves the Tails box problem. Thanks for that.
Click to expand...

A lot of objects were directly borrowed from Sonic 1. A few of the objects from Labyrinth Zone were not that good programmed, and they were still used in the final Sonic 2, in Aquatic Ruin Zone.

So a breakable object could easily be borrowed from Marble Zone if wanted. But the Green Stone was borrowed from the Purple Rock in GHZ.

So the question is not what the Green Rock was supposed to do. The question is: What was the Purple Rock supposed to do in GHZ? When you can answe that question, you can answer the Green Stone question.

Hez · Aug 26, 2005

maybe they intended it to break different?

Aurochs · Aug 26, 2005

Hez said:

maybe they intended it to break different?
Click to expand...

Even then, would it not make sense to base this object off one that already had a working breaking routine?

Rika Chou · Aug 26, 2005

The block in CPZ and the rock in HTZ break different, but they are still the same sprite. (both functional in S2b)

Hez · Aug 26, 2005

Aurochs said:

Hez said:

maybe they intended it to break different?
Click to expand...

Even then, would it not make sense to base this object off one that already had a working breaking routine?
Click to expand...

well I mean like totally different, maybe they wanted it to like.....fucking explode and burn. I know when I make fan-games I sometimes will use another object that does almost the same thing for another, but if I want it completely different Ill start from something more basic....like a rock....but that might just be me

Gunner112k · Aug 27, 2005

>
> Was he going to be the guardian of the Master Emerald
> in the Hidden Palace?

I have no idea what the Master Emerald is. If you are refering to the large emerald in the screen shots, that was simply a 'block' that you had to break inorder to gain access to the tubes beneath. There may have been other things planned for that emerald, but it's been too long)
Click to expand...

Rika Chou · Aug 27, 2005

I recall someone saying that when the emerald hits water, that it disappears. I am no programmer, so I am wondering if this in intentional?

Flame · Aug 27, 2005

Maybe the emerald was supposed to be something sonic had push out of the way? Sort of like the rock in Angel Island act one in Sonic 3, you have to push that rock away inorder to get to the two super ring boxes and the invincibility box.

Weird Person · Aug 27, 2005

maybe they want place a sonic life box but mistyped and typed $02 instead of $01.

or worse, they want place a Sonic life box, but placed the Sonic 1 value instead of Sonic 2 Beta.

(Sonic 1 : $A6 $02 for Sonic Life Box.)
(Sonic 2 : $A6 $01 For Sonic Life Box.)

It's possible.

and also, THE BIG EMERALD IS POINTLESS. even if you remove it from the tube, you won't fall trough the tube. You will have to place a Side Switcher to pass by the tube.

And also, why Hidden Palace was cutten? because the great quantity of Bronken tiles? Because there's no way to hide it (Sonic isn't a RPG, even if it's a thing like "yuo haev teh 7 esmeraldos! go to HPZ!" why it would be in the game? just for I go to Hidden Palace?) ?

Hidden Palace is VERY worked even in the Beta, 219 rings placed, badniks placed, computers played , level layout defined...

Ultima · Aug 27, 2005

no way to hide it? my Hidden Palace was pretty hidden, and I'm sure they, with the source code, can hide it if I, with machine code, can =P

Qjimbo · Aug 27, 2005

Intruiging, so the purple stone in GHZ might've also been intended to break originally, and when putting together HPZ they were like "oo we'll take this break code from Sonic 1" even though they forgot it was never implemented?

Tentative Explanation for the Tails Life Box

Useful Searches