Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
http://tasvideos.org/userfiles/info/44988607938034213
Here is a partial re-sync of the TAS in BizHawk. I ran into some trouble towards the end of Ice man stage as a bird spawned that wasn't there in the original and I oculdn't get a good zip.
Maybe someone who actually knows how to TAS mega man can do better.
The good news is that Both BizHawk and Mesen agree that this is exactly what happens, which means they agree to a single instruction. This gives me high confidence that a console verification will work.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
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! :)
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
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:
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.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
jlun2 wrote:
I'm not sure if it's just my computer, but when I was using TAStudios with GBHawk, saving a tasproj file (the Sailor Moon run to be specific) took a long time for some reason. Loading a branch also took a while. Is that normal? Saving seems to take shorter amounts of time when using the mgba core for GBA game TASing.
I'm not really sure, I'm not sure how that functionality works.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
I did some research on what a 'no new content' goal of this game would entail.
The value at $3D in RAM controls the speed of the enemies / divers. It increases every time you return to the surface with a diver. It doesn't matter how many divers you return with, even with 6 divers the value increases by one.
Bahaviour changes all the way through the range 0-255. Some Degenerate behaviour occurs around 0xFB, but as long as you stored enough divers you can make it roll over back to 0.
So the 'no new content' condition would require rescuing 256 divers (plus triggering the surface partolling sub to appear which is a different condition.)
I don't really intend to do all that. I made a rough run up to 0x80 that wasn't optimized at all and it's just too tedious. Maybe it would make a good bot project for anyone who might be interested in such things.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
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.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
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.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Tested on BizHawk and yeah you need to use the full screen settings. For NesHawk go to NES -> Graphics Settings -> Full [0,239]
You can do a similar thing in FCEUX in config -> video
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
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.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
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.)
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
The run [2599] A2600 Seaquest by morningpee in 01:39.80 relies on a glitch that is the result of emulation error. I plan to submit a run to obsolete that one that doesn't use the glitch.
However, I saw a lot of discussion on that movie's thread about goal choice, ending, and branch name, and I wasn't really sure what the ultimate conclusion was. Should the existing run still be held in 'moons' or is it actually in the vault?
What kind of run would I have to submit to obsolete that one? Does it have to be a 'max score' run or could it be a 'no new content' run? (A max score run would likely just be repeating the highest scoring pattern every level until the end which would be about 25 minutes of repeated play.)
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
For some time I have been trying to reproduce the 'no despawn glitch' as demonstrated in the currently published TAS. [2599] A2600 Seaquest by morningpee in 01:39.80
So far, I have been totally unable too. The discovery of the glitch was also made on emulator (probably an early version of Bizhawk but I don't know for sure, as is obvious from the divers sticking out of the left edge of the screen.) So far I have found no evidence that it works on console and cannot reproduce it in the current version of BizHawk. I am becoming convinced that the glitch itself is an emulator bug.
This would be unfortunate as it would completely invalidate the TAS.
I'm posting this here in case it piques anyone's interest. I don't have a lot of time at the moment to sort this out, but any demonstration that the glitch works on BizHawk 2.2.1 (or console) would be a welcome and easy solution.
EDIT: The sub is one pixel too far to the left on BizHawk 1.6.1. Bizhawk 2.2.1 and Stella are in agreement on it's poisition. This is likely the cause of the glitch/bug.
EDIT2: Yup, I can confirm that moving the sub one pixel to the left is what makes this 'glitch' possible. I'm quite certain now that this glitch is just an emulator bug and the TAS (and the glitch itself) is not possible on hardware.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
fsvgm777 wrote:
Alyosha wrote:
I just added suport for korean BIOS. I'll try to make region choice a little more clear cut as well going forward.
Not sure if it's intentional, but I don't seem to be able to access the Korean BIOS in any way on the latest interim builds?
Make sure you have 'Region' set to auto. This will(should) then automatically boot with Korean bios for games recognized as korean ROMs in the game db.
EDIT: Regarding Aladdin, it appears to be only a EU ROM. The game doesn't appear to have been released in the US. It does have a Korean release, but I'm not sure if the ROM is any different (I can't find a specifically korean one.)
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
MESHUGGAH wrote:
Bizhawk 2.2.1 Gambette Cheats crash
1. Open GB ROM
2. Add a cheat using the Cheats tool
3. Save a state
4. Load that state
5. Press CTRL+R for crash
Was trying to check some stuffs in Super Mario Land to generate lag frames with the Cheats tool. Don't know if it's only Gambette issue (tried A7800, no crash)
Can't reproduce on the dev build, seems to work.
(Anything Gambatte related, just use the dev build for, many things have changed for it since 2.2.1)
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
https://segaretro.org/
Sega Retro is an excellent resource for this kind of thing. It gives a lot of valuable information about which titles are released where as well as a lot of other neat facts.
I'll look at that specific case when I have more time.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
MESHUGGAH wrote:
BizHawk 2.2.1 no gameboy firmwares crash:
1. Open a GB ROM (drag and drop)
2. Set "use BIOS" to true and place GB Bios in firmwares
3. Open a GB ROM (drag and drop)
4. Open a GBC ROM (drag and drop)
Using the above steps it should always crash. After writing this post (while doing these steps), GB ROM doesn't have BIOS however it says "True" in bold letters. This also works revers (GBC ROM, place GBC BIOS, GBC rom, GB ROM)
These crashes have since been fixed and will roll out with 2.2.2. Try the dev build if you want to test it out.
