-
Notifications
You must be signed in to change notification settings - Fork 2
Description
I've been meaning to figure this out and FINALLY release st2, without it users wouldn't know what framerate to set in libtas (which now controls internal framerate of pcem), but I never got to the bottom of it and I don't seem to ever have time on this :(
We know that at least in DOS, applications set framerate according to viedo mode they want to run it, along with resolution. But while resolution doesn't need any logging since it's automatically picked by libtas, internal framerate changes can't be automated like this unless we manually change it in libtas... to something correct.
Don't know about Windows resolutions and framerates, maybe monitor refresh rate set in the OS handles this, and games are just meant to use vsync. But when vsync is off, is there even a way to set refresh to something that matches the game? Sounds problematic.
In jpc-rr I did this by writing current FPS into dump file (which is a custom thing different from video itself, tho it contains video), and maybe some variables may indicate which DOS internals are involved, but I have no idea how easy it would be to translate that into PCem, which is probably much lower level.
So whoever gets around doing this, we just need PCem to print to console numerator and denominator of the framerate that was just set by the application it's running. That way users would be able to either perfectly match framerate for every segment where it changes, or at the very least they'd be able to set it to in-game framerate at all times and stop caring about it for the rest of the movie.
Farthest I got was different GPUs incrementing
Line 98 in eb216b4
| int frames, fps; |
and then that value being used in
Line 1560 in eb216b4
| sprintf(temps, "SVGA refresh rate : %i Hz\n\n", svga->frames); |
but that's it... And even that is not num/denom kinda fraction that we need, so the real values are stored somewhere deeper.