Posts for Alyosha


Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I tried improving my Gensan 2 run before submitting it but when I did I ran into another desync on console. This game sure is working out the bugs in GBHawk. This one though only took a few minutes to track down (at this point there really aren't many things left that can be changed that it could be.) The problem was in the timing of clearing interrupt flags. There's still a little room for variation in the setup I have now, but this case reduces the uncertainty down to 1 cycle. Actually the above was wrong, the real solution is that when clearing an IRQ flag at the same time it is set in GBA mode sets it instead of clears it. This test: tc00_irq_late_retrigger_2_dmg08_outE4_cgb04c_outE0.gbc gives E4 on GBA. Before I was using the GBC04 behaviour of getting E0, which is evidently wrong at least for GBA (and likely GBC E.) I'll still need to look over other tests to see if this breaks anything else before committing anything. Looks like Gensan 2 will wait for yet another BizHawk release.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
So I think the problem with Mortal Kombat is just input resolution of GBI. On the ladder screen, the game is just spamming checks to the control register. If I change the offset built into the input script by 1 incrament, with equates to 1024 cycles at 4MHz, then Mortal Kombat syncs just fine. This also explains why TAS input syncs just fine, since I was pressing start on the ladder on the first available frame, the input was already there before the spamming started. For now I'm not going to change the script, since I'm not entirely sure what the correct fix is (it could be only off ~200 cycles and still break the sync), but it's something I'll keep in mind.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
My goodness does this ever look like an optimization nightmare. The other run is too long for me, but 15 minutes is short enough to enjoy the level of complexity here and the thought that went into it without getting too bored. Good job, yes vote.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I think it's also worth pointing out here that over the past couple of years, several of the examples of running GB games in GBC mode and making TASes of them, with the goal of console verification, has directly lead to significant advancement in emulation accuracy. Its been good for the site, good for the pokemon people, good for emulator devs. , and really helped advance the state of the art.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I don't really find this run to be that interesting,still impressive you were able to improve the existing one though, nice work.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
feos wrote:
Can you elaborate why your run is slower there?
No idea, that's already way more effort then I put into comparing the runs. I'll try looking into it. EDIT: http://tasvideos.org/userfiles/info/66919700439251260 Here's a new file, ~120 frames faster. Notes: 15:11.067 - fixed 18:43.767 - don't know why boss is slower, I don't know of any way to manipulate it 23:55.233 - don't know, mine cart levels are too fragile. 38:40.067 - mostly fixed, looks like some lag differences still 40:17.033 - can't fix without input file, I don't get the jumps, despite trying many times 43:47.167 - Slightly improved, but it seems like the bird section is much faster, not sure how or why, maybe less lag. 47:01.267 - don't know, Once again not sure how to manipulate a faster boss 50:40.367 - mostly fixed I think 51:52.500 - mostly fixed, but still slower, an enemy doesn't have a hitbox so I miss a boost 54:10.333 - no idea how to manipulate anything faster. I should note that in all my different files and all the revisions I've done, boss patterns have never changed beyond 1-2 frames, and even that is probably mostly frame timing differences. I have no idea why the boss fights are slower, or for that matter why the bee fight is faster. If I'm missing something I surely don't know what it is.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I tried your suggestion, but it seemed like I always ended up losing any frames I gained somewhere else. I did go back and save some lag on level 4 though, it added up to quite a bit. Please replace the movie file with this one: http://tasvideos.org/userfiles/info/66897177042784615 EDIT: I tried making a console verification video of this version, kind of shaky but not too bad. Link to video
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
EZGames69 wrote:
Was this tested on console? If so, I'd like to see the video of it.
Yes I played it back on my GBP. I don't have a capture device though, the best I could do is a poor quality cell phone video.
DJ Incendration wrote:
How is this 150 frames faster? Wasn't the previous movie a 3:41?
The previous run did not include BIOS (that's 190 frames.) Also time in VBA movies was not calculated accurately due to the way it processed loading times when the screen was off. There are ~100 extra lag frames from loading time being counted correctly in the new movie.
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/66828727632451057 Here is a resync and minor improvement of this game. It is console verified. I saved a few frames in a few spots, but the last boss will need to be redone probably. I wanted to try this game because it had a lot of interesting graphical elements to test GBHawk with. Also it is very short, a perfect combo for testing. I'll have to put a bit more work into this before it's submittable, but it's a start. EDIT: WIP 2, about 150 frames saved. Better movement in levels 1 and 2 saved the most time. Boss 1 was slightly improved. http://tasvideos.org/userfiles/info/66858681884594734
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
The test speed_change_cancel.gbc expects a speed change (which uses STOP) to be exited if a button is pressed even though joypad interrupts are not set in register FFFF. Maybe this is only for speed change, but not sure. There is also another test called joy_interrupt.gbc that the notes say behaves differently on GBA SP from GBC/GB. At any rate I have tried a resynced version of this run on GBP and it doesn't work, so seems like knowledge is incomplete here.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
It sounds like you are encountering an instance of the NES DMC DMA bug. In Ninja Gaiden one this bug is dealt with by ignoring the input on the frame it occurs and using the input from the previous frame, I haven't looked at the code for 2, but if it's the same it will look like your input is lost for a frame even though it's not lag. This is emulated in NESHawk but not FCEUX.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
It would be nice to dump some save RAM and see what actually ends up there. I tried with some games I have (mostly MBC3) and it looks like alternating blocks of FFFFFFFFF00000000 with a whole lot of junk randomly scattered about. MBC1 looked like large blocks of FFFFFFFFFFFFFFF alternating with other junk. Not sure how representative any of this is. I don't have Link's Awakening. Probably all FF isn't too unrealistic, but anyway this is another cool demonstration of how strong save corruption is when you can reset at exactly the time you want.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
It's not like we're stuck with vague guessing, there is a run on the workbench right now that I specifically mentioned is in GB mode because of annoying sprite errors in GBC mode. Those stray lines and Dixie's messed up sprite are a result of GBC variations. If you look here you can see the details of one sound hardware change that breaks a game in older model GBCs, look in obscure behaviour: https://gbdev.gg8.se/wiki/articles/Gameboy_sound_hardware There are many variations in GBC from GB, and many variations amongst different models and from GBA, even just the fact that the GBC BIOS takes less time to run dramatically changes RNG in games that don't reset the timer (ex pokemon) all other things being equal.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Made a lot of improvements to window + sprite timing and made a bunch of new tests. Everything actually worked out pretty cleanly. The cases around 0 weren't really that bad, although I have a few more left for complete coverage. I'll be putting all the tests I put together here: https://github.com/alyosha-tas/Misc.-GB-Tests This does not seem to have fixed Mortal Kombat though. I think I'll have to look closer at the serial port.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I think that rule can just be removed. I don't see any benefit to forcing people to play in black and white when an official hardware that supports colorization is available. Even the default red and green palettes in GBC markedly improve the visual clarity in most games. Things aren't exactly the same, but close enough. GBA isn't really the same as GBC either, oh well, hardware is messy and their are lots of revisions. The easy console verification pipeline makes that worth it too.
Nach wrote:
Why are you saying this? My understanding from Sinamas was that he runs his hardware tests on both a DMG and a CGB.
Also some of those tests aren't even compatible with all CGB revisions. It's too bad really, things would be so much easier if there were less revisions.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I recently got a development cart to run hardware tests with. The first thing I did was run lycint152_ly153_3_dmg08_cgb04c_out00.gbc and I can confirm it gives 99 on a GBP instead of zero. I'll be working on window + sprite timing tests now. I'll post them when I have ones that work on GBP. Hopefully this will solve Mortal Kombat and be the last major piece of the single speed puzzle. EDIT: Here is the first test which already revealed an error in GBHawk. It also doesn't work in Gambatte but fails in a weird way, I don't really get it. It worked on GBP. This is the simplest case of a window mid screen and sprites in that region are sufficiently spread out to avoid overlap. It failed in GBHawk because sprites were being evaluated according to the pre-window offsets when window and sprite started on the same pixel. Fixing this actually made the rendering code more symmetric in terms of when different things were getting evaluated, so it is an accuracy fix and a good clean up too. https://www.dropbox.com/s/f8sdl76ew8u37qr/intr_2_mode0_timing_sprites_win26_nops.gb?dl=0 There are a lot more tests to go. I'll do a few more of the basic case, then a bunch with overlapping sprites, then one test for each window value 0-7 where I expect weird stuff might happen.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Nice work, I'm really surprised how often checksum collision leads to a useful result. I guess it's only because the checksum value is so small, but it's still cool to see.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
It's really surprising to me how much shorter this is then the other Crystal movie, despite all the extra travel. Nice work.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
My time is really constrained now and I can't really focus on multiple things, so I'm thinking of setting Odyssey 2 to released soon and calling it a day, even if there are a couple left over bugs. At least then people can use it for 2.5.3 with nearly all games compatible. If anyone has a bug that is actively preventing them from actually making a TAS, let me know and I'll try to fix it. Other then that I probably won't return to this.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
RetroEdit wrote:
This doesn't appear to be filed on Gambatte-Speedrun's issue tracker. I'm sure they would appreciate it if you filed the issue.
I think CasualPokePlayer could do that if he wanted one. I looked over what Mortal Kombat was doing and noticed a pretty serious error in how I was dealing with sprites + window. Turns out I was not resetting the alignment for sprite evaluation when the window was activated. Obviously this would yield incorrect results for mode 3 timing. When I fixed this oversight, Mortal Kombat synced fine. This error has been present since almost the inception of GBHawk. Sprites interact with the window rarely enough that this simply didn't come up often enough to notice. I only did the basic case though, that is when sprites are comfortably in the middle of the window. Edge cases where sprites span across the edge where the window is activated or around x=0 are not accounted for at all, and certainly need their own comprehensive test ROMs to do correctly. What I have currently is enough for Mortal Kombat though. I'll do a few more tests with Mortal Kombat, then I'll try to find another game that does some non-standard stuff and see what comes up. If things work out it might be time to move to double speed mode finally. EDIT: Nope, Mortal Kombat is still broken, the run I made just got lucky, looks like it's time to make some window+ sprites tests.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Cool, thanks for your help. Fix committed! I'm glad despite this being a pretty obvious oversight that it led to something useful. Overall Gensan 2 helped improve GBHawk pretty substantially, and even helped gameboy emulation in general a little bit I guess. I'll defnitely be submitting a run of it next release. Now I can move on confidently to Mortal Kombat. My preliminary guess on that game is that there is a sprite + window timing issue somewhere. Hopefully it takes me less time to find then this one. I've also been cleaning up window emulation in general a bit. There are a lot more behaviours you can do with the window then I expected, and GBHawk isn't really built to handle all of them, but some of the more important issues for games at least are getting resolved.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Awesome, thanks for testing. Looks like I was almost right. Based on those results, it looks like the penalty doesn't go away completely, it just gets capped at 5. I just checked and this is indeed still enough to fix Gensan 2, so looks like this is definitely the solution. I'll make new versions of tests 6 and 7 later today that should actually work on console. In hindsight this should have been obvious, the normal penalty for non zero sprites goes 5,4,3,2,1,0,0,0. So, it makes sense that this one should go 0,1,2,3,4,5,5,5 and not 0,1,2,3,4,5,6,7 that I currently have implemented. That's what I get for extrapolating beyond the available data without thinking it through. At least the fix is super easy. Hopefully this can get fixed in Gambatte too, it's one of the only really obvious flaws it has. This is not some rare edge case so it probably impacts other games too. EDIT: Here are revised tests for scx6 and scx7 that i believe should work on console. https://www.dropbox.com/s/l9hfqvfn39vqmyc/intr_2_mode0_timing_sprites_scx6_nops.gb?dl=0 https://www.dropbox.com/s/4yvtv675szu9vpu/intr_2_mode0_timing_sprites_scx7_nops.gb?dl=0
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
scx = 5: https://www.dropbox.com/s/w4twsy5g6m0qphv/intr_2_mode0_timing_sprites_scx5_nops.gb?dl=0 scx = 6: https://www.dropbox.com/s/4vtnpa23wwegfk6/intr_2_mode0_timing_sprites_scx6_nops.gb?dl=0 scx = 7: https://www.dropbox.com/s/v1xvvym9kztazpg/intr_2_mode0_timing_sprites_scx7_nops.gb?dl=0 I think scx = 5 should pass on console. If what I'm thinking is correct, 6 and 7 should fail on console. All 3 pass on GBHawk and Sameboy currently. Gambatte does not pass any of the scroll tests, not sure why. Assuming 6 and 7 fail, I will make proper versions that pass. If they also pass on console in their current form, well then I'm pretty stumped.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I believe I finally figured out Gensan 2. There is a penalty when evaluating sprites at position 0 with non-zero x-scroll. I have previously added this penalty for all values of x-scroll, as this was consistent with existing tests of x-scroll up to values of 4 mod 8. However, the tile fetcher is only active for 6 cycles, so i speculated that maybe this penalty should not be added for x-scroll values 6 and 7. If I implement this, then I do indeed get the same de-sync as Gensan 2 as on console, and without any de-syncs in other console verified runs. When I adjust the run of gensan 2 to include this case, it syncs to the end of the game on console as well. I think this is highly likely to be correct, there isn't much else it could be to de-sync in this exact way, but to make sure I manually edited the existing sprite + scroll tests to use cases 6 and 7 and will get some dev carts to test on console to verify. Hopefully this will bring this case to a close and i can move on.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Nice TAS, I like the gameplay of the Gargoyle's Quest games, it's good in a TAS too.