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
Moderator
Joined: 8/3/2004
Posts: 14775
Location: 127.0.0.1
Fog
Experienced player (625)
Joined: 4/5/2014
Posts: 459
1, 2, 3, 4! I declare a frame war!
Experienced player (542)
Joined: 11/18/2011
Posts: 245
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.
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
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.
Spikestuff
They/Them
Editor, Expert player, Publisher (2254)
Joined: 10/12/2011
Posts: 6324
Location: The land down under.
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, Skilled player (1402)
Joined: 3/31/2010
Posts: 2081
1 ★ FRAME (Yes vote)
Experienced player (703)
Joined: 2/5/2011
Posts: 1417
Location: France
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, Skilled player (1502)
Joined: 7/9/2010
Posts: 1317
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
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
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 player (625)
Joined: 4/5/2014
Posts: 459
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
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
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.
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
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 player (607)
Joined: 11/8/2010
Posts: 4012
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
Spikestuff
They/Them
Editor, Expert player, Publisher (2254)
Joined: 10/12/2011
Posts: 6324
Location: The land down under.
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.
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
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.
Masterjun
He/Him
Site Developer, Skilled player (1968)
Joined: 10/12/2010
Posts: 1179
Location: Germany
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, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
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.
Spikestuff
They/Them
Editor, Expert player, Publisher (2254)
Joined: 10/12/2011
Posts: 6324
Location: The land down under.
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 player (625)
Joined: 4/5/2014
Posts: 459
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, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
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 player (607)
Joined: 11/8/2010
Posts: 4012
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, Skilled player (1502)
Joined: 7/9/2010
Posts: 1317
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
Post subject: Explanation of the glitch
Masterjun
He/Him
Site Developer, Skilled player (1968)
Joined: 10/12/2010
Posts: 1179
Location: Germany
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, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
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, Expert player (2310)
Joined: 5/15/2007
Posts: 3854
Location: Germany
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.