Submission Text Full Submission Page
It's this little pink thing again.

Game objectives

  • Emulator used: FCEUX 2.2.3

Comments

It's an one frame improvement over the published run. The slope clip is improved. Everything else is unchanged. I (TASeditor) tried to improve other things as well by delaying and interupting certaing actions, but it didn't work out due to lag sadly. Here's is an userfile with these tests in second room, just in case.
For non glitched graphics change inputs from TLR to TDLR on last frame.
Now it is 9 frames faster than the current published run, thanks to better lag reduction due to interrupting movement.

First room

Don't interrupting by extending jump height at frame 603, 2 lag frames and 134 subpixel inproved at frame 888 when swallowing. At frame 1069 being 6:224 pixels ahead, due to delaying the running start and interupting movement in mid-air. 12:199 pixels ahead at frame 1229. 6 frames faster in this room.

Second room

Interrupting before sliding in order to go over the hill efficiently, this section is very laggy. ~2 pixels needed to be sacrificied at frame 1584 to not bumb into the Waddle Doo. At frame 1620 being 21:8 pixels ahead, thanks to better lag reduction on the hill. 3 frames faster in this room.

Last room

Not improved, due to the lag behaviour of the game.

Masterjun: Judg... no wait I'm an author dang it!

Nach: I'm not an author, judging.

TASeditor: Please update the submission with this file!

Nach: Replaced movie file.

Nach: It's now larger than a 1 frame improvement, and a nice one at that. Accepting.
Spikestuff: Publishing.

