search

TASEmulators / BizHawk

BizHawk is a multi-system emulator written in C#. BizHawk provides nice features for casual gamers such as full screen, and joypad support in addition to full rerecording and debugging tools for all system cores.
http://tasvideos.org/BizHawk.html
Other
2.14k stars 380 forks source link

Consider switching default throttling method to Audio Throttle #3562

Open CasualPokePlayer opened 1 year ago

CasualPokePlayer commented 1 year ago

Additional ideas

Keep Clock Throttle default for TAS profile Perhaps do per core default for throttling? (not sure how this would be cleanly implemented) Maybe enable VSync by default too? (frame pacing is noticably worse with Audio Throttle, VSync seems to mitigate it however?)

Morilli commented 1 year ago

Random thought about Perhaps do per core default for throttling?: For examples the subbsnes core only performs well with audio throttling, not with clock throttle, as "frames" in bizhawk can be variable length.

Spikestuff commented 1 year ago

Better for atypical user end, and speedrunners actually use Audio Throttle. For TASing/Dumping there might be questions where the answer is "switch to Clock".

CasualPokePlayer commented 1 year ago

@Spikestuff "speedrunners" more only applies to your area with PSX, due to most of the time games will be running at a non-interlaced framerate, and clock throttle always throttles according to the interlaced framerate, causing a minor discrepancy.

For TASing/Dumping there might be questions where the answer is "switch to Clock"

https://github.com/TASEmulators/BizHawk/blob/67466be2f449cf4c4de2f6886653809611ab5083/src/BizHawk.Client.EmuHawk/MainForm.cs#L2745

Random thought about Perhaps do per core default for throttling?: For examples the subbsnes core only performs well with audio throttling, not with clock throttle, as "frames" in bizhawk can be variable length.

The main trouble cores would be GB/C with Gambatte or SameBoy (variable frame length), PSX with both Shocks due to multiple framerates possible (possibly could be fixed otherwise by dynamically changing Vsync* props but hawk itself will need changes to account for that being possible e.g. A/V dumper splits), and mupen64plus which doesn't properly have a/v sync internally, forcing hawk's a/v sync to do work recovering what it (audio throttle producing best results here). Might also help cases where the framerate is just some approximate guess at e.g. 50/60 FPS but the core actually runs at a slightly different framerate.

(edit: ignore issue close, curse mobile GitHub design)