corrected CL_ScaledMilliseconds when using mme_blueFrames

[em92]

pardon, mme_blurFrames Example, when CL_ScaledMilliseconds does NOT consider mme_blurFrames: https://www.youtube.com/watch?v=hsM_6zJXeDY (see team scores and "I have a flag" icon at 0:00)

This commit fixes it

[brugal]

It looks like the problem is in tr_backend.c RB_SetGL2D() ...

    ...  
    // set time for 2D shaders
    backEnd.refdef.time = ri.Milliseconds();
    backEnd.refdef.floatTime = backEnd.refdef.time * 0.001f;

The problem can happen for other reasons besides blurframes. It will be triggered by anything (hardware, high render fps, etc..) that will slow down video recording. One possible fix is to store a base time when video recording starts and then from CL_ScaledMilliseconds() return that plus a total of the fake video time offsets generated in CL_Frame().

[em92]

CL_Frame plays scene using timescale, that has value com_timescale divided by mme_blurFrames (assuming mme_blurFrames > 0).

CL_ScaledMillisecords returns time with timescale with value com_timescale. Without mme_blurFrames. This generates inconsistency of different timescales.

"Fast blinking" is the problem that shaderTime uses backEnd.refdef.floatTime, which is equal to ri.Milliseconds() * 0.001f

The problem can happen for other reasons besides blurframes. It will be triggered by anything (hardware, high render fps, etc..) that will slow down video recording.

Slow video recording is not an issue of this PR.

[em92]

Btw, I call "fast blinking" that appearance from mentioned video. And this inconsistency generates fast blinking. Without using mme_blurFrames, there is no fast blinking.

[brugal]

Thanks. Going to change CL_ScaledMilliseconds() so it just returns cls.realtime which already factors everything in.