Posts for Alyosha


Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Another impressive TAS, nice work!
Koh1fds wrote:
>Also, after every 10 hits, he becomes invincible and starts smashing back and forth across the screen. You can skip that if you land 11th hit while he is in the air. It saves like 15 seconds or something https://youtu.be/jv4IF3dt4Po?t=1068 edit: i didnt discovered it by the way
There's just so much knowledge scattered about out there, it's crazy. Cool strat.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I did some testing with Mortal Kombat today. This game is interesting because it uses the serial port extensively even when there is no connection. it also uses the window as the primary part of the display. The test run I made desyncs almost immediately in GBHawk. Gambatte is slightly better (despite some sprite compatibility issues on emulator), making it through the first fight before desyncing on the second. Still so much work to do even for single speed mode.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
TiKevin83 wrote:
Is it just the last input that doesn't work? There has to be a blank input at the end of a GBI movie for the last input to work
There is a blank input at the end. Also this is just a trimmed down version of a much longer movie that also desynced in the same way.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Game: Daiku no Gen-san - Robot Teikoku no Yabou (Japan) Emulator: BizHawk: GBHawk in GBA mode Console Verification Device: Gameboy Player with GBI Movie: http://tasvideos.org/userfiles/info/66431762538224618 Description of Desync: On emulator, player character does not beat the level at the end of the movie. On Console, player character does beat the level. This appears to be deterministic and happens in the same way every time. Research: I have looked at invalid VRAM / OAM accesses, usage of uninitialized memory, and edge cases of IRQ source selection and nothing points to the cause of this desync. I have made an equivalent movie in Gambatte which is cycle-for-cycle the exact same as GBHawk, so no leads there either. Possible Next Steps: Sprite + x-scroll tests with x-scroll 4,5,6,7 would eliminate one possible source of error. Status: Open Closed. Resolution: This was in fact an edge case of sprite + scroll timing, in particular sprite evaluation at x=0. New test ROMs verified the behaviour.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
http://tasvideos.org/userfiles/info/66431762538224618 Here is a movie that demonstrates the desync in Gensan 2 as clearly as possible. On emulator, the character stops just short of beating the level before input ends. On console, the player beats the level, indicating that there is one less lag frame somewhere. I haven't narrowed down exactly where the desync happens. I played around with the inputs at the end, and there are some points where lag frames definitely line up differently compared to console, but it's hard to tell where this starts. I made a post about it in the console de-verified thread: http://tasvideos.org/forum/viewtopic.php?p=500074#500074 I'll probably move on for now since I've run out of ideas. Probably needs some new test ROMs around mode 3 but who knows for sure.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I tried working on some more of Gambatte's test ROMs to see if I was missing anything obvious that would effect Gensan 2. But, I ran into some trouble on some of the PPU tests. The issue is that this test: lycint152_ly153_3_dmg08_cgb04c_out00.gbc is incompatible with the results from AntonioND, gbc-hw-tests: mode1_disableint_gbc.gbc It appears that on later model GBCs (and presumably GBA and GBP) that LY timings are slightly different compared to older models and original GB. This effects other tests as well but this is the simplest case to see. I knew this was a problem, it causes at least one desync (Super R.C. Pro Am) on Gambatte, but I didn't connect the dots that Gambatte's test suite is also tuned to this expectation until now. So looks like I'm going to have to be more careful about how I use Gambatte's tests going forward. I had implicitly tuned GBHawk to the newer models since there were consistent results between AntonioND's tests and WilbertPol's tests. I have to make sure I don't bake in some contradictory behaviour by relying too heavily on Gambatte's test suite at the same time. I don't know what else besides this is effected. It can't be anything too major or there is no chance Men in Black or Pokemon TCG would have worked on console. It's worth noting though as it already cost me some time trying to sort out an inconsistency that is fundamentally caused by different models of console.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Still working on Gensan 2. I looked a little closer at the console replay, and it's actually desyncing at the end of level after the first boss, not on the second boss as I previously thought. This eliminates the window as the source of the desync, but that level has a lot of lag and sprites and it's hard to narrow down exactly where things are going wrong. I'll post another movie file when I have a minimum case of where console and emulator diverge. If I had to speculate it would be some edge case of mode 3 timing. The test roms only test xscroll up to 4 mod 8, so maybe we need 5,6 and 7 as well. Beyond that I'm not really sure what it could be. Changing anything too drastic causes immediately obvious desyncs, and I already checked for usage of uninitialized RAM and blocked VRAM accesses. I compared with video from my phone as best I could for a frame by frame analysis, and everything looks correct until the very end of the level, where a jump and attack happens slightly differently on console, allowing the level to end one frame earlier, which is what causes the later desync in the second boss. If I don't make any more progress I might need to set it aside and look for another game that desyncs but is a little more obvious what's going wrong.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
RetroEdit wrote:
So now GBHawk and Gambatte behave the same for this game? What does that mean for console-verification, I guess the run needs to be modified for the new emulation to see if it will verify on console, or are there still clear emulation problems that will prevent console-verification? Also, is the list of console-verified games publicly available anywhere? I'm aware it's possible to filter submission by which ones have the console-verified flag, but I'm not sure if you have something different.
They behave the same in this particular case. I have another test run that works correctly in GBHawk (compared to console) but not in Gambatte do to incorrect mode 3 emulation of sprites + xscroll in Gambatte. This particular run avoids that though, and both Gambatte and GBHawk agree here cycle for cycle, but the run desyncs on console. So, there is something unknown missing in both GBHawk and Gambatte. My speculation is mode 3 sprites + window timing, but have no way to test yet. It could also be an edge case of IRQ source selection. All the complete runs in GBHawk that I have either personally verified or match cycle - for - cycle to runs already verified in Gambatte are linked in the opening post. I have a few other console verified test runs but are incomplete. The list of Gambatte verified runs is longer, and can be found here: https://runs.tas.bot/runs.html I think it's still missing some recent ones like mega man though. Eventually I will catch up but I've been busy plus stuck with Gensan 2. I have personally verified the recent Men in Black TAS but I don't have a capture device so it's not officially verified.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I updated GBHawk's interrupt processing to pass all of gambatte's interrupt precedence tests (except HDMA ones.) This is also brings behavior on Gensan 2 inline with Gambatte. As always please let me know if this breaks anything. There is still a bit of room for error here as the test coverage isn't 100%. I tested against there console verified runs I have and everything seems to still work as expected. Curiously gambatte does not pass some of the hdma tests either. I haven't had a chance to look at what these tests were doing yet, but it's pretty interesting since some of them aren't even in double speed mode.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
For me, console verification is the most impressive part of TASing. So I thought I would make this thread to see what games (with or without existing TASes) people would most want to see a console verification of. Personally, I'm mostly interested in seeing new work on N64. This will probably need a new emulator, but I'm hopeful it might happen one day, and maybe there are still some games out there like SM64 and Mario Kart where verification is possible with Mupen. Anyway here are the games I most want to see console verified. N64: Goldeneye Perfect Dark Rogue Squadron Banjo Kazooie Ocarina of Time Diddy Kong Racing Body Harvest 1080 Snowboarding SNES: Mega Man X Super Mario RPG Donkey Kong Country 1/2 NES: Punch Out Done! Ninja Turtles GB/C: Oracle of Ages/Seasons Done! Shantae
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
There's been a lot of interesting stuff happening in N64 TASing recently, maybe some of those creators can give some commentary? Iknow WhiteTed has some cool Goldeneye stuff, and the recent SM64 120 star WIP post would be cool to have some commentary with it too. Also new improvements in Mario Kart 64.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I have fixed dual gameboy. You'll have to make new XML files though, the old style is incompatible with the new rom loader stuff.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Yeah the file I uploaded accidentally cut off the last couple of inputs. The console desync though happens around frame 12300. I think we need a sprites + window mode 3 test. The boss part of the screen is all window and I don't think we have a lot of details about timing in that situation. The game is checking for end of mode 3 each scanline. Not entirely sure this is it but at least need to rule it out.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
RetroEdit wrote:
Alyosha wrote:
Here is a file for gambatte (2.4.2) that desyncs on console on the second boss in a deterministic way.
Does that file sync in 2.5? Gambatte was updated in 2.5.
Not sure, I haven't gotten the chance to look at the new GBA BIOS stuff. EDIT: I hacked back in the fake GBA bios stuff and can confirm the run syncs on the current build of gambatte.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Gensan 2 continues to provide challenges for console verification. http://tasvideos.org/userfiles/info/66301728356726713 Here is a file for gambatte (2.4.2) that desyncs on console on the second boss in a deterministic way. I have confirmed a version in GBHawk matches this run cycle for cycle in the boss area. GBHawk has an IRQ priority issue that is fixed in my local build that made it desync in a different way, but once I fixed that it syncs to the end of the game just like Gambatte. So there is some un-implemented behaviour in both GBHawk and Gambatte that is causing desync on actual hardware. I didn't see any uninitialized RAM so I don't think that is the cause. Also in this run mode 3 timing does not seem to be the issue (at least to the extent testable.) Currently I don't have any idea why this desyncs.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Nice run, yes vote. It's good to see expert knowledge put into a TAS like this. A lot times I go into games like this with only superficial knowledge and inevitably miss things that I would only ever really know from time and experience. This TAS really shows the difference those things can make.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
NES games can also have issues with uninitialized RAM, it's not exceptionally rare. It is good to identify that problem though and ways to work around it for games that encounter it. Just having things written down in an organized way really helps.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
EZGames69 wrote:
What do you mean by this?
I mean LibTAS and the examples of games with built in TAS tools. Maybe not console verification in the usual sense but still a lot of progress compared to say genesis.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Making and re-syncing TASes can take a lot of time and effort, are there any thoughts on which specific games or TASes should be looked at that can most help console verification? GB and GBC have progressed a lot recently, and PC of course too, but not so much for other consoles, where should effort be focused?
Post subject: Console De-Verified
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I thought I would make a thread specifically for runs that failed to sync on console. There is a page with a lot of old tests here but a lot of those are too old to be relevant to modern development. Failed cases tend to find hardware edge cases not expected or covered by test ROMs, so keeping track of them seems like a helpful way to drive improvements to emulation and verification. More generally keeping track of what things can go wrong and why helps get a clearer picture of what path development needs to take. I expect a lot of older TASes to fail to sync just by virtue of being made on old inaccurate emulators, so I intend this thread mainly for new TASes made on accuracy focused emulators.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
ThunderAxe31 wrote:
I just found another graphical bug with GBHawk and SubGBHawk. The first 11 frames of the GBC BIOS sequence consist in a black screen. I can confirm this behavior is NOT present on any real console: GBC, GBA, GBI.
Fixed in master.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
PikachuMan wrote:
Super Bombliss DX crashes when trying to load game modes in GBHawk in version 2.5
thanks for the report, seems like a straightforward game so not sure what the problem is, I'll add it to the github tracker.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I find it fascinating how there was a hint of this all the way back in 2007 but it took over a decade of technological development to be able to arrive at the point where this TAS could be made. Jumping to the middle of the credits seems a bit strange, but if there isn't any way to tell the game is beaten besides seeing the end screen then good enough I guess, yes vote.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
GBHawk still applies inputs on VBlank boundaries, so you cannot save time simply by converting between it and gambatte, unless the game samples inputs while the screen is off, which this game doesn't do. My guess is you just found some places where I didn't press input on exactly the right frame, like in the 2nd K .Rool fight where I am indeed 3 frames late. However trying to save after truncating my movie file when fixing this also corrupted my TASproj, seems like something bad is going on with TAStudio. EDIT: yeah i missed a few presses, here is a corrected file. http://tasvideos.org/userfiles/info/65880395759689215 I'll probably take another look and see if I missed any other small things.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I (mostly) fixed 4 in a Row. This was actually a very difficult case. Just figuring out what the ROM format was took a lot more googling I expected (it's something called 'XROM' apparently, and only in 2 games.) After accounting for that there were several small bugs that needed fixing that slid under the radar until now. There is still a problem that a counter interrupt is happening one scanline too late, but that kind of thing could take forever to properly sort out and I currently don't have the time. So for now it will have to be good enough, at least it's playable.