Post subject: Impossible TASes
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3826)
Joined: 11/30/2014
Posts: 2834
Location: US
We generally accept that emulators are innaccurate without giving it too much thought. If a certain TAS happens to work on console, or a game happens to be particularly stable and easy to emulate, great, but just as a matter of practicality we don't spend much time thinking about it. If we had to wait for perfect emulation, we'd have hardly any TASes, so we settle for good enough. What's good enough? Generally speaking if it 'looks right' no more attention is paid to it. This works most of the time, maybe you did a jump in a TAS that doesn't quite line up on console, but if it looks like it could work with only minor adjustments then it's probably close enough. Or maybe some RNG manipulation doesn't quite work out, but if slightly different manipulation could still make it work, well close enough. But, how do you know? Can we know which TASes are fixable, and which ones are impossible, even in principle? I recently realized that [2599] A2600 Seaquest by morningpee in 01:39.80 relies on a glitch that doesn't even exist in reality. The majority of the encode is showing something that will literally never happen. I like to focus on accuracy, so for me this was a bit un-settling. But originally I thought, 'Well it's only A2600, who really cares? It's only a 1:45 long TAS, I'll make a replacement and move on.' Yesterday though I remembered that this wasn't the first time I saw something like this! [749] NES Paperboy by Randil in 11:30.78 Paperboy is just as bad as Seaquest. The customer houses are determined by the number of cycles from power on until the code reaches a certain point. FCEU is not even close on this, so it gives an arrangement that you would never see in a real console. Now we're in NES territory, with hundreds of runs dating back over a decade. So now I'm wondering how many more TASes are out there like this. How many LOOK right but in fact rely on emulator bugs? How many impossible TASes are there? I think this is more then a philisophical question. We spend hours and hours working on a TAS, I think most people wouldn't want to work on something that is inherently flawed on the tool they are using. Can anyone else think of any examples? Are there any runs you suspect have something fundamentally wrong with them? (I'm currently looking at [1686] NES Mega Man by Shinryuu & finalfighter in 12:23.34 The NMI race condition at the start of Ice Man stage is known not to work on console (and desyncs in the same manner on BizHawk.) I don't know if it can be fixed or not.)
MESHUGGAH
Other
Skilled player (1919)
Joined: 11/14/2009
Posts: 1353
Location: 𝔐𝔞𝔤𝑦𝔞𝔯
If your question is: "Anybody knows TASes relying on emulation bugs", it's probably discussed in the submission text. I don't know any TAS that has emulation bug AND it isn't noted somewhere on the site. edit2: Regarding NES verifications: Wiki: ConsoleVerificationTests I'm also unsure about that anyone will come here and post a published TAS that probably relies on an emulator bug which would require the knowledge of the game and platform itself (cause I guess you are looking for known cases, not potential ones). I made a thread about Doom relies on inaccurate and not input based "replay system" (it's not an emulator). As a result of the basics behind that particular TASing system is that none of the TASes will be possible to replicate when a much accurate system becomes available. They will be required to TAS all the way from the beginning. The same applies to Half-Life TASes because of the way they are required to create and play. edit: however I know a lot of potential impossible TASes in the future like subframe/midframe inputs like SMS games with pause spam to get over the title screen if you are interested in. Cycle level resetting for RPGs etc.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Site Admin, Skilled player (1255)
Joined: 4/17/2010
Posts: 11492
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
Back when FinalFighter came up with the trick (which is, let's admit, revolutionary), no one was sure it's even supposed to work. He made a ROM hack what recreates the conditions that need to be met, and it was verified on a powerpak. Debugging it was tricky, but in the end it was concluded that it's possible to make it work. But no one suspected that the very concept won't work on console. I don't think that's what you're saying tho. If the conditions are different, improving them and improving the run might fix the verification. If conditions used in that run are outright impossible, then it's pretty sad. Start from this post: http://tasvideos.org/forum/viewtopic.php?p=223361#223361 Another point. Inaccuracy itself doesn't spoil the joy of tasing. We want to optimize games, we do it. If they are inaccurately ran, well, we optimize romhacks, fine. But accuracy is still required by movie rules for a reason. Possibility of console verification was still a basis since the beginning. So while TASing on accurate emulators doesn't kill the joy from tasing, using inaccurate emulators for that might kill the joy of some people involved, since there's quite a lot of spheres that overlap here: TASing, video encoding, emulator coding, software tool development, hardware tool development, even presence at events like GDQ. The more spheres are involved, the more importance accuracy gets. I want to say that even before the first SMW game end glitch was verified, seeing that was my dream. And an even crasier dream was showing that on console before thousands of people at AGDQ. It happened! It became the highlight of the event for years! Standing ovations after Pokemon Plays Twitch, man, isn't that one of the nicest things TASing ever caused? Well, after dethroning Todd Rogers of course.
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.
Post subject: Re: Impossible TASes
Editor, Expert player (2331)
Joined: 5/15/2007
Posts: 3940
Location: Germany
Alyosha wrote:
So now I'm wondering how many more TASes are out there like this. How many LOOK right but in fact rely on emulator bugs?
#1580: Bag_of_Magic_Food, nesrocks & Randil's GB Super Mario Land 2: 6 Golden Coins in 18:21.73 The pipe glitch itself is emulated correctly, but part of the RAM underneath the level is made up of breakable blocks instead of empty space. Kirby Super Star has a bug that lets you warp to the final boss on ZSNES under certain circumstances. Many people in Youtube comments tend to end up thinking it is a legit bug, from what I've seen many years ago... I think someone went ahead and uploaded a cheated run to nicovideo at one point. It used the emulation glitch and there was a mouse cursor on the video due to bad video editing... Speaking of cheated runs, someone had made a cheated run of Earthbound that clipped through the Onett cliff without a skip sandwich. That's as far as I remember about illegitimate runs.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3826)
Joined: 11/30/2014
Posts: 2834
Location: US
MESHUGGAH wrote:
I'm also unsure about that anyone will come here and post a published TAS that probably relies on an emulator bug which would require the knowledge of the game and platform itself (cause I guess you are looking for known cases, not potential ones).
Actually I am looking for potential cases. Sequest was assumed to be correct for 3 years, so I'm curious if there are other similar instances. Also I'm not so much interested in runs that simply fail to sync on console, that would be most runs. I'm interested in ones that have some fundamental error that can't be simply fixed.
feos wrote:
If the conditions are different, improving them and improving the run might fix the verification. If conditions used in that run are outright impossible, then it's pretty sad. Start from this post: http://tasvideos.org/forum/viewtopic.php?p=223361#223361
Yes this is precisely what I'm interested in finding out.
MESHUGGAH
Other
Skilled player (1919)
Joined: 11/14/2009
Posts: 1353
Location: 𝔐𝔞𝔤𝑦𝔞𝔯
Impossible due hardware: - Famicom 2P controller has no start button, but the console accepts it. Example: [2840] NES Atlantis no Nazo by exposure in 02:20.12 Possible but hard to implement correctly - Famicom Disk System loading time emulation... Here's my movie where I somehow able to skip one of the loading parts after selecting player and before starting the game (IIRC!): http://tasvideos.org/userfiles/info/40067147588770269 - Very laggy games like Jackal are prone to desync wherever they want on console - Initialized RAM... affects for example NES Metroid Might be impossible to ever sync: - There are games where the smallest change in timing changes everything. Example: Indiana Jones and the Temple of Death Known phenomenons outside of emulators: - Battletoads finishing the game by pressing the Reset button (but deemed to be a "malfunctioning cart"). I personally believe that this is related to the initialized RAM values for not working in emus. - One of the NES Megaman games having a boss or an enemy being present on console but not on emulator... I've read this first on SDA and then someone also posted it on this site. Future TASes: - Subframe inputs, example: SMS pause spam - Subframe resets, example: RPGs - Non frame based systems and highly different between hardwares, example: J2ME - Cart swapping
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Experienced player (691)
Joined: 11/23/2013
Posts: 2238
Location: Guatemala
MESHUGGAH wrote:
Impossible due hardware: - Famicom 2P controller has no start button, but the console accepts it. Example: [2840] NES Atlantis no Nazo by exposure in 02:20.12
Remember that the A/V Famicom exists, which has the same controller ports as the NES.
Here, my YouTube channel: http://www.youtube.com/user/dekutony
Skilled player (1742)
Joined: 9/17/2009
Posts: 4986
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
So.... [2285] GBA Densetsu no Stafy "demo glitch" by jlun2 in 03:28.68 Ok, so the glitch is that if you restart when opening the menu, the temp save messes up, and you end up loading wierd things. Reset must be done on a lag frame, which means it's a hard reset, so the BIOS will play back every time the glitch is used. This movie isn't technically "impossible", but IF you do this on console, the last boss makes zero sense to restart over and over due to the BIOS playing back over and over. The glitch REQUIRES a hard reset since it occurs during a lag frame, so if this run were to be done on mGBA, it must beat the last boss "legit" simply due to the BIOS taking too long. tl;dr An updated TAS of it will be forced to be slower due to BIOS if reset; last boss cannot be glitched without significant slowdown. Also the run resets like 3 times to reach the boss, so the BIOS will be forced to playback more than once anyways. If it's any help, I can try remaking it in BizHawk and submitting it. I hope it doesn't cause too much issues. Edit: This same scenario also occurs for Dementium the Ward TAS, but for 1 single situation during the mouth room boss, where skipping the cutscene causes crashes after the chapter and forces a reset. The BIOS on a console would make this slower than simply viewing the cutscene.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3826)
Joined: 11/30/2014
Posts: 2834
Location: US
jlun2 wrote:
So.... [2285] GBA Densetsu no Stafy "demo glitch" by jlun2 in 03:28.68 Ok, so the glitch is that if you restart when opening the menu, the temp save messes up, and you end up loading wierd things. Reset must be done on a lag frame, which means it's a hard reset, so the BIOS will play back every time the glitch is used. This movie isn't technically "impossible", but IF you do this on console, the last boss makes zero sense to restart over and over due to the BIOS playing back over and over. The glitch REQUIRES a hard reset since it occurs during a lag frame, so if this run were to be done on mGBA, it must beat the last boss "legit" simply due to the BIOS taking too long. tl;dr An updated TAS of it will be forced to be slower due to BIOS if reset; last boss cannot be glitched without significant slowdown. Also the run resets like 3 times to reach the boss, so the BIOS will be forced to playback more than once anyways. If it's any help, I can try remaking it in BizHawk and submitting it. I hope it doesn't cause too much issues. Edit: This same scenario also occurs for Dementium the Ward TAS, but for 1 single situation during the mouth room boss, where skipping the cutscene causes crashes after the chapter and forces a reset. The BIOS on a console would make this slower than simply viewing the cutscene.
I think this is a very interesting case. My personal opinion is that our technical standards are way to low in this area, and I would like to see a realistic replacement. Quite interesting regardless. EDIT: Another interesting case is [2821] A2600 River Raid by Lord_Tom in 1:22:47.90 The version of BizHawk used in this case has an error in the timer. The error is slight, but over an hour, it adds up to several seconds.
Skilled player (1742)
Joined: 9/17/2009
Posts: 4986
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
http://tasvideos.org/userfiles/info/44858263236234342 I managed to trigger the warp on the mGBA core on the latest version of BizHawk, so at least the run's core route works on a more accurate emulator. Unfortunately, the glitch isn't quite the same; I'm forced to use the 2nd room instead, and for some reason visually, it appears different; on the vba run, I appear on the 2nd stage, but the game treats it as last. On BizHawk, the NPCs for the 2nd stage appear, but the background and all is still from the final stage. I'm not sure if it's because the reset timing is different, or if it will work if subframe reset is implemented, but I'm not sure how to trigger the boss in the first room like the current run. I have no idea if it's truely impossible due to my lack of (assembly) knowledge, but I hope not.
Alyosha wrote:
EDIT: Another interesting case is [2821] A2600 River Raid by Lord_Tom in 1:22:47.90 The version of BizHawk used in this case has an error in the timer. The error is slight, but over an hour, it adds up to several seconds.
How much difference gameplay wise is that? Does it affect the RNG (or syncing)?
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3826)
Joined: 11/30/2014
Posts: 2834
Location: US
jlun2 wrote:
... I'm not sure if it's because the reset timing is different, or if it will work if subframe reset is implemented, but I'm not sure how to trigger the boss in the first room like the current run. I have no idea if it's truely impossible due to my lack of (assembly) knowledge, but I hope not. ... How much difference gameplay wise is that? Does it affect the RNG (or syncing)?
Seems like we need trace logger in mGBA to sort that one out. The gameplay is quite different I can barely make it past the first bridge and then things fall apart. It could also be due to the other errors in the A2600 core at the time, either way it doesn't work. Also, coincidentally from current events it seems like [3424] SNES Super Metroid "game end glitch" by Sniq, total & Aran_Jaeger in 07:09.68 is also impossible from discussion here. At least that one's getting a replacement presently.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3826)
Joined: 11/30/2014
Posts: 2834
Location: US
I looked a little into Rockman to see how far off things were in IceMan stage to make the 'DelayWaterCurrent' glitch work in BizHawk. First, the idea of the glitch is that during lag frames, it's possible for an NMI to interrupt processing when ROM bank is changed to 6. If the NMI occurs after the ROM bank is changed, but before the change is stored in the backup location ($42) then bank is not restored correctly once NMI is exited. This happens in FCEUX here:
c346972718   A:00 X:1F Y:04 S:FD P:nvUBdIZC  $D89B:A9 06     LDA #$06
c346972720   A:06 X:1F Y:04 S:FD P:nvUBdIzC  $D89D:8D 06 C0  STA $C006 = #$06
c346972731   A:06 X:1F Y:04 S:FA P:nvUBdIzC  $D4A8:48        PHA (NMI)
.
.
.
c346975662   A:05 X:05 Y:00 S:F7 P:nvUBdIzc  $D571:9D 00 C0  STA $C000,X @ $C005 = #$05
.
.
.
c346975697   A:06 X:1F Y:04 S:FA P:nvUBdIzc  $D582:40        RTI
c346975703   A:06 X:1F Y:04 S:FD P:nvUbdIzC  $D8A0:85 42     STA $0042 = #$05
In BizHawk, the NMI occurs too early by only 2 instructions:
D898:  F0  BEQ $D89B       A:00 X:1F Y:04 P:37 SP:FD Cy:346940446 nvTBdIZC
====NMI==== 
.
.
.
D582:  40  RTI             A:00 X:1F Y:04 P:26 SP:FA Cy:346943422 nvTbdIZc
D89B:  A9  LDA #$06        A:00 X:1F Y:04 P:27 SP:FD Cy:346943428 nvTbdIZC
D89D:  8D  STA $C006       A:06 X:1F Y:04 P:25 SP:FD Cy:346943430 nvTbdIzC
D8A0:  85  STA $42         A:06 X:1F Y:04 P:25 SP:FD Cy:346943434 nvTbdIzC
Two instructions are all that seperates possible and impossible in this case. The glitch itself is has to occur exactly between changing bank and storing in $42. Unfortunately it's hard to say why those 2 instructions of difference exist between FCEUX and BizHawk, so this is about all I know for now. I'll try some available LUA scripts to see if another setup is posible. Also, I'll try changing ppu power up timing as this is known to vary on console and might change timing by the small amount we need here. I also tested on Mesen and the setup fails there as well. If nothing else, I find this to be a very interesting example of just how difficult it can be to know what is an emulator glitch and what isn't.
Site Admin, Skilled player (1255)
Joined: 4/17/2010
Posts: 11492
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
Extreme botting was used to trigger this event. I remember millions of rerecords in the original submission. I disagree that having the bot hit an event 2 instructions too late is just an emulator glitch in principle. The event is right there, align objects differently and it will hit on a more accurate emulator.
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, Emulator Coder, Expert player (3826)
Joined: 11/30/2014
Posts: 2834
Location: US
feos wrote:
Extreme botting was used to trigger this event. I remember millions of rerecords in the original submission. I disagree that having the bot hit an event 2 instructions too late is just an emulator glitch in principle. The event is right there, align objects differently and it will hit on a more accurate emulator.
Yes you are right, it is possible, I just found a setup for it! It works on both BizHawk and Mesen. Looks like this one might be moving towards console verification! :)
YaLTeR
He/Him
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
MESHUGGAH wrote:
The same applies to Half-Life TASes because of the way they are required to create and play.
What do you mean? Half-Life TASes (as in Half-Life 1) made with BXT store basically actual input (and don't rely on demos or stuff like that).
MESHUGGAH
Other
Skilled player (1919)
Joined: 11/14/2009
Posts: 1353
Location: 𝔐𝔞𝔤𝑦𝔞𝔯
It's hard to answer this straightforward, but the simple answer is that those TASes can't exploit various bugs AND there could be things that won't work the exact same way. The TASes for Doom and Half-Life can be converted later, but will require many tests redone once we achieve "perfect" emulation. Judging by prior experiences of the very first TAS Life (forgot what was the name), there are known glitches that doesn't works there because of the way it works (the server side code isn't blocked, so you can't abuse things that rely on them like the jumpbug, the ability to cancel fall dmg by releasing ducking ~2 units above the ground and pressing jump, all done in the same server frame). Judging by creating my bot for understanding jumping mechanism in Counter-Strike, I've got different results depending on how I tried to input them. My most succesful attempt was doing with AMXMODX, with still not same results everytime I played back. Judging by the half life source code, there are many inconsistencies that happens sub frame level.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
YaLTeR
He/Him
Joined: 12/2/2011
Posts: 129
Location: Moscow, Russia
It's extremely easy to make mistakes regarding how input is done and how FPS is handled, especially in newer engines. BunnymodXT takes all of that into account, we spent an enormous amount of time researching ins and outs of the engine. TAS Life is extremely outdated and doesn't handle most of the subtlieties correctly. But, I think this discussion is better continued elsewhere (like the BunnymodXT thread).
Skilled player (1742)
Joined: 9/17/2009
Posts: 4986
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
Alyosha wrote:
EDIT: Another interesting case is [2821] A2600 River Raid by Lord_Tom in 1:22:47.90 The version of BizHawk used in this case has an error in the timer. The error is slight, but over an hour, it adds up to several seconds.
I just remembered something. From the submission notes of the 100k run:
A commented disassembly by Thomas Jentzsch was helpful in figuring out how to manipulate enemy movements. Not sure why, but the memory addresses in the source don't match what's used in the emulator.
Does that have any effect, or nah, just a mistake in the disassembly?
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3826)
Joined: 11/30/2014
Posts: 2834
Location: US
^ I think that's just a result of memory mapping.
YaLTeR wrote:
But, I think this discussion is better continued elsewhere (like the BunnymodXT thread).
I don't even remember seeing that thread before. Seems cool though. We're probably out of the loop on a lot of these tools that individual communities have developed, I bet there is a lot of neat stuff out there.
Skilled player (1742)
Joined: 9/17/2009
Posts: 4986
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
jlun2 wrote:
http://tasvideos.org/userfiles/info/44858263236234342 I managed to trigger the warp on the mGBA core on the latest version of BizHawk, so at least the run's core route works on a more accurate emulator. Unfortunately, the glitch isn't quite the same; I'm forced to use the 2nd room instead, and for some reason visually, it appears different; on the vba run, I appear on the 2nd stage, but the game treats it as last. On BizHawk, the NPCs for the 2nd stage appear, but the background and all is still from the final stage. I'm not sure if it's because the reset timing is different, or if it will work if subframe reset is implemented, but I'm not sure how to trigger the boss in the first room like the current run. I have no idea if it's truely impossible due to my lack of (assembly) knowledge, but I hope not.
https://www.twitter.com/Natage_t/status/969584673809575937 Apparently the save glitch is sorta is possible, and from the Wii U VC at least. This gets a different screen from VBA/mGBA/others though. Thanks to "Diamond" for notifying this. Edit: The alternate route works, but again different screen: https://mobile.twitter.com/Natage_t/status/970167130602668032/video/1