Language…
11 users online:  AmperSam, Dan2point5, fsvgm777, Gasterus155, JPhanto, kirsvantas, nonamelol1, reevebarusadar8, signature_steve, Sokobansolver, tOaO - Guests: 251 - Bots: 323
Users: 64,795 (2,377 active)
Latest user: mathew

The SMW Glitch List

I found another oversight: if the game activates lock animation and sprites flag (7E:009D, happens if Mario is growing up from a mushroom, flower, feather, L/R scrolling etc), shelless koopas ignore the freezing effect. This can be exploited to make red and blue koopas fall off edges of platforms by timing it so that the furthest pixel on the edge they turn around (they actually "gap dash", turning around in MIDAIR and lands back to the platform before falling).

Another result is that if they are on a conveyor belt while $7E009D is active, they get "conveyor'ed" (probably because that they also interact with objects while frozen).
Give thanks to RPG hacker for working on Asar.


The first one you mentioned is already in the list, as this:
Quote
Freezing the game via a screen scroll, death, damage, or a powerup on the frame that a red or blue Koopa touches the corner of a block will cause it to fall downward past that corner.


Though I didn't realize a similar effect occurs with the conveyor belts, so that's added in now. (might be other sprites that do it too with them, I haven't tested)

Professional frame-by-frame time wizard. YouTube - Twitter - SMW Glitch List - SMW Randomizer
I found this in Iggy's castle. I'm not really sure if it's a glitch though.


Formerly known as nick 139
My YouTube channel
Not really a glitch, as the smasher has a habit of striking at the end of the screen and will follow the same pattern until you go into another room.
Windowless ride, feeling alive
Are you alive or just breathing?
I figure out why the smasher doesn't but you when alternating and that the screen doesn't scroll up if you reach higher platform, because of how $7E:0072 works, it you touch a platform on the first frame after falling on it still assume you are still in midair #$24 while on the platform for a frame before being set to #$00.

The smasher only damages the player if the player is on the ground, so that it doesn't "crush" the player when "not" between two surfaces on contact (like how Mario gets crushed between two layers 1 & 2, excluding death), that way it simulates the getting crush between surfaces.

I found another bug: any layer 3 (objects besides the status bar/HUD, layer 3 background of LM) that doesn't scroll-follow the screen like fishes, smashers and mist will follow the screen if L/R scrolled, possibly because they freeze (stop storing layer 3 position based on the position of layer 1) if $7E009D is set.

I notice that Rexes have a strange hitbox "stomp detection", if you are falling at a certain y speed $7E007D, and touch it on ANY side, the game will think Mario stomps it on top (the game didn't check for side contact), this happens if using gravity higher than #$06 for editing the player's Gravitational acceleration. Possibly because of the "Rex on a slope" glitch.
Give thanks to RPG hacker for working on Asar.
More info about exploiting the yoshi tongue drop glitch:
https://m.youtube.com/watch?v=AiHD5KHzHeE
Give thanks to RPG hacker for working on Asar.
I found an oversight: some cluster sprites like the boo ceiling (from the donut plains ghost house (north version)) and the boo ring always assume super/cape/fire Mario has a 16x32 hitbox. This causes big crouching Mario to get hit if the cluster sprites are in a block space above him. I notice this when developing the hp bar.

Edit: it works fine (without glitches) with small Mario, the hitbox detection only check the player's status rather than both the crouch flag and the powerup.
Give thanks to RPG hacker for working on Asar.
I found some glitchy stuff about extended sprites:

>> Killing them with star, by putting a star in item box and using in levels that you normaly couldn't:
($7E:170B value)Extended sprite -> which graphical glitch on the first frame after killed

(02)Reznor fireball -> flame goes up by 4 pixels, and left by 2,5 pixels if comes from the left or 5,5 pixels if comes from the right (I guess not actualy a glitch, because this new position is the puff of smoke that ever extended sprite becomes when killed;
(03)flame left by Hopping Flame -> same as Reznor fireball, but they're static;
(04)hammer -> nothing;
(06)bone from Dry Bones -> same as Reznor fireball;
(0B)piranha plant fireball -> hammer, keeping the orientation;
(0D)baseball -> glitched mole-ish, that depends on the orientation.

Note: the other extended sprites are not killable.

>> When you screen scroll the same frame Reznor spits fireball, it will multiple spawn


>> Wiggler's flower y-position is glitchy, as if it were multiplied by a huge number

Glitch hunter, RAM eater, pseudo-TASer.
Scripts, documentations, and misc: SMW stuff on Github, YI stuff on Github, The Flintstones stuff on Github
Stuff and me: YouTube, Twitter
EDIT: a lot of people have found this before, but never understand well

Ok, I found a beautiful thing. First, look at this gif:



Basically, the cape interaction acts really weird when layer 2 or 3 moves.
I found this by accident in this room, when heading to Morton to check another completely different thing (SMW basic day), almost as this gif above. I killed both dry bones and I was "wut........" (wasn't using the script). Then I found that the cape interaction (that yellow box) "virtually" moves as the layer 2/3 moves, BUT it only interacts (kill sprite or hit block) if the game is frozen. The "close-range" capespin still works normally.

I made some gifs that you can directly see in this album, but I'll explain each of them now. Please see each gif carefully:
-If you take a flower when capespinning, the interaction may go slow, or go really fast. Note the increase of the Interaction x value, in yellow on the left;
-The same occurs when you die capespinning (by time limit and maybe insta-kill block);
-You can even hit (multiple hit, if slow) blocks away from Mario, as here, I got 6 feathers from one block;
-When layer 2 moves vertically, happens the same, you may get slow or fast (cute trick). Note the difference in the Interaction y value increase between both cases;
-Here you can see exactly how it virtually moves, opposite to the layer 2 movement;
-If Mario stands on the moving layer, clearly you see how the game is doing this, by "adapting" the cape interaction to a fixed position;
-The same happens if there's layer 3, but here is even more weird, because the virtual cape interaction is looping exactly between the middle of the 2nd screen and the middle of the 3rd screen (Layer 3 is the running water), so Mario can be in the end of the level capespinning, but the virtual cape will always be there;
-As layer 2, with layer 3 you can kill sprites away from you.

Enough gifs, let's head to the science behind it.
For some bizarre reason, the value of the cape interaction in levels that there's layer 2 or 3 moving is discounted by the layer relative position. In other words, the addresses $7E:0026 and $7E:0028 (Layer 2 or 3 relative x and y position, respectively) are the key. So, as you can see in the gifs, the virtual cape moves exactly as the 2nd layer moves, but in the opposite direction. The reason it's the opposite way I guess is because the 2nd layer coordinates are inverted. You can clearly see that by watching the 2nd layer x speed ($7E:144A), that is negative when going to the right.
Now you may ask why sometimes the interaction box goes slow and sometimes goes fast when the game is frozen. The cape interaction takes the 2nd layer relative position as a speed (not the 2nd layer speed), as you can see in the image (3 consecutive frames on the right):


So in Morton's pre-boss room, for example, if you want the slow effect, you should wait until the layer 2 is on the right (the value -1 on the image is the extreme right), and vice-versa.
Also, you can see in "normal levels" (like YI2) that there's a 2nd layer relative position value (not zero), BUT there's no 2nd layer speed. So my final theory is: the cape interaction directly uses the 2nd layer relative position ONLY WHEN there's 2nd layer speed.

EDIT: just for curiosity, the Layer 3 relative position is (0, 0) in Mario's position.

Conclusion: did someone purposely code this?
EDIT: Kaizoman (Thomas) checked the code, "they completely stop processing Mario when the game is frozen, which includes the code that figures out where capespin goes, but the code that adds layer 2's position to the capespin's for interaction runs separately so it keeps getting added".

Anyway, it's now a new thing to use on kaizo/puzzle hacks 8>
(and maaaybe the description of the addresses in the RAM Map could be edited)
Glitch hunter, RAM eater, pseudo-TASer.
Scripts, documentations, and misc: SMW stuff on Github, YI stuff on Github, The Flintstones stuff on Github
Stuff and me: YouTube, Twitter
Taking up the top row in the Iggy/Larry Platform Editor can lead to strange results.
Quote
When climbing upward on a moving rope mechanism, Mario will not interact with the tops of blocks. This can be used to enter solid blocks when the mechanism moving downward or falling.


This also happens if you have a layer 2 level that follows the screen, that if the player scrolls it upwards, and the blocks "chases" him upwards fast enough to try to "push Mario upwards" with the blocks while the player's y speed is up, will also clip through blocks. The game thinks that the player is jumping upwards through the bottom of the ledge.

This is because the top of the blocks that are solid don't run if the player is going upwards ($7E007D a negative value), the reason why Nintendo did this is because they (re)use the 1-way up ledges code (like clouds, rope, normal ledges that work in any tile set (just changes gfx) and etc) as a "floor" and so that the player can jump up from underneath it (only applies to "top offset") rather than being blocked from going upwards. They recycle this "floor" code on non-ledges to save space. This is probably due to how the "player blocked status" ($7E0077) works.
Give thanks to RPG hacker for working on Asar.
If you eat cancel a sprite in a way that Yoshi's tongue only touches it for 1 frame and then Yoshi's get hurt (so that the sprite isn't warped to the center of the tongue), it won't get the proprieties of a canceled sprite, but it will still be in Yoshi's mouth, which means Yoshi can't be hurt by it.
While you don't spit out Yoshi's tongue, if you despawn this sprite and another sprite is spawned in the same slot, then this new sprite can't hurt Yoshi.
If the game freeze ($7E009D set) the same frame while the beach koopa gets up after entering its shell (after it jumps in, a shell with koopa eyes in its "hole"), it will show a glitch frame:



It goes in a sequence like this:

the koopa is walking, when it "touches" the shell, it jumps in, the koopa "disappears into the shell", now its a shell that has "koopa eyes" but is not up yet (looks like an ambonded shell, but with eyes), the shell shakes, and then it gets up as a normal walking koopa with a shell.

It glitches the frame if the freeze is performed the time between "shell with koopa's eyes" and "normal walking koopa with a shell"

The "easiest" way to do this is by waiting till the koopa jumps into its shell and press L/R to scroll the screen and freeze time. If performed perfectlly, its first frame will glitch until the game stops freezing.

Trivia: happens on sma2 also.
Give thanks to RPG hacker for working on Asar.
Don't forget to link snes9x-rr. Since that can run scripts.
Give thanks to RPG hacker for working on Asar.
Found something cool about Sumo Brother's flames (cluster sprites):



When you screenscroll on the exact frame the 1st (middle) flame appears, the game creates another 2 or 3 extra flames. Scrolling to the right worked, to left was unsuccesseful.
The 1st extra flame appears almost in the middle of the normal flames (4 pixels to the right from the middle flame);
the 2nd extra flame appears away from the action (193 pixels to the right from the middle flame);
the 3rd extra flame occurs not all the time, but when it does it's overlaped with the 2nd extra flame.

As nathanisbored suggested, it could be (ab)used with that glitch about any sprite in slot 0 warps to the lowest cluster sprite position (like this video) to make an obscure puzzle. I tested and it always works, because any extra flame spawns on lower slots.

Also, you can get extra flames by taking damage from the 2nd or 4th flame (counting from left to right), but seems random, sometimes you get only the 1st extra flame, as you can see on the next gif, and sometimes you get the 2nd and even the 3rd. But this method doesn't work all the time, maybe due the oscillation or the real/effective frames. [Amaraticando (RodAmaral) found this]



You can see the method above with script here.

I tested the same methods with other cluster sprites, but it seems a flame special thing. The only other thing I found is a "pause buffering" in bonus room when the 1ups (cluster sprites) are coming. When you pause, and unpause on real frames above f0 (seems like), you force a next 1up to come, so you can get 2 1ups really close to each other, ou unpause on low real frames, so you delay the spawning. But you can't "create" extra 1ups, not even frame perfectly.
Glitch hunter, RAM eater, pseudo-TASer.
Scripts, documentations, and misc: SMW stuff on Github, YI stuff on Github, The Flintstones stuff on Github
Stuff and me: YouTube, Twitter
Originally posted by Thomas
If you item swap a sprite that uses extra bits (e.g. the goal tape) when Yoshi is in a lower slot than it, the sprite's extra bits will be modified.

Just for the record, I made a video about it. I hope we find more uses for it #w{:>}
Glitch hunter, RAM eater, pseudo-TASer.
Scripts, documentations, and misc: SMW stuff on Github, YI stuff on Github, The Flintstones stuff on Github
Stuff and me: YouTube, Twitter
Originally posted by Master Valads
EDIT: a lot of people have found this before, but never understand well

Ok, I found a beautiful thing. First, look at this gif:



Basically, the cape interaction acts really weird when layer 2 or 3 moves.
I found this by accident in this room, when heading to Morton to check another completely different thing (SMW basic day), almost as this gif above. I killed both dry bones and I was "wut........" (wasn't using the script). Then I found that the cape interaction (that yellow box) "virtually" moves as the layer 2/3 moves, BUT it only interacts (kill sprite or hit block) if the game is frozen. The "close-range" capespin still works normally.

I made some gifs that you can directly see in this album, but I'll explain each of them now. Please see each gif carefully:
-If you take a flower when capespinning, the interaction may go slow, or go really fast. Note the increase of the Interaction x value, in yellow on the left;
-The same occurs when you die capespinning (by time limit and maybe insta-kill block);
-You can even hit (multiple hit, if slow) blocks away from Mario, as here, I got 6 feathers from one block;
-When layer 2 moves vertically, happens the same, you may get slow or fast (cute trick). Note the difference in the Interaction y value increase between both cases;
-Here you can see exactly how it virtually moves, opposite to the layer 2 movement;
-If Mario stands on the moving layer, clearly you see how the game is doing this, by "adapting" the cape interaction to a fixed position;
-The same happens if there's layer 3, but here is even more weird, because the virtual cape interaction is looping exactly between the middle of the 2nd screen and the middle of the 3rd screen (Layer 3 is the running water), so Mario can be in the end of the level capespinning, but the virtual cape will always be there;
-As layer 2, with layer 3 you can kill sprites away from you.

Enough gifs, let's head to the science behind it.
For some bizarre reason, the value of the cape interaction in levels that there's layer 2 or 3 moving is discounted by the layer relative position. In other words, the addresses $7E:0026 and $7E:0028 (Layer 2 or 3 relative x and y position, respectively) are the key. So, as you can see in the gifs, the virtual cape moves exactly as the 2nd layer moves, but in the opposite direction. The reason it's the opposite way I guess is because the 2nd layer coordinates are inverted. You can clearly see that by watching the 2nd layer x speed ($7E:144A), that is negative when going to the right.
Now you may ask why sometimes the interaction box goes slow and sometimes goes fast when the game is frozen. The cape interaction takes the 2nd layer relative position as a speed (not the 2nd layer speed), as you can see in the image (3 consecutive frames on the right):


So in Morton's pre-boss room, for example, if you want the slow effect, you should wait until the layer 2 is on the right (the value -1 on the image is the extreme right), and vice-versa.
Also, you can see in "normal levels" (like YI2) that there's a 2nd layer relative position value (not zero), BUT there's no 2nd layer speed. So my final theory is: the cape interaction directly uses the 2nd layer relative position ONLY WHEN there's 2nd layer speed.

EDIT: just for curiosity, the Layer 3 relative position is (0, 0) in Mario's position.

Conclusion: did someone purposely code this?
EDIT: Kaizoman (Thomas) checked the code, "they completely stop processing Mario when the game is frozen, which includes the code that figures out where capespin goes, but the code that adds layer 2's position to the capespin's for interaction runs separately so it keeps getting added".

Anyway, it's now a new thing to use on kaizo/puzzle hacks 8>
(and maaaybe the description of the addresses in the RAM Map could be edited)



Code
CODE_029516:        AD E9 13      LDA.W $13E9               
CODE_029519:        18            CLC                       
CODE_02951A:        65 26         ADC $26                   
CODE_02951C:        8D E9 13      STA.W $13E9               


Code
CODE_029527:        AD EB 13      LDA.W $13EB               
CODE_02952A:        18            CLC                       
CODE_02952B:        65 28         ADC $28                   
CODE_02952D:        8D EB 13      STA.W $13EB


wtf?!? Is this deliberate? Ram address $7E13E9 and $7E13EB are the cape's coordinates in the level.
Give thanks to RPG hacker for working on Asar.


Originally posted by GreenHammerBro
Code
CODE_029516:        AD E9 13      LDA.W $13E9               
CODE_029519:        18            CLC                       
CODE_02951A:        65 26         ADC $26                   
CODE_02951C:        8D E9 13      STA.W $13E9               


Code
CODE_029527:        AD EB 13      LDA.W $13EB               
CODE_02952A:        18            CLC                       
CODE_02952B:        65 28         ADC $28                   
CODE_02952D:        8D EB 13      STA.W $13EB


wtf?!? Is this deliberate? Ram address $7E13E9 and $7E13EB are the cape's coordinates in the level.

Uh, yeah. It's how they process interaction between the cape and Layer 2 correctly. Otherwise it'd interact with where Layer 2 *would* be, if it weren't for the scrolling.

Normally the position then gets reset back to Mario at the start of the next frame, before it processes interaction with Layer 1 again. However, since the game is frozen, Mario doesn't get processed anymore, but his cape's hitbox still does (same reason freezing the game when you hit an item box causes a bunch of items to pop out). So the position just keeps getting added without being reset, causing it to fly off like that.

Professional frame-by-frame time wizard. YouTube - Twitter - SMW Glitch List - SMW Randomizer
Wooh, I fixed it. Also, please tell me why using "RTS" instead of "JML $02953B" crashes the game if the player tries to perform this glitch.

Edit: Now I know why, you cannot execute an RTS at a certain bank(s), the bank byte got changed, but the game doesn't know it. Thus the game get "lost" on what address its in. I have no choice but to jump into an RTS in bank 02 to make it work.
Give thanks to RPG hacker for working on Asar.
Found a glitch with the star timer:

The hexadecimal number in the HUD's (heads-up display) item box counter represents the freezable frame counter ($7E0014), while the counter left of the coin counter represent the star timer ($7E1490).

Whats supposed to happen is when the game is frozen, the star timer should also freeze. But because it only rely on the freezable frame counter being divisible by (or multiple of) 4 and not the locked flag directly, it causes it to "decrement faster" rather than freezing. Take a look:

Code
CODE_00E2DA:        A5 14         LDA RAM_FrameCounterB     ;\
CODE_00E2DC:        29 03         AND.B #$03                ;| quite often, don't decrement the star counter
CODE_00E2DE:        D0 03         BNE CODE_00E2E3           ;/
CODE_00E2E0:        CE 90 14      DEC.W $1490               ; Decrease star timer 


The developers believed that using $7E0014 guaranteed that the timers that uses this address as a "delayer" will always work, if that address is frozen, then the timers are frozen. Wrong, not always, when the locked flag is set, the frame counter is frozen, but if its frozen at a value divisible by 4, the DEC.W $1490 will keep executing while the locked flag is set. Here is the bugfix (my first time making a hybrid sa-1 patch).

Also, not to mention, since star power is considered a powerup, and that mario dies loses it, he keeps flashing colors even during the death animation. The patch also fixes that.
Give thanks to RPG hacker for working on Asar.