[ZScript] The problem with MSTime

[Serious_MOod]

Hello everybody. I have a wad in which there is a code for ZScript. The problem is that it worked correctly in versions 3.0 - 3.2 (approximately), but in later versions it does not work as it should. It seems to be related to MSTime. The problem is that I did not write the code, and I do not understand ZScript at all. The author of the code tried to fix it, but the bug did not go anywhere. The bug lies in the following - there is a torch. The torch has dynamic lighting. And this lighting does not match the color of the torch color, although in earlier versions everything worked as it should. "It looks like your code makes some assumptions about the maximum value the timer can return. This really can return any valid integer value - even negative ones. If you want to work with time results you always have to use the difference between some starting time and the current time." In the version with the corrected code (v 1.4) everything seems to be fine, but after a while the desynchronization of sprites and lighting begins. I would be grateful if someone could help with this definitively. I attach two links to the wad, in v 1.2 the original code, and in v 1.4 corrected.
https://www.dropbox.com/s/93eucnz5zbta8 ... 2.pk3?dl=1
https://www.dropbox.com/s/yauaq6hvigu11 ... 4.pk3?dl=1

[_mental_]

Occasionally saw your post on Doomworld and remembered that I didn't reply to this topic.
Could you please provide a simple test map with a small square room and a torch that exhibits the mentioned problem?
It will help if you will find the last stable version when it worked as it should.

EDIT: Also, rainbow shader in version 1.4 is not quite correct. You should not use #extension directive because

You should put these definitions before any other language features, but after the version declaration.

The way GZDoom handle shaders there always be some actual code before user's shader.
I suggest you to just remove the line with #extension declaration.

[Serious_MOod]

Could you please provide a simple test map with a small square room and a torch that exhibits the mentioned problem?

There are two versions in the attached archive. test1.2.pk3 I ran in GZDOOM 3.2.0, and there was no way I could get out of sync. test1.4.pk3 I ran in GZDOOM
  3.5.1, and then I managed to get out of sync after I switched to some other application on Windows without putting Doom on a pause, and then switching back to GZDOOM. Although, as far as I know, desynchronization during the game appears after some time.
https://www.dropbox.com/s/s3bqurwgummsh ... T.zip?dl=1

Also, rainbow shader in version 1.4 is not quite correct. You should not use #extension directive because

Does this raise any problems? The author of the code just added them to fix another bug, so I suspect.

I asked Graf Zahl about all this: about the function MSTime, whether it changed somehow between versions, and so on, and that's what he said to me.

Yes, something has changed. In fact the entire timing system has changed. As a result the values returned by MSTime can be a lot larger than before.

Like I said in a previous post, you cannot use the values returned by MSTime directly - you have to use the differences between two time points. The absolute value is totally undefined. It can be anything from -4billion to +4billion and is never guaranteed to be close to 0.

You have to fix your code.

What you did here is dead wrong. You cannot use MSTime like this and expect it to work:

override void Tick()
{
SetHSV(int((float(MSTime()*2)/1000/8+pos.z/2048)*255), 255, 255);
Super.Tick();
}

float(MSTime()*2) already overflows and produces all your problems. Like I said, you have to use the difference between current time and a reference time point, not the absolute value that's being returned by MSTime. And you shouldn't perform an integer multiplication on it because it significantly reduces its value range.

This would have broken anyway, had you just had your mod run for a few hours or running the engine before starting your mod.

[_mental_]

Does this raise any problems? The author of the code just added them to fix another bug, so I suspect.

Version 1.4 doesn’t work on macOS, GZDoom aborts with a fatal error because of shader compilation failure.

[Serious_MOod]

Is it possible to count the time in the shader according to the start time of the level, and not the engine? if there is such an opportunity, it would help.

[Gutawer]

Something like level.time + e.TicFrac (in a RenderOverlay override, measured in tics) should do that, IIRC, but still, MSTime doesn't count time since the engine started, it uses time since the Unix epoch. I would personally say that gametic + e.TicFrac is the best timer for visual effects, which is tics from the engine starting.

[ZZYZX]

Does gametic not get affected by pause/opening menus? Because that's the issue I had with level-related tic counters: shader ignores any pause, while tic counter stops.
Also: this probably is not relevant anymore since, in some time after I wrote this code, shaders finally learned to count time since level startup.

MSTime doesn't count time since the engine started, it uses time since the Unix epoch

This is probably only since they changed it to int64. Because 32-bit millisecond timers can't rly fit Unix epoch in them and thus usually return time since OS or (more common) application startup.

Either way sadly there's no direct way to sync to this:

Code: Select all

	activeShader->muTimer.Set((double)(screen->FrameTime - firstFrame) * (double)mShaderTimer / 1000.);

However, "frameTime" is somewhat equal (+- 1s) to calling MSTime() which is why I used it in the first place.