TASVideoAgent
They/Them
Experienced Forum User, Moderator
Joined: 8/3/2004
Posts: 12391
Location: 127.0.0.1
Fog
Experienced Forum User, Experienced player (864)
Joined: 4/5/2014
Posts: 459
Funny TAS of 2015
1, 2, 3, 4! I declare a frame war!
Experienced Forum User, Experienced player (509)
Joined: 11/18/2011
Posts: 241
Location: Morocco
First Super Metroid, then Kirby?! And not only one TASer who's doing that, a lot of TASers for the same run?! And for only a time that doesn't surpass 5 frames?! What's happening in the world of TAS? Oh! Only one author who's doing that, ah I know now. Ok I vote yes. (I said that blah blah in order to vote yes).
I still learn more about English. https://www.youtube.com/user/McBobX100
I wrote:
Working is the best way to achieve goals in speedruning. Hardworking is a pain.
Experienced Forum User, Experienced player, Site Admin (974)
Joined: 4/17/2010
Posts: 10601
Location: RU
NES TAS of 2011
Fog wrote:
1, 2, 3, 4! I declare a frame war!
No one has a chance dude. Only Aglar can improve this now.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting. If TASing is meta-play, TASVideos Movie Rules are meta-meta-play!
Editor, Experienced Forum User, Publisher, Skilled player (1228)
Joined: 10/12/2011
Posts: 6018
Location: The land down under.
PSX TASer of 2016
You know, a few days ago I was planning to update the encodes to the other game end glitch TASes for a reason... Instead I have to look at this lovely beast and hopefully publish it. Since no one else is providing one. Providing an Encode. Link to video (We don't need no stinking clean credits til publication. :V)
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. These colours are pretty neato, and also these.
Editor, Experienced Forum User, Skilled player (1341)
Joined: 3/31/2010
Posts: 2042
TAS of 2017First edition TAS of 2017PSX TAS of 2017
1 ★ FRAME (Yes vote)
Experienced Forum User, Experienced player (656)
Joined: 2/5/2011
Posts: 1417
Location: France
TAS of 2017First edition TAS of 2017PSX TAS of 2017Rookie of 2013
The frame war is back! Hide yourselves, guys! YES VOTE OTHERWISE
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
Editor, Experienced Forum User, Skilled player (1374)
Joined: 7/9/2010
Posts: 1312
Glitchy TAS of 2015NES TASer of 2014Speedy TAS of 2014NES TAS of 2013
Frame war is unrealistic. This is the best I could do:User movie #36213916995294957 Saves 192 subpx and 3 lagframes at frame 1231.
Favorite animal: STOCK Gt(ROSA)26Sortm1.1(rtTA,EGFP)Nagy Grm7Tg(SMN2)89Ahmb Smn1tm1Msd Tg(SMN2*delta7)4299Ahmb Tg(tetO-SMN2,-luc)#aAhmb/J YouTube Twitch Twitter
Alyosha
He/Him
Editor, Experienced Forum User, Expert player (2820)
Joined: 11/30/2014
Posts: 2467
Location: US
NES TASer of 2015
I tried to get this run to sync in BizHawk and it made it all the way up to the glitch itself. But after that it crashed. It crashed at a kill instruction ($72). Execution here depends critically on values in PPU registers/memory and undocumented opcodes. FCEUX seems to be having some serious trouble here. Here are the last few instructions where things depart seriously from NESHawk:
c64248952    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3C78:A8        TAY
c64248954    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3C7A:10 00     BPL $3C7C
c64248957    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3C8C:87        UNDEFINED
c64248960    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3C9E:23        UNDEFINED
c64248963    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3CA0:A8        TAY
c64248970    A:7E X:FF Y:62 S:F9 P:nvUBdIzc       $0029:48        PHA
There are 2 TAY's here that aren't moving A to Y, a jump to $0029 that I can't tell where it's coming from, and execution jumping from 3C8C to 3C9E on the 87 instruciton (which is just supposed to AND X and A.) I read in the original publication of this branch by MUGG that the glitch itself is console verified, but on a different level. Is the glitch console verified on this level?
Fog
Experienced Forum User, Experienced player (864)
Joined: 4/5/2014
Posts: 459
Funny TAS of 2015
Alyosha wrote:
I tried to get this run to sync in BizHawk and it made it all the way up to the glitch itself. But after that it crashed. It crashed at a kill instruction ($72). Execution here depends critically on values in PPU registers/memory and undocumented opcodes. FCEUX seems to be having some serious trouble here. Here are the last few instructions where things depart seriously from NESHawk:
c64248952    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3C78:A8        TAY
c64248954    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3C7A:10 00     BPL $3C7C
c64248957    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3C8C:87        UNDEFINED
c64248960    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3C9E:23        UNDEFINED
c64248963    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3CA0:A8        TAY
c64248970    A:7E X:FF Y:62 S:F9 P:nvUBdIzc       $0029:48        PHA
There are 2 TAY's here that aren't moving A to Y, a jump to $0029 that I can't tell where it's coming from, and execution jumping from 3C8C to 3C9E on the 87 instruciton (which is just supposed to AND X and A.) I read in the original publication of this branch by MUGG that the glitch itself is console verified, but on a different level. Is the glitch console verified on this level?
The current any% WR: https://www.speedrun.com/run/pydwx4vm
Experienced Forum User, Experienced player, Site Admin (974)
Joined: 4/17/2010
Posts: 10601
Location: RU
NES TAS of 2011
Alyosha, there were posts by true back when some of the recent glitched Kirbys was published, look those up.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting. If TASing is meta-play, TASVideos Movie Rules are meta-meta-play!
Alyosha
He/Him
Editor, Experienced Forum User, Expert player (2820)
Joined: 11/30/2014
Posts: 2467
Location: US
NES TASer of 2015
feos wrote:
Alyosha, there were posts by true back when some of the recent glitched Kirbys was published, look those up.
Yeah I'm getting the same thing he describes, frozen grey screen with different sprites and a constant tone.
Fog wrote:
The current any% WR: https://www.speedrun.com/run/pydwx4vm
Hmmm that looks quite a bit different then the exeution in the TAS, I will try to reproduce it in BizHawk. EDIT: Here is a test run in NESHawk that executes the credits. I didn't in any way try to optimize it all I did was recreate what I saw in the video Fog posted. http://tasvideos.org/userfiles/info/36216983802179878 I am pretty confident in saying that FCEUX is not emulating this correctly. I looked through the 6502 source code for it and undocumented ops are not well emulated to say the least. This combined with True's console tests before and I would say that this run should really be done on BizHawk.
Post subject: BizHawk 2157/35.89 sec
Editor, Experienced Forum User, Experienced player (556)
Joined: 11/8/2010
Posts: 3953
Exotic platforms TASer of 2014NES TAS of 2013
Using Alyosha's test movie, I managed to redo the glitch section on BizHawk with zero time loss! 2157 is still a reality! User movie #36222432332944819 Link to video The only hurdle for console verification now is the hard reset at the beginning. Otherwise, this file is ready to replace this submission.
Post subject: Re: BizHawk 2157/35.89 sec
Editor, Experienced Forum User, Publisher, Skilled player (1228)
Joined: 10/12/2011
Posts: 6018
Location: The land down under.
PSX TASer of 2016
CoolKirby wrote:
User movie #36222432332944819
Wow that input near the end... Here's a cleanup: User movie #36222579598264480 I wish I could get rid of Player 2's input. However The input (both mine and Cool's) falls into a problem. The credits are glitched and no form of correcting it to have clean credits is currently possible. I don't recommend updating to either of the updated for Hawk input at the current time.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. These colours are pretty neato, and also these.
Experienced Forum User, Experienced player, Site Admin (974)
Joined: 4/17/2010
Posts: 10601
Location: RU
NES TAS of 2011
you guys are beyond insane
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting. If TASing is meta-play, TASVideos Movie Rules are meta-meta-play!
Masterjun
He/Him
Experienced Forum User, Site Developer, Skilled player (1822)
Joined: 10/12/2010
Posts: 1153
Location: Germany
Exotic platforms TAS of 2020Speedy TAS of 2018PC TAS of 2018Glitchy TAS of 2015TASer of 2014SNES TASer of 2014TAS of 2014SNES TAS of 2014Funny TAS of 2014Glitchy TAS of 2014TASer of 2013SNES TASer of 2013NES TAS of 2013SNES TAS of 2012Funny TAS of 2012
Alyosha wrote:
c64248952    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3C78:A8        TAY
c64248954    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3C7A:10 00     BPL $3C7C
c64248957    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3C8C:87        UNDEFINED
c64248960    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3C9E:23        UNDEFINED
c64248963    A:7E X:FF Y:62 S:FC P:nvUBdizc    $3CA0:A8        TAY
c64248970    A:7E X:FF Y:62 S:F9 P:nvUBdIzc       $0029:48        PHA
There are 2 TAY's here that aren't moving A to Y, a jump to $0029 that I can't tell where it's coming from, and execution jumping from 3C8C to 3C9E on the 87 instruciton (which is just supposed to AND X and A.)
This seems like the usual case of not logging what actually happens. This happens a lot with stuff I do and emulators I use so I'm kind of used to it really. For example, take a look at that first TAY. No matter how you turn it, it should be a 1-byte instruction. However the next instruction is 2 bytes further, clearly indicating that the instructions executed and the instructions logged are different. The location being executed seems to be the huge chunk of mirrors of the 8 bytes PPU registers. And reading PPU registers not meant to be read results in open bus behavior, which would explain the strange logging (and execution, for that matter).
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)
Alyosha
He/Him
Editor, Experienced Forum User, Expert player (2820)
Joined: 11/30/2014
Posts: 2467
Location: US
NES TASer of 2015
http://tasvideos.org/userfiles/info/36229935354105129 Here's a version that is only 2 frames too long but has correct credits and only 1 player input. maybe it's possible to get those 2 frames back with enough guess and check.
Masterjun wrote:
This seems like the usual case of not logging what actually happens. ... The location being executed seems to be the huge chunk of mirrors of the 8 bytes PPU registers. And reading PPU registers not meant to be read results in open bus behavior, which would explain the strange logging (and execution, for that matter).
A bug in the logging makes sense, but also makes it very hard to tell what's going wrong. There are other spots where only one instruction is read from PPU registers and those spots differ as well I noticed, so there are too many discrepencies to sort out unfortunately. I think console testing is required.
Editor, Experienced Forum User, Publisher, Skilled player (1228)
Joined: 10/12/2011
Posts: 6018
Location: The land down under.
PSX TASer of 2016
Alyosha wrote:
http://tasvideos.org/userfiles/info/36229935354105129
This crashes on TAStudio however runs fine as a normal bk2. What. Update: And literally as soon as I posted that it ran fine on TAStudio. COMMON!
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. These colours are pretty neato, and also these.
Fog
Experienced Forum User, Experienced player (864)
Joined: 4/5/2014
Posts: 459
Funny TAS of 2015
Spikestuff wrote:
Update: And literally as soon as I posted that it ran fine on TAStudio. COMMON!
Disappearing errors are definitely quite common, thanks for pointing that out!
Alyosha
He/Him
Editor, Experienced Forum User, Expert player (2820)
Joined: 11/30/2014
Posts: 2467
Location: US
NES TASer of 2015
I notice sometimes I get differences in TAStudio as well, but they always seem to go away and I can't recreate them with any consistency. One frame away now: http://tasvideos.org/userfiles/info/36235074406613720
Editor, Experienced Forum User, Experienced player (556)
Joined: 11/8/2010
Posts: 3953
Exotic platforms TASer of 2014NES TAS of 2013
I suggest adding Alyosha as a co-author if it's okay with him. Very nice and clean latest movie Alyosha. I couldn't improve it in my tests, I'll try again tomorrow.
Editor, Experienced Forum User, Skilled player (1374)
Joined: 7/9/2010
Posts: 1312
Glitchy TAS of 2015NES TASer of 2014Speedy TAS of 2014NES TAS of 2013
Masterjun works on removing the last button presses. It's dependend from PPU cycle count. And I will try to improve other rooms by testing more interupts, might code a semi-automatic bot for, since it this point it's nearly impossible. So, please set it to delayed for a while.
Favorite animal: STOCK Gt(ROSA)26Sortm1.1(rtTA,EGFP)Nagy Grm7Tg(SMN2)89Ahmb Smn1tm1Msd Tg(SMN2*delta7)4299Ahmb Tg(tetO-SMN2,-luc)#aAhmb/J YouTube Twitch Twitter
Post subject: Explanation of the glitch
Masterjun
He/Him
Experienced Forum User, Site Developer, Skilled player (1822)
Joined: 10/12/2010
Posts: 1153
Location: Germany
Exotic platforms TAS of 2020Speedy TAS of 2018PC TAS of 2018Glitchy TAS of 2015TASer of 2014SNES TASer of 2014TAS of 2014SNES TAS of 2014Funny TAS of 2014Glitchy TAS of 2014TASer of 2013SNES TASer of 2013NES TAS of 2013SNES TAS of 2012Funny TAS of 2012
Posting everything I have so far. After hours of reverse engineering literally everything that happens (juggling two emulators, a bunch of scripts, tons of logs, etc. you get the idea), I found out a lot of things that don't happen. Process of elimination then got me to a conclusion which was quickly confirmed by a conversation with link_7777 (thanks for that!). With that I then wrote a bot that would test a bunch of possible situations, but that was only possible thanks to the emu.totalexecutedcycles() implemented by adelikat (thanks for that!). Let's start with things we already got by simply trying: Changing button presses changes if the glitch works or not. So how does changing the button presses, !which, when processed, are not even read!, change the glitch results? Now let's start with the further explanations: The obvious thing that I already found out last time is how the whole process will jump to an address in the wrong bank. It will execute a bunch of bogus code and maybe land in the credits routine mode. Now the question is, what is the difference between a result of a simple crash and a credits jump? Logging both, comparing files, critical point at a certain JSR $3C37, which jumps into the mirrors of the PPU registers.
3C37:  00  BRK
<BRK>
3C39:  00  BRK
<BRK>
3C3B:  00  BRK
<BRK>
3C3D:  00  BRK
<BRK>
3C3F:
I stopped at $3C3F because that's where the code differs. $3C3F is a mirror of $2007 which is the PPUDATA register. The important part here is the fact that we're not in VBlank (the part of the frame where the scanline laser reverts back to the top left of the screen), and reading PPU registers when not in VBlank will give us strange values[1], values used by the PPU drawing pixels on the screen. What does this tell us? It means two things: 1. Changing the pixels on the screen could change the results of the glitch. 2. Changing the time at which $3C3F is executed could change the results of the glitch. And how do you change the timing? Exactly! Different button presses lead to different branch paths in the button processing code and thus lead to different timing. This also means that it's possible to exchange different buttons (assuming they both aren't accessed beyond the processig) and still get the credits! (Which is confirmed to work.) Most importantly though, which timing do we need now? The problem is that even small cycles amounts can and will change the outcome completely, so I wrote a bot that tries every single cycle (to like +300, because we won't be able to change it much more). The only cycles it found was the one we already got, and this one, which resets you to the start of the room. The one we already got requires so many buttons, and changing buttons before the frame with the mandatory Start barely changes the cycles, so it won't be possible to reduce that two frame input to a single one. At least not without changing the pixels on the screen, which is what I'm trying currently. [1] - You might have seen that $3C37 is also a mirror of $2007, but it seems like the first read of that register (including mirrors) in non-VBlank gives you a stable 00.
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)
Alyosha
He/Him
Editor, Experienced Forum User, Expert player (2820)
Joined: 11/30/2014
Posts: 2467
Location: US
NES TASer of 2015
Since things here are dependent on true cycle accuracy, you might want to wait until some console testing can be done to finalize DCM timer startup before trying to make a final run. Right now I found 2 places in the run where a DCM read occurs that would effect the final cycle timing at the glitch. Unfortunately these instances may change with more accurate knowledge of DCM startup state (a process which was started with Ninja Gaiden but never finished.) You might also be able to use this to your advantage if you can purposely trigger a DCM glitch and cause a re-read to eat up some cycles. Unfortunately there just isn't a way to nail down DCM startup state without some more testing.
Editor, Experienced Forum User, Expert player (2258)
Joined: 5/15/2007
Posts: 3825
Location: Germany
Gameboy TASer of 2015NES TAS of 2013Gameboy TASer of 2011Gameboy TASer of 2010
I was actually always under the impression that enemy spawns play a certain role in the outcome of the glitch. Back when I made the first two TASes in this category, I found myself in situations where the credits warp didn't work at all unless I went back to redo the previous room. I guess this plays into what you mean with, the game executes bogus code before finally landing in the credits routine. The enemy spawns have an influence on the bogus code and may prevent execution from entering the credits routine. Not sure if this info is useful.