I discovered two vaguely interesting and unusual things about the vertical fireball/Podoboo (sprite 33). First, did anyone ever wonder just why it freezes the game when sprite buoyancy isn't turned on? It's because of this snippet of code in its INIT routine:
CodeCODE_01E05B: B5 D8 LDA RAM_SpriteYLo,X
CODE_01E05D: 18 CLC
CODE_01E05E: 69 10 ADC.B #$10
CODE_01E060: 95 D8 STA RAM_SpriteYLo,X
CODE_01E062: BD D4 14 LDA.W RAM_SpriteYHi,X
CODE_01E065: 69 00 ADC.B #$00
CODE_01E067: 9D D4 14 STA.W RAM_SpriteYHi,X
CODE_01E06A: 20 40 91 JSR.W CODE_019140
CODE_01E06D: BD 4A 16 LDA.W $164A,X
CODE_01E070: F0 E9 BEQ CODE_01E05B
To put it simply, the code moves the sprite down a tile until it touches lava or water. But to add more detail...well, the sprite's initial Y position is already saved in $1528,x/$151C,x. (That's how it determines how high to jump.) Here, the sprite gets moved down a tile, then the object contact routine is run, then $164A,x is checked. $164A,x is often used to check if a sprite is in water or lava; if it is nonzero, then the sprite is in water or lava. However, this only works if sprite buoyancy is on. The init routine here keeps moving the sprite down until $164A,x is nonzero, but if sprite buoyancy is off, then $164A,x is never set at all. And if this occurs, then the code gets sent into an infinite loop.
The other thing I noticed...well, while disassembling the sprite, I noticed that it references $C2,x several times. But it never
stores anything to that sprite table, nor does it change it in any way; it just loads and compares it. This would make sense if there were another sprite that shared its code with that one, but the only other sprite that fits the bill is sprite B5, the so-called "sinking fireball used in boss battles", and its init routine just returns, so it never changes $C2,x either. BUT...take a look at this piece of code:
CodeCODE_03A800: A9 33 LDA.B #$33
CODE_03A802: 99 9E 00 STA.W RAM_SpriteNum,Y
Yes, it's the Podoboo being spawned from somewhere. This is part of the code that handles the Bowser fight scene, in case you're wondering. (By now, you might know where I'm going with this.) Well, guess what occurs soon after that?
CodeCODE_03A825: F6 C2 INC RAM_SpriteState,X
Yes, Bowser spawns sprite 33, but in sprite state 01, which means that it acts completely different from the normal one we place in Lunar Magic. What it acts like is...the fireballs that fall from the sky in between fight rounds. Where does sprite B5 come into play? It doesn't. Nowhere in the entire code of SMW is sprite B5 even used at all, unless I just suck at finding things. My hypothesis is that sprite B5 was originally supposed to be a close variant of sprite 33 with $C2,x nonzero and a few other settings slightly altered (the spawning routine also messes with some of the Tweaker values, enabling the sprite to interact with objects and changing its clipping value), and
it would be the flame spawned during the Bowser battle, but it never made it into the final version of SMW.
----------------
I'm working on a hack! Check it out
here. Progress: 64/95 levels.