CPR sync typically degrades to half FPS

[vxgmichel]

Mentioned here: #23 (comment)

And thinking about the half-fps condition you write about, that will cause an "always on" or "always off" for "faded" / shadow animations? I see them more now through emulation than ever, original gameboy zelda dog, original pokemon prize shop, and in this zelda link-in-bubble animation. I wonder if it should be another fraction like maybe 2/3 or 5/7?

I'm sure the blitter could also perform a bit of "fading", like, if every single frame was just a calculated average between the previous and next frame, and we display 1 frame behind. Could be an option, but it would cause a static "shadow" animation to basically freeze, there is a test in https://github.com/pinobatch/240p-test-mini rom image, "shadow test" to experiment with it. It would be a nice runtime feature, I would accept -1 frame to avoid an epilepsy warning.

Also for more context:
https://zladx.github.io/posts/links-awakening-partial-translucency

Neither the GB or the GBC have half-transparent rendering – but they have the latency of the LCD screen. So the good old 50% transparency trick is used: displaying the portrait only every other frame.

There are two different issues here:

At 60 FPS, the sprite appears blinking rather than transparent

I wonder what other emulators typically do about this, maybe something similar to the averaging between frames that @jquast mentioned? This would require an investigation.

At 30 FPS, the sprite appears either solid or absent

If gambaterm starts showing only every other frame (typically due to the CPR sync being consistently late), the "transparent" blinking sprites would be either fully solid, or fully absent.

In my opinion, this shouldn't be much of a problem if the degrading to half FPS occur sporadically, as it should (typically during screen transitions).

If it occurs consistently, it can come from two different things:

• Either the terminal itself is slow and does not support the 60 FPS video load most of the time. In this case the CPR sync works as expected, and the problem could be fixed with the averaging mentioned above.
• Or, gambaterm is served though SSH or something else, and a consistent latency is added by the network. In this case I think we can definitely improve CPR sync since there is no reason to degrade to 30 FPS: the terminal do support 60 FPS, but the frames simply arrive a bit late. A good solution in this case would be to accept a couple of frames of delay. This can be easily achieved counting the number of CPR that are currently unacknowledged. Once this number is too high (e.g more than a configurable parameter, defaulting to 3), then we skip sending frames until a CPR response is received.