Game::getTime() behaviour in long running applications

[helmut.bressler]

Hello,

 

Our applications are running for a very long time (typically several month).

I have Game::getTime() in a material expression and I have to make sure it doesn't wrap around (or jumps back to zero).

I.e. if Game::getTime() is implemented like this:

float timer = 0.0f;

void Game::internalUpdate()
{
	timer += getIFps();
}

float Game::getTime()
{
	return timer;	
}

 

it will probably stop getting incremented due to the lack of precision, but it will never become negativ or zero.

However, if you are internally counting ticks with 32 bit integer precision, it may jump to a negativ value at some point.

Or you maybe the Engine is resetting the timer if it exceeds some value.

I'm just asking this question  because it is very hard to find it out on my own :-)

 

Thanks

Helmut

 

 

 

 

[alexander]

Hi helmut.bressler,

Game::getTime() is implemented like you said: IFps is simply added to the time value. Never become negative or zero, but has precision problems in the future.

Alternatively, you can use double clock() (in UnigineScript) or long double Timer::getFloatTime() (C++/C#) functions. These functions use QueryPerformanceCounter (long long precision) on Windows and gettimeofday on Linux.
 

Best regards,
Alexander

[helmut.bressler]

Hello Alexander,

thats no problem at all - in Unigine Script I typically use a double timer and add per frame the IFps value, thats also working :-)

I was asking because I have a post-material which should only be applied for the first couple of seconds. Of course it would be more efficient to deactivate the post material, but by embedding the logic directly in the material via an expression, it can be much easier integrated into other projects.

Thanks for the quick reply

Helmut