Language…
5 users online: anoMaly666,  Atari2.0, playagmes169, sinseiga, Tsquare07 - Guests: 234 - Bots: 261
Users: 64,795 (2,375 active)
Latest user: mathew

The SMW Glitch List

Originally posted by Thomas
NEW! Killing a sprite by sliding into it will set the counter for the number of sprites Mario has killed with a star to 1.


I fixed it. Here's why:

Code
CODE_01A87E:        9C D2 18      STZ.W $18D2
[...](<- Note that the above address is in a subroutine, thats how it reads in that order.)
CODE_01A84B:        EE D2 18      INC.W $18D2


The game first resets $7E18D2, then increments it when killing an enemy, that's how its set to #$01.

Nintendo was originally plan to add a "slide kill chain" gimmick where if you keep killing enemies in 1 go, each points from each enemies will use the same effect to consecutive stomps, and on the 8th and onward rewards a 1-up. This can be proven on SMA2.
Give thanks to RPG hacker for working on Asar.
I found something weird:
Code
CODE_029FFF:        BD 15 17      LDA.W RAM_ExSpriteYLo,X   
CODE_02A002:        38            SEC                       
CODE_02A003:        F9 A2 9F      SBC.W DATA_029FA2,Y       
CODE_02A006:        9D 15 17      STA.W RAM_ExSpriteYLo,X   ;conveyor glitch?


I don't understand why Nintendo does this; making fireballs teleport when they hit a slope conveyor belt.
Give thanks to RPG hacker for working on Asar.
@GHB: It's related to the extended sprite<->layer interaction routine, it sets the index used in $029FA2 (Y position shift) and $029F99 (Y speed) tables (it's modified a bit later, though). The conveyor slopes sets the index to $0C and $FC, which loads some garbage when loading the tables. It's interesting how they set the index for those slopes, it's a bit different that the others slopes.

I think I fixed it with this patch: http://pastie.org/pastes/10523030/text

Probably it needs more testing.


Originally posted by LX5
@GHB: It's related to the extended sprite<->layer interaction routine, it sets the index used in $029FA2 (Y position shift) and $029F99 (Y speed) tables (it's modified a bit later, though). The conveyor slopes sets the index to $0C and $FC, which loads some garbage when loading the tables. It's interesting how they set the index for those slopes, it's a bit different that the others slopes.

I think I fixed it with this patch: http://pastie.org/pastes/10523030/text

Probably it needs more testing.


I looked into it, and I think there might be a much simpler solution. After looking through a bunch of tables, I came up with this. It basically just checks if the value loaded from the table at $00E55E corresponds to one of the conveyor belt slopes and tells the game to use the regular slope interaction for fireballs if so.

Professional frame-by-frame time wizard. YouTube - Twitter - SMW Glitch List - SMW Randomizer
After looking through my code again, I realized how dumb I was and noticed that I can do the same with less code, just changing the index used in those tables.

Code
header : lorom
org $029FF8
	autoclean JSL fire_fix

freecode

fire_fix:
	TAY 
	CPY #$0C	;this is what causes the fireballs to warp
	BNE +		;wrong index = boom
	LDY #$01	;or weird bugs
	BRA ++
+	
	CPY #$FC	;this value too
	BNE ++		
	LDY #$07	;make them use the steep slope settings
++	
	LDA.w $9F99,y
	RTL


I guess both codes are ok, but I wonder if yours affects other things, since that routine is shared with normal sprites.


Originally posted by LX5
I guess both codes are ok, but I wonder if yours affects other things, since that routine is shared with normal sprites.

Well, the modification I made is specifically in the fireball's object detection code. If you directly modified the tables at $00E53D or $00E55E/$00E5C8, then it'd affect normal sprites and Mario.

A note on your code though, it doesn't seem to work quite right with the left-facing-down conveyors for whatever reason. The fireballs acts as if it hit a solid block rather than bouncing up it if you shoot up the conveyor, but everything else works fine so I have no idea what's up with that.

Professional frame-by-frame time wizard. YouTube - Twitter - SMW Glitch List - SMW Randomizer
I think it's because the conveyor slopes are missing a "slope interaction" for fireballs, I also play around with it with my own patch: link, and got the same result, it acts as if it hits a wall and disappears. Too bad that the all.log didn't comment about the slope interaction routine, (I think it's located near the routine that runs when Mario is on a solid layer 1/2 ground, there should be a routine that stores a value to $96 (player y position) in order for the platform and slopes to work).
Give thanks to RPG hacker for working on Asar.
There is a glitch on the magikoopa's magic and bullet bill that they disappear if you scroll the screen up far enough so they go past the bottom of the screen, and scroll back down, they don't respawn, even in horizontal levels. Normally if you scroll the screen downwards, they should respawn.

^EDIT: also spike tops too.

Just to let you know, in horizontal levels, the game loads sprites that are far above and below the screen on most sprites. And on vertical levels, far left and right side of the screen will be loaded.
Give thanks to RPG hacker for working on Asar.
I didn't find this in the list. Actual interaction glitch, not only graphical.



SMW TAS'er. My pages:
New TAS blog - old SMW Blog, Youtube - Twitter
Enemy sprites that uses horizontal proximity (such as splittin' chuck, whistlin' chuck, thwomp, falling spike (sprite #$B2)) reacts also if you are on one side of the screen and the sprite on the other:


I think this happens is because the proximity check range wraps the screen, in other words, the thwomp thinks the player is to the right of it and is close enough to make it attack.

Edit: I think it has to do with this:
Code
SubHorizPos:        A0 00         LDY.B #$00                
CODE_01AD32:        A5 D1         LDA $D1                   
CODE_01AD34:        38            SEC                       
CODE_01AD35:        F5 E4         SBC RAM_SpriteXLo,X       
CODE_01AD37:        85 0F         STA $0F                   
CODE_01AD39:        A5 D2         LDA $D2                   
CODE_01AD3B:        FD E0 14      SBC.W RAM_SpriteXHi,X     
CODE_01AD3E:        10 01         BPL Return01AD41          
CODE_01AD40:        C8            INY                       
Return01AD41:       60            RTS                       ; Return 

Give thanks to RPG hacker for working on Asar.
Originally posted by GreenHammerBro
Enemy sprites that uses horizontal proximity (such as splittin' chuck, whistlin' chuck, thwomp, falling spike (sprite #$B2)) reacts also if you are on one side of the screen and the sprite on the other:


Interesting. Does this glitch occur only on screen 00?


not screen boundary, as in the player's current screen. Also, there is another proximity check:
Code
CODE_02D4FA:        A0 00         LDY.B #$00                
CODE_02D4FC:        A5 94         LDA RAM_MarioXPos         
CODE_02D4FE:        38            SEC                       
CODE_02D4FF:        F5 E4         SBC RAM_SpriteXLo,X       
CODE_02D501:        85 0F         STA $0F                   
CODE_02D503:        A5 95         LDA RAM_MarioXPosHi       
CODE_02D505:        FD E0 14      SBC.W RAM_SpriteXHi,X     
CODE_02D508:        10 01         BPL Return02D50B          
CODE_02D50A:        C8            INY                       
Return02D50B:       60            RTS                       ; Return 


And the only difference is that it uses the player's next frame x position rather than current frame.
Give thanks to RPG hacker for working on Asar.
Sounds like this one:
"If a wall springboard is crossing the edge of the screen, its interaction will loop to the other side. In order for it to work, however, the base sphere of it has to be fully onscreen."
Of course you should fight fire with fire, you should fight everything with fire.

Oooh look at my userbar!


Sadistic Designer - testing Pit without tools.
and there is something even weirder: somethimes, the whistlin chuck that summons fish doesn't use the horizontal proximity check; waiting till the player stomps him, I don't know how it act like that. In forest of illusion, it works.

Edit: nevermind: you need to set sprite buoyancy.
Give thanks to RPG hacker for working on Asar.


Originally posted by Sadistic Designer
Sounds like this one:
"If a wall springboard is crossing the edge of the screen, its interaction will loop to the other side. In order for it to work, however, the base sphere of it has to be fully onscreen."

Actually, it's this one:

Originally posted by the list
The Mario proximity detection routine for sprites (e.g. for Thwomps, falling spikes, Yoshi eggs, etc) loop across the screen borders.



Anyway, I'll add the other mentioned glitches (and a bunch of new ones).

Professional frame-by-frame time wizard. YouTube - Twitter - SMW Glitch List - SMW Randomizer



I remember seeing a glitch in some pit hack playthroughs like Living on the Edge where they spinjump at certain intervals while moving very fast to stay at the same speed and not jump up. I have no clue how to do that, but I think it would be handy to have on this list. If someone does know the trick/s behind it, I would appreciate it/them.





Azunyan >>>>>>>>>>>>>> all other waifus on this site

Links to other places I am:
My site - My YouTube channel - MyAnimeList - My Twitter

PM me and I may put your userbar to the left!



Tag (idiocy) was not closed.
Originally posted by nambona890
I remember seeing a glitch in some pit hack playthroughs like Living on the Edge where they spinjump at certain intervals while moving very fast to stay at the same speed and not jump up. I have no clue how to do that, but I think it would be handy to have on this list. If someone does know the trick/s behind it, I would appreciate it/them.



This is listed:

If Mario is moving fast enough (x-speed of 64-80), then Mario will be unable to jump. Any faster and his jump height will also be significantly higher than usual.

SMW TAS'er. My pages:
New TAS blog - old SMW Blog, Youtube - Twitter