1 2
19 20
Skilled player (1706)
Joined: 9/17/2009
Posts: 4952
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
Alyosha wrote:
I console verified the first level of Airaki by Furrtek, a game that purposely tried to be difficult to emulate, with no issues. I also realized that twitch doesn't automatically save your past broadcasts, so none of the verifications I did previously were saved, oops. I'll be recording some of them and uploading to youtube. Hopefully I can have Spirou, Zen, SMB Deluxe, and Mega Man Xtreme up today, and the Oracle games later in the week.
IIRC twitch deletes old streams after 2 weeks so it might be worth backing up on youtube.
Alyosha
He/Him
Editor, Expert player (3532)
Joined: 11/30/2014
Posts: 2728
Location: US
Link to video (I had to mute part of the video due to copyright claim.) Catching up on some stuff. Here is a resync of Operation C that I console verified. The original does not sync in level 2, so I redid parts of it (the second boss is a few frames faster.) But I didn't keep track of lag in level 3 so I don't know if it's faster overall, it's too much of a hassle to compare to VBA.
Alyosha
He/Him
Editor, Expert player (3532)
Joined: 11/30/2014
Posts: 2728
Location: US
I'm starting to look at the console desync in Castlevania The Adventure (JPN, GB) Runs made in GBHawk also desync on console. Unfortunately, trace logs deviate between Gambatte and GBHawk even before there is any input. The immediate reason is that gambatte returns STAT mode 0 for 4 cycles in between vblank and the start of mode 2 on scanline zero. This behaviour can be verified to be incorrect (at least on GBP) with the test ly00_mode1_2-C.gb. I tried it on my GBP and it passes there, so this needs to be fixed before I can dig any deeper into it. I made an issue for this in Gambatte speedrun.
Alyosha
He/Him
Editor, Expert player (3532)
Joined: 11/30/2014
Posts: 2728
Location: US
I changed GBHawk's behaviour to match gambatte on the end of VBL just to see if it would otherwise match execution. After doing that it looks like GBHawk has an error in window enable. I'm still looking to see if an existing test tests this particular case. It's surprising that this relatively basic case hasn't come up before (activating window at LY>WY), still a lot of work to be done.
Emulator Coder, Judge, Experienced player (608)
Joined: 2/26/2020
Posts: 698
Location: California
Alyosha wrote:
I'm starting to look at the console desync in Castlevania The Adventure (JPN, GB) Runs made in GBHawk also desync on console. Unfortunately, trace logs deviate between Gambatte and GBHawk even before there is any input. The immediate reason is that gambatte returns STAT mode 0 for 4 cycles in between vblank and the start of mode 2 on scanline zero. This behaviour can be verified to be incorrect (at least on GBP) with the test ly00_mode1_2-C.gb. I tried it on my GBP and it passes there, so this needs to be fixed before I can dig any deeper into it. I made an issue for this in Gambatte speedrun.
I've done some work looking into this, and was able to hack a "fix" for that test, which ended up failing 41 tests in the testrunner lol. I ended up actually looking into these failures to see if any of them happen to fail on GBP, and found 3 of such: https://cdn.discordapp.com/attachments/842947491435118622/845700752252993577/Screenshot_20210522-093144.png The regressions here I might be able to get away for this game, but even then, a good fix still needs to come.
Alyosha
He/Him
Editor, Expert player (3532)
Joined: 11/30/2014
Posts: 2728
Location: US
Yeah this is a case where gambatte being tuned to older model GBC's is definitely making things difficult. Do you have a list of the other 38 tests that failed with your fix? I'd be interested to see how they fair in GBHawk. Anyway, after looking at tracelogs with GBHawk modified behaviour on VBL, and matching window enable behaviour to gambatte, the next place there is a desync is in a sprite + scroll mode 3 timing check. I'll take a closer look, but I'm pretty confident in GBHawk's mode 3 timing, and Gambatte is known to need some work in this area, so I think this is a problem on Gambatte's end. All of that being said, I tried a test run with a fixed window behaviour in GBHawk and it still desynced on console (almost made it to the rope but not quite) so something is still not right, this game is proving interesting for emulation.
Emulator Coder, Judge, Experienced player (608)
Joined: 2/26/2020
Posts: 698
Location: California
Alyosha
He/Him
Editor, Expert player (3532)
Joined: 11/30/2014
Posts: 2728
Location: US
CasualPokePlayer wrote:
Here are the tests the hacky "fix" made fail: https://cdn.discordapp.com/attachments/842947491435118622/845859569195417610/failed_tests.zip
Thanks, looks like GBHawk still fails about a dozen of those, including some single speed ones. The last time I worked on screen timing stuff was quite painful, hopefully nothing is too seriously wrong. I took a closer look at where things go wrong compared to console, and it's actually much earlier then I thought. The game turns on the screen mid way through a frame when it's ready to start gameplay, and this gives a helpful visual queue of how things are syncing. Here is what GBHawk and Gambatte show: and here is console: So something is wrong in between pressing start and game loading, I have no idea what, I don't think there are any sprites involved at this point. If I make GBHawk's VBL behaviour match Gambatte, then I do get the same screen as Gambatte, so it seems like there might be some new behaviour at play here.
Alyosha
He/Him
Editor, Expert player (3532)
Joined: 11/30/2014
Posts: 2728
Location: US
After comparing video again, I realized that something wasn't right with how input was getting sent to the console. As it turns out, the recent fixes I made to fix the BizHawk issue with autofire broke the dump script (because it was decrementing the frame count from core, which it no longer needs to do.) After fixing that (updated script posted to OP), everything syncs just fine, there is no mystery here, only me not keeping track of stuff carefully. @CasualPokePlayer: this might effect gambatte too, might want to check input dumps in dev build. I did have to delay input in one spot because input was polled right on a frame boundary, nothing I can do about that one. It also syncs with or without the window timing fix, so I'll have to investigate that one on it's own some more. Gambatte will still need the mode 3 fixes and the end-of-VBL fix to work, but those are already known issues. So, I'm calling this one closed.
Emulator Coder, Judge, Experienced player (608)
Joined: 2/26/2020
Posts: 698
Location: California
I just dumped my Gold Glitchless TAS on a dev build yesterday, so it's probably not affecting Gambatte's input scripts? Unless this change was very recent. Although for this game, I'll note I used a different script, instead just hooking onto FF00 writes (which apparently worked best for capturing the inputs lol), and debugging input boundary issues: https://cdn.discordapp.com/attachments/842947491435118622/846109779595100230/timestamps.lua
Alyosha
He/Him
Editor, Expert player (3532)
Joined: 11/30/2014
Posts: 2728
Location: US
The changes were made two days ago.
movie.getinput(emu.framecount() - 1)
is what would make it break. Now it should just be
movie.getinput(emu.framecount())
Alyosha
He/Him
Editor, Expert player (3532)
Joined: 11/30/2014
Posts: 2728
Location: US
Did some testing of castlevania adventure in the dev build with updated gambatte. Execution is now identical up to a desync due to mode 3 timing.
Post subject: Wario Land 3 OoB
SoapAgent
He/Him
Joined: 4/2/2017
Posts: 13
Location: TASVideos.org, of course...
I was told to post this here. Basically, GBHawk doesn't emulate the OoB in Wario Land 3 properly, or at least not in this level. Below are videos from different platforms showing how the OoB is supposed to behave for the purposes of a speedrun: Gameboy Interface (Twitch clip) Gameboy Player (Twitch clip) 3DS Virtual Console (Twitch clip) BGB 1.5.8 (YouTube, timestamped) I couldn't find a run on the speedrun.com leaderboard that was definitely on gambatte, so I recorded it myself. I do have more powerups than you would normally have in a speedrun, but that doesn't affect the OoB in this particular case. gambatte-speedrun (YouTube, timestamped) In the preceding videos, Wario falls down about 2 screens while hugging the left wall. Next, he heads right a bit before reaching the bottom of the screen for the third time and a jump is buffered by holding A. He lands on a 3 or 4 tile wide platform in OoB, but immediately jumps and is able to get hit by the Pneumo (the mosquito-thing that inflates Wario). Meanwhile, in GBHawk, this platform is missing, and other features of OoB are also incorrect (At the bottom, there should be blocks that Wario can dash into that will make unloaded tiles appear a deep blue. At the top of the RAM, there should be plenty of garbage; however, there is just a solid ceiling). I believe this is similar to or the same as how this OoB behaves in VBA, but I don't know for sure. Anyway, here is an HD encode of a LOTAD that shows how the OoB doesn't behave properly in GBHawk (starting at around the 1-minute mark): YouTube link I wasn't anticipating that the first OoB section wouldn't work. I originally stumbled upon this problem because I wanted to test a new OoB room that only works on emulator, behaves slightly differently on 3DS, and crashes the game on original hardware. However, I cannot even get to that room because I have to be in this version of the level (daytime, without the blue snake door open), and in order to get to the correct section of the level without the blue snake door, this first bit of OoB has to be used. If I had to guess, even if I used cheat codes to move Wario into the proper in-bounds room and performed the setup to get into OoB there, that room would probably not be accessible in the first place. Movie used for the above video: User movie #73008826659546776
Alyosha
He/Him
Editor, Expert player (3532)
Joined: 11/30/2014
Posts: 2728
Location: US
Thank you for the detailed report. I am in NES development mode for now, so my recommendation is to use Gambatte in the dev build for the time being until I can look further into this (which may not be for a month or so): https://ci.appveyor.com/project/zeromus/bizhawk-udexo/build/artifacts
Emulator Coder, Judge, Experienced player (608)
Joined: 2/26/2020
Posts: 698
Location: California
Alyosha wrote:
Thank you for the detailed report. I am in NES development mode for now, so my recommendation is to use Gambatte in the dev build for the time being until I can look further into this (which may not be for a month or so): https://ci.appveyor.com/project/zeromus/bizhawk-udexo/build/artifacts
Gambatte-Speedrun r717 works so a dev build is not needed, a recent BizHawk release (2.4.1+ should match r717) should work fine.
SoapAgent
He/Him
Joined: 4/2/2017
Posts: 13
Location: TASVideos.org, of course...
Actually, ignore my above post. Upon further inspection, it appears that saving and reloading the level (through the in-game save menu) is necessary in order to get the platform to appear there. I didn't realize that there are portions of OoB that are affected by saving, and I thought the saving in speedruns is done purely for making the wall clip setup much easier. (It's definitely used for that too, but I guess it has two functions.) I feel kind of dumb for not testing this since I assumed that saving was only for RTA consistency, but there are at least a couple cases in the previous game where saving and reloading changes the OoB so I guess I'm not too surprised. Anyway, after I finish what I'm doing in gambatte, I'll look into if the newly discovered emu-only glitch room behaves "improperly" (i.e. like the other emulators) in GBHawk.
Alyosha
He/Him
Editor, Expert player (3532)
Joined: 11/30/2014
Posts: 2728
Location: US
I encountered a desync in The World is not Enough in both Gambatte and GBHawk: Gambatte: http://tasvideos.org/userfiles/info/73232337575963718 GBHawk; http://tasvideos.org/userfiles/info/73232329922675139 I'm not entirely positive, but I'm pretty sure this an input timing issue and not an emulation issue. The only difference between the GBHawk and Gambatte movies is that I had to add a few frames to Gambatte to account for the start up offset. Using the most recent Gambatte script I have, the run desyncs on console near the start of level 3. With the GBhawk script, it desyncs on the the code screen before the start of level 3. If I change this script to use 'floor' instead of 'ceiling' then it instead desyncs in the same manner as Gambatte. Haven't looked through trace logs or anything yet, but since both movies play the exact same input timing in the scripts seems likely.
Emulator Coder, Judge, Experienced player (608)
Joined: 2/26/2020
Posts: 698
Location: California
I took a peek at this desync. I logged out LY values during joypad polling, starting right before the code screen before level 3 all the way to the end: https://www.dropbox.com/s/4gjnk805vvqqgft/lyDebug.txt?dl=0 The game polls very erratically. Sometimes it's very early in a frame (LY 91), sometimes it's very late in a frame (LY 8F), sometimes it's in the middle of a frame, sometimes it's right after VBlank is finished, sometimes it's in the middle of VBlank, it's all over the place. I would definitely suspect input timings/rounding screwing us over here.
Alyosha
He/Him
Editor, Expert player (3532)
Joined: 11/30/2014
Posts: 2728
Location: US
Small update to The World is Not Enough sync issue. An updated version of the run syncs but only after a reset of the Game Cube. The game doesn't use uninitialized RAM in any way that I can tell, and has no SRAM, so I'm not sure why it only works from reset. From power on it desyncs consistently, and from reset it syncs consistently. Perhaps the timing offset from reset is slightly different, enough to offset the error from rounding and random polling time? I've never encountered this situation before, so right now I'm not really sure what's going on. EDIT: using floor instead of ceiling works from power on. Doesn't explain why ceiling works from reset only, but good enough for now.
1 2
19 20