New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[GB/C] Make Equal Lenght Frames default to False #1176
Comments
This is more consistent for TASing, but for encoding it can/will result in audio glitches. Coincidentally Barbie Game Girl in the Queue right now is one such example. |
Indeed, the whole reason the original default for the Gambatte was not equal length frames is because if you're forced to frames (instead of using a proper input-at-any-time paradigm), you want those frames to line up as best as possible to when typical games typically poll. Then a bunch of people who had no idea what they were talking about barged into the issue and forced the stupidity that we're stuck with now. That being said, the video dumping problem is solvable in another way. @alyosha-tas are you using "alternate sync" when video dumping? It's far superior and should be used 99-100% of the time. |
Well I just tried video dumping now and BizHawk crashed with an unhandled exception. Happens in 2.2.1 as well, so looks like something is messed up on my computer somehow, guess I'll have to fix that first. EDIT: well I used CodecTweakTool and disabled and re-enabled codecs and that fixed it by magic so whatever. |
Ok I did a bit of testing. For the two cases I know of, Barbie Game Girl and Kirby's Dreamland, whether or not EqualLengthFrames is set doesn't make a big difference in terms of sound quality. This is because that setting primarily impacts frames that are way too short. Those two games have frames that are way too long, and Gambatte already seems to adjust for them internally. Does anyone have any other examples where this setting makes a difference for encode quality? If not, then setting this to false seems to be the better choice. |
Many N64 games benefit quite a bit from alternate sync, as the N64 sound output is a mess. Let's flip it around though: Is there any one situation where alternate sync=false produces better results? |
I always have 'Alternative Sync' checked. I don't even know what it does honestly. How does it interact with the gameboy setting of 'Equal Length Frames'? |
Video dumping always creates a constant framerate output, with framerate equal to the emulation core's target framerate as specified in corecomm or wherever that prop is now. With regular sync, the emulator's video output is assumed to be authoritative; there is exactly one video frame in the output for each FrameAdvance() call. The audio is then stretched or squashed on a frame by frame basis to fit. With alternate sync, the emulator's audio output is assumed to be authoritative. All of the audio samples generated by FrameAdvance() are placed in the output file with no alterations. Video frames are duplicated or dropped as needed to fit. Practically speaking, on well behaved cores, there is almost never a frame duplication or drop, and studders in the audio are more noticable. On cores like GB with equal length frames off, there can be large differences in framerate but they're concentrated around times when the LCD display is turning on or off, so missing one frame is not a huge deal. |
Sorry I kind of forgot about this. So is there concensus that 'Equal Length Frames' in the Gambatte sync settings should default to off? Seems like a good idea to me. |
I've noticed that some games, if played with Equal Lenght Frame set to True and GBC BIOS, will sometimes generate some lag frames. From what I can tell, the BIOS boot does cause some sync changes that result in the emulation skipping some input polls. However, if you set Equal Lenght Frames to False, this problem does not occur. A game in which I noticed this is GBC Survival Kids.
Many people are not aware of this, so I think that Equal Lenght Frames should be made default to False, since it's more appropriate for TASing.
The text was updated successfully, but these errors were encountered: