 |
A test FM with video that demos the problem is available. PM me for a link |
|
|
Confirmed that the Movie Theatre method exhibits the same bug. |
 |
As a matter of fact, mp4 videos allow to play sound from video file. It stays in sync with video no matter what, but since video plays slower without uncapped FPS, audio briefly pauses every so often, so it is still bad. |
|
|
Unfortunate that it is still bad. Is the method to play sound from the mp4 video something a mapper could currently do outside of briefings (in 2.10 or 2.11)? If so, please point me to details, so I can update [[Full-Screen_Video_Cutscenes]] to include it... even with the sync loss problem. Thanks. |
|
|
I don't know. I think there is no artificial barrier for playing sound from video file during gameplay. To be honest, I don't know how to fix this issue in a way that would work during gameplay too. Aside from returning to old-style modelling with guaranteed micro-stutter every 1.5 seconds regardless of mission size. |
|
|
If no artificial barrier, then I'll experiment at some point. But not this month... I'm trying to complete a major wiki series. Always depressing when no fix can be seen. I wonder if there's some capped fps where the slowdown doesn't happen. Maybe it would be a fractional fps (59.94, 29.97, 23.976... the usual 1000/1001 ratio with respect to an integer fps). If so, the ability for the user to easily select a fractional fps would be useful. |
 |
This probably won't be a popular suggestion but we could just force uncapped behavior with max_fps 60 whenever a video is playing ? At least it should be good enough to get 2.11 out with something resembling the intended functionality. |
|
|
Sure. That idea may be most problematic for video playing on a small surface, but maybe that doesn't occur all that much. |
|
|
No, I definitely don't like the idea. Deterministic fixed-step tics is the only benefit of the capped mode. Introducing hacks for disabling it is a road to nowhere. |
|
|
I went back to a very old TDM version ( 1.07 ) and noticed that the bad FPS behavior in Linux with capped FPS has been with us since before going standalone. One thing I found that dramatically improved the behavior was disabling "precise tic" ( com_preciseTic 0 ). I tried testing this in 2.11 and the game froze. Most of the code for this looks unchanged from Doom 3 vanilla so I am guessing something else in the timer infrastructure broke this? |
|
|
Yes, of course it is broken: all those "uncapped FPS" changes broke it. Anyway, as far as I see, it just issues the tick every time timer calls async function. So it would break time synchronization even harder than the current code does. |
|
|
I reverted the fix from 0004514 in svn rev 10746. So now GUI + game time goes with the same speed as the sound time. No sound stutters when playing sound from video file, no problem with sound playing slower if it is run independently. Unfortunately, most of the code treats time as integer number of milliseconds. So if we want to keep time step constant, it can be either 16 ms or 17 ms. Neither of which is synced to Vsync, so the double-frames are inevitable. The previous "solution" was to have game frame at 16 ms but run it every 16.65 ms, which introduces this difference between video and sound. Given that now default mode is "uncapped FPS + Vsync on", I don't think lack of smoothness in this legacy mode is a problem. Keeping strictly fixed timestep is more important --- that's the only reason we maintain this mode... |
- Anonymous
