This is a 10 frames (0.17 second) improvement to the current game end glitch published movie.

Game objectives

  • Emulator used: lsnes rr2-β22b1
  • Aims for fastest time
  • Uses game-breaking glitches
  • Achieves credits early

Comments

Everything about the glitch that triggers the credits, done via item swapping a Chuck by collecting and licking a coin at the same time, is described in the submission text of the previous movie. Thus, I'll describe here just the improvement itself. Instead of eating the green shell right after spitting out the fireballs, I kicked it forwards by touching it while Yoshi is ascending. So, it's possible to spit out the fireballs much further before getting the green shell. This initially was saving 4 frames, but after a while it was possible to save 8.
Amaraticando, then, managed to save an extra frame, by spitting out the shell while Yoshi is turning right. That, however, was preventing us to get the credits, because the controller #1 register ($4219), which allows us to trigger credits with input, wasn't being executed. We investigated a lot what was causing it, and it turned out it was Mario's position. At frame 2510, $4219 is not executed if Mario's x position is 2470 or higher, in this situation. Therefore, we have to press X and left at the very end, before the game end input. The last inputs that trigger the credits were done by Masterjun.
Update: The berry, placed where we needed to be to get the green shell, was stopping Mario for a while. Berries freeze Mario's position a bit when Yoshi eats them with his mouth, but the rest of the game keeps moving (such as the fireballs). Avoiding it, however, seemed to be impossible, because we had to press < to not destroy the shell, and that makes Yoshi to turn around and eat it. The solution was to turn left before, and then turn right at the very moment we spit out the flames. While Yoshi is turning right, pressing < doesn't make him to turn left. This way, we could spit out the flames even further, since it's easier to catch them up without the berry disturbing us.
There's a frame rule that affect the fireballs: they can turn enemies into coins only in 1 frame out of 4. And this frame rule was horrible to us, because we would need to eat the coin at the same frame it turns into a coin, which means it is still moving with the shell's speed, which is too high. It was obligating us to dismount Yoshi only in the upper platform, but that, again, was preventing $4219 to be executed. The solution was to spit out the flames much below, and spit the shell at a very high position, so that it takes 4 extra frames to be burned. In this 4 frames we spit out Yoshi's tongue and dismount it in a proper position, and both Mario and Yoshi's tongue reach the coin at the same time.

Noxxa: Judging.
Noxxa: Replaced with a 1 frame improvement.
Noxxa: Accepting as an improvement to the published movie.
fsvgm777: Processing.


TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 15576
Location: 127.0.0.1
Spikestuff
They/Them
Editor, Publisher, Expert player (2642)
Joined: 10/12/2011
Posts: 6438
Location: The land down under.
Yea, okay, that happened.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. Something better for yourself and also others.
Amaraticando
It/Its
Editor, Player (159)
Joined: 1/10/2012
Posts: 673
Location: Brazil
This is better to watch in 1080p60 and full screen... Link to video
dnnzao
He/Him
Former player
Joined: 11/5/2010
Posts: 90
Location: Toronto, ON
Voting yes! Even though it's a little improvement, I think a improvement on a Game and Glitch category is necessary to be close to perfect, always.
sorry my bad english... - Finished projects: Super Demo World any% - SMW Hack - Dropped projecs: Super Demo World All Exits - SMW Hack Super Mario World All Exits
Joined: 11/15/2004
Posts: 804
Location: Canada
Made that look easy!
TASing or playing back a DOS game? Make sure your files match the archive at RGB Classic Games.
Editor, Expert player (2478)
Joined: 4/8/2005
Posts: 1573
Location: Gone for a year, just for varietyyyyyyyyy!!
How hard would it be to do this on a console? Is there maybe an alternative setup that requires less precision?
Joined: 12/29/2007
Posts: 489
Credits jump has been done on console, using pixel-perfect sprite positions to spell out code rather than mashing it through controller inputs. It's still very hard to do though. On mobile so can't provide a link right now unfortunately, but it shouldn't take long at all to look up a video & explanation.
Editor, Player (69)
Joined: 1/18/2008
Posts: 663
The previous version of this video did not verify. I can try this version though, give me a couple weeks to unpack and decompress from this convention.
true on twitch - lsnes windows builds 20230425 - the date this site is buried
Player (173)
Joined: 12/28/2007
Posts: 235
Location: Japan, Sapporo
Nice improvement! I like to see such a strategy which is easy to do but not so obvious to think up. Voted yes.
Retired because of that deletion event. Projects (WIP RIP): VIP3 all-exits "almost capeless yoshiless", VIP2 all-exits, TSRP2 "normal run"
GoombaHeart
He/Him
Joined: 7/11/2015
Posts: 131
Location: Winters
Aqfaq wrote:
How hard would it be to do this on a console? Is there maybe an alternative setup that requires less precision?
People have done game end glitches. Link to video
Shit tier TASer.
Joined: 1/13/2013
Posts: 8
Location: Tokyo, Japan
Amazed at very cool improvement;-) I'm impressed with the elaborate works for saving frames. Yes vote for your challenge!
Skilled player (1672)
Joined: 7/1/2013
Posts: 448
Looking forward to next year's submission as well! :)
Joined: 3/1/2009
Posts: 64
Remember when this game included gameplay? Yeah, me neither. Obvious yes vote :)
Post subject: Movie improved
Editor, Skilled player (1344)
Joined: 12/28/2013
Posts: 396
Location: Rio de Janeiro, Brasil
A slightly different strategy, which will be described in the submission text, allowed us to save another frame. I've uploaded the movie to the userfiles, here is the link: http://tasvideos.org/userfiles/info/24824444132533782 Mothrayas, could you replace the movie by the new one, please?
My YouTube channel: https://www.youtube.com/channel/UCVoUfT49xN9TU-gDMHv57sw Projects: SMW 96 exit. SDW any%, with Amaraticando. SMA2 SMW small only Kaizo Mario World 3
Noxxa
They/Them
Moderator, Expert player (4124)
Joined: 8/14/2009
Posts: 4090
Location: The Netherlands
Done.
http://www.youtube.com/Noxxa <dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects. <Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits <adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
Player (122)
Joined: 1/22/2012
Posts: 45
Awesome improvement, especially from such a short TAS! Obvious yes.
Joined: 5/8/2010
Posts: 177
Location: Entropy
I didn't think SMW could get any broken, I was wrong.
Experienced player (588)
Joined: 2/5/2011
Posts: 1417
Location: France
inb4 ace at title screen Yes vote! :P
Current: Rayman 3 maybe? idk xD Paused: N64 Rayman 2 (with Funnyhair) GBA SMA 4 : E Reader (With TehSeven) TASVideos is like a quicksand, you get in, but you cannot quit the sand
Joined: 9/1/2014
Posts: 58
The last time I checked on this game being glitched it was like 2 minutes long. Didn't realise it gt refined so well. The actual video doesn't look too strange compared to the first glitched ending so it makes it look like very little set-up is actually needed to glitch the game now. Which is strange.
Enjoys speedruns but hasn't actually tried making any yet.
Post subject: Movie published
TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 15576
Location: 127.0.0.1
This movie has been published. The posts before this message apply to the submission, and posts after this message apply to the published movie. ---- [2926] SNES Super Mario World "game end glitch" by BrunoVisnadi, Amaraticando & Masterjun in 00:41.81
Post subject: Console Playback
Ownasaurus
She/Her
Editor
Joined: 3/15/2016
Posts: 2
Hello everyone, A few months ago, DwangoAC and micro500 were able to play this run back on actual hardware using the TASLink replay device. However, the run had never worked for me on my SNES, SMW cart, and TASLink replay device. The only notable difference is that my cart is a 1.1 whereas they were both using 1.0 carts. Every other ACE/TAS I have attempted with SMW works great though. Ilari suggested that SRAM[0x101] == $700101 == 0xFF in order for the payload to work properly. This is indeded the case in lsnes. However, today I installed the SMW "jailbreak" to view my memory and noted that the memory address read 0x00 for me rather than 0xFF. After manually modifying $700101 to read 0xFF, this game end glitch worked flawlessly on my hardware. My question is: is this due to my having a 1.1 cart, or did my cart's SRAM get corrupted somehow? Thanks, Owna
Post subject: Re: Console Playback
Masterjun
He/Him
Site Developer, Skilled player (1987)
Joined: 10/12/2010
Posts: 1185
Location: Germany
Ownasaurus wrote:
My question is: is this due to my having a 1.1 cart, or did my cart's SRAM get corrupted somehow?
Neither of those. This is simply due to your SRAM address $0101 having a value of 0x00 instead of the required 0xFF of this run. In this run, that SRAM address is never touched so it stays whatever it was.
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)
Post subject: Re: Console Playback
Ownasaurus
She/Her
Editor
Joined: 3/15/2016
Posts: 2
Masterjun wrote:
Ownasaurus wrote:
My question is: is this due to my having a 1.1 cart, or did my cart's SRAM get corrupted somehow?
Neither of those. This is simply due to your SRAM address $0101 having a value of 0x00 instead of the required 0xFF of this run. In this run, that SRAM address is never touched so it stays whatever it was.
Thanks for your reply, Masterjun. It seems that if the user has ever used file B, that address will not contain 0xFF. So I wonder -- do we consider this run console verified if it requires a particular initial SRAM state?