TASVideos

Posted: 10/21/2020 5:01 PM
(Edited: 10/21/2020 6:55 PM)

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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

Posted: 10/20/2020 6:07 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 10/18/2020 3:16 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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

Posted: 10/18/2020 1:24 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 10/17/2020 1:37 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 10/17/2020 1:34 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 10/15/2020 10:15 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 10/14/2020 10:07 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 10/14/2020 1:04 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 10/12/2020 5:32 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 10/12/2020 5:21 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 10/9/2020 9:25 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 10/9/2020 9:22 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 10/6/2020 4:03 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 10/5/2020 8:37 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 10/5/2020 1:47 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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

Posted: 10/5/2020 2:26 AM
(Edited: 10/5/2020 5:36 PM)

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 10/4/2020 11:08 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 10/2/2020 1:13 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
Location: US

Nice TAS, I like the gameplay of the Gargoyle's Quest games, it's good in a TAS too.

Posted: 10/2/2020 1:06 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 10/1/2020 5:55 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 9/30/2020 7:19 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 9/30/2020 6:17 PM
(Edited: 10/5/2020 8:40 PM)

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 9/30/2020 6:11 PM
(Edited: 10/5/2020 8:44 PM)

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.

Posted: 9/29/2020 4:23 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3602)

Joined: 11/30/2014
Posts: 2752
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.