Skip to content
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

Report changes in framerate #18

Open
vadosnaprimer opened this issue Mar 8, 2025 · 0 comments
Open

Report changes in framerate #18

vadosnaprimer opened this issue Mar 8, 2025 · 0 comments

Comments

@vadosnaprimer
Copy link

vadosnaprimer commented Mar 8, 2025

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

int frames, fps;

and then that value being used in
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.

vadosnaprimer added a commit that referenced this issue Mar 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant