Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Cioss wrote:
Can anyone help, It's a pain to have to wait constantly beczuse I made a mistake or because I have to check if it works. And turbo seek doesn't help either. Before, it didn't do that and it simply didn't seek at all only when going backwards.
I have also had this problem, but unfortunately I can't reproduce it consistently, so I haven't been able to figure out a fix.
As a workaround, whenever this is happening to you, reset the greenzone by adding and then removing a random input at the start of the movie. Then once the movie plays back up to where you want it to it should work fine from there.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Game: Warioland II (USA) (GB Version)
Emulator: BizHawk: Gambatte (but also behaves similarly in GBHawk) in GBA mode
Console Verification Device: Gameboy Player with GBI
Movie:http://tasvideos.org/userfiles/info/67631410422598803
Description of Desync: On emulator, player character beats the level using out of bounds at ~ frame 50000. On console, there is a desync in the out of bounds section and the level does not complete.
Research: This is a case of trying to read VRAM on the same cycle it is released by the ppu. This is not emulated correctly and currently the details are not known.
Possible Next Steps: This needs an exhaustive test ROM.
Status: Open. The current work around is to simply avoid the glitch, which is cycle exact so is easy to avoid with irrelevant button presses
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Link to video
I had some time so I did the console verification today.
I only recorded around the time where the old one desynced.
It synced all the way to the end though, so looks like simply avoiding the VRAM glitch is the best approach for now.
I played it in dev build and it looks fine to me. I'll try to console verify it in the next couple of days (I'll try to capture video of the last couple of minutes.) The glitch is cycle exact, so if the game takes a few extra cycles to process a button press it can change alignment and you won't encounter it.
__________________________________
I've also been making progress on double speed mode. The timing of the speed change seems right now (some of the existing tests play out differently on different revisions, so it took e quite a while to work out what is supposed to be happening and why.) Mode 3 timing tests seem to all pass as expected, so no major surprises there. LYC seems to behave differently, almost like the logic gets clocked twice as fast in double speed, but several LYC behaviours are also revision specific and this also passes all the tests so I'm going with it.
I think the only obstacle at this point is HDMA timing. This is what is currently keeping Men In Black the Series from syncing correctly.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
I recently fixed a couple bugs in movie recording where it was possible to record inputs to the movie file while not sending them to the core.
If anyone is able to test the dev build and make sure I didn't introduce any other issues accidentally at the same time I would very much appreciate it.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
phoenix1291 wrote:
Alyosha wrote:
phoenix1291 wrote:
Did I miss something, I don't think it's possible to launch Ninja Spirit Game Boy on GBHawk or Gambatte?
Oops I missed this comment. What kind of error are you getting? What is the hash you have for the game? Ninja Spirit looks like a standard game it would be very unusual for it to fail in both cores.
The game just doesn't start for me, I don't have any specific errors.
I didn't check if there was something specific in the log window.
Try in Gambatte but with 'use official bios' false in the settings. If it works then you probably have a bad ROM and it's failing the logo check in the real bios.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
If you want to see the gameboy screen in Gambatte, you have to go to GB->settings->enable official nintendo bios and set it to true. Then reboot the core. Then you can start recording a new movie and the bios screen will show up.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Movie file 2 only starts from SRAM. It does not know what the internal state of the clock should be.
Try using the 'From Now' setting when starting recording for movie 2 instead.
The RTC is only an internal state to Gambatte, it doesn't actually use any real world RTC (not in BizHawk anyway by default), so whenever you reset the emulator core, the state is lost.
I believe older versions had an option to use real world RTC, but not sure how reliable it was. EDIT: actually the setting is still in Gambatte, try setting Realtime RTC to true, not sure it actually works though.
EDIT: also just so you know, if you want console accuracy you have to record movies using the official BIOS (you can enable it in the settings), the homebrew ones used by default will not result in console accurate RNG, and are for casual play only.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Part 1 ends at 4:10-4:11 AM Monday for me, seems correct.
Part 2 appears broken, it loads from SRAM and immediately desyncs.
No idea how you are obtaining the results you describe, I can only recommend grabbing a fresh version of 2.5.2 and trying again (and when doing so do not use any old files, start fresh exactly as it is in the zip file.)
EDIT: part 3 says it's wednesday 7:59 am
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
phoenix1291 wrote:
Did I miss something, I don't think it's possible to launch Ninja Spirit Game Boy on GBHawk or Gambatte?
Oops I missed this comment. What kind of error are you getting? What is the hash you have for the game? Ninja Spirit looks like a standard game it would be very unusual for it to fail in both cores.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
It keeps track of RTC one cycle at a time. Seems to be working fine to me (I just tested 2.5.2 and master.)
If you can upload a movie where things are getting messed up I can take a look at it.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Not detectable with LUA.
In the dev build now, any time you encounter the glitch it will show up as "VRAM Glitch" followed by a bunch of number in the console log.
I was able to avoid the glitch in the room where it desynced on console and made it to the next level:
http://tasvideos.org/userfiles/info/67272359711138584
Unfortunately I got stuck there and wasn't able to easily fix it from there, but I don't actually know what I'm doing with that OOB stuff so maybe you can do it easily.
The glitch still happens in the early parts of the run, but that's already verified to work right on console so no problem there, just be aware that in any other parts of the run that you see that message pop up, there is no guarantee it is being emulated correctly (I'm pretty confident the timing is correct, just not the results.)
Also remember to set 'Read Domains on VBLank' to true so your script works.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
jlun2 wrote:
While I do not understand the glitch, the fact you managed to resync the run up to that in 3 days is incredibly motivating. Thanks a lot for the work and good luck!
Resyncing only took about an hour, but unfortunately I also don't understand the glitch, so I can't really go any further right now. I could make the dev build output a message whenever you encounter the glitch (if you wanted to continue in GBHawk), and can therefore simply avoid it, but that's the best I could do at the moment.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
I made a modification to the vram_reads_eol test ROM by changing the byte written to the upper part of VRAM to CC instead of 33. This was the only change I made to the ROM.
The results from my GBP are much different then expected. No 00 for the first read, not sure where 22 comes from exactly.
I think this is something that needs a comprehensive, and possibly even interactive, test ROM to get the full details of what is happening.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Oh cool another de-sync, looks like maybe another bad VRAM access? Maybe we can learn some more about this glitch. Hopefully I can look into this weekend. Thanks for letting me know.
EDIT: After resyncing the run to GBHawk and getting back up to that point, it's definitely the end of line VRAM glitch.
It was pretty easy to get a similar desync after I upgraded GBHawk's emulation of the glitch, but I didn't get the exact same thing.
It looks like the critical details are in emulating the glitch correctly when the PPU is doing the first accesses for a a tile. When doing this it accesses 2 regions of VRAM at once. The returned value in this case is what we need to find.
I made some modified versions of the existing test to see if I could narrow things down at all, but it was just more confusing. I'll look at it in more detail this weekend when I have more time to sit down and think about it.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
I'm pretty confident in single speed mode at this point. There are some edge cases to clean up still but it's time to start looking ahead to double speed mode.
In preparation for that I re-synced the run of Spirou Robot Invasion to the latest dev build. To my surprise it worked on console:
http://tasvideos.org/userfiles/info/66989349617966603
The run contains some adjustments, there have been a great number of emulation changes since it was first made, but it's still almost entirely faithful to the original.
This gives me another run to check against along side pokemon TCG when I start working seriously on double speed mode pretty soon.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
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.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
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.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
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.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
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.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
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.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
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
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
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.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
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
I made a modification to the vram_reads_eol test ROM by changing the byte written to the upper part of VRAM to CC instead of 33. This was the only change I made to the ROM.
The results from my GBP are much different then expected. No 00 for the first read, not sure where 22 comes from exactly.
I think this is something that needs a comprehensive, and possibly even interactive, test ROM to get the full details of what is happening.