You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
pcem/src/vid_svga.h
Line 98 in eb216b4
and then that value being used in
pcem/src/vid_svga.c
Line 1560 in eb216b4
but that's it... And even that is not num/denom kinda fraction that we need, so the real values are stored somewhere deeper.
The text was updated successfully, but these errors were encountered: