Timer inaccuracy in text objects

So I did an experiment:

By putting two text objects side by side, assigning the first one with a timer text game property then the other one with an integer text game property. Integer text object adds a value of “1” to the displayed text every second (depends on how many fps is set on the scene physics tab) while letting the timer text object to just do its own thing and start the game.

Expectation was that they will be essentially two (almost) identical stopwatches. But after just a few seconds I noticed that they become non-synchronous.

Could it be caused by the slight fps drops that happens occasionally?

this has nothing to do with text objects, the problem is FPS can not be used as a basis for a timer, not if you want a precise one.

I only used text objects as an example so it could be visualized simply.
And what I’m trying to say is that the property values can be quite unreliable when used for “accurate” clock/timing methods.

You are trying to say that “properties are not accurate”: Accurate about what?

Can you share your benchmarking blend to double check your experiment? Chances are you made false assumptions.

Notably: Frame time can be inconsistent, but timers should not be affected by this.

Also I wonder how a timer property would match compared to the system time? (using Python to test).

I imagine the timer is tied to the clock. Your incrementing property increments every time a second has passed, which in reality will be 1 second + the time it takes to process the change. The latter will never be exactly a second.

My point is that non-timer properties can be inconsistent WHEN used to make an in-game clock mechanism like countdown timers or stopwatches. Particularly in something like a racing game where you may have a time trial level and the recorded time in the game should be synchronized with time recorded in the real world.

Also, there doesn’t seem to be a tutorial on how to use the timer-type property to define values without using python (because I assume that it’s actually based on the system time of the hardware that’s running the program although it may be a lot more complicated than that).

But unfortunately the blend file was not saved because I was just messing around with the logic bricks at the time.

(P.S: I have a bad habit of over-complicating things)

If you need to set a game-clock, you need to reference the actual system time-of-day, which is maintained by hardware. First, capture the time when the game started. Next, at least ten times per second (according to how much visual “lag” you wish to tolerate), retrieve the current time and calculate what the timer’s displayed value should be. If it has changed, redraw it; if not, do nothing until next time.

Typically, there’s a clock out there which is an unsigned integer measured in milliseconds (1/1,000 of a second), making the math easy. Better yet, Python e.g. has a full-featured Time object which can do the math for you: “how many seconds have elapsed between that-time and right-now?”

yup, all depends on the frame rate. 60 tics a second or seconds * logic.getLogicTicRate()

but what is the problem with timer property, works great, my day/night cycle counts on it heavily and is accurate, so why do you want to build your own?

Don’t know what you are trying to do, but just setup a timer property and watch it roll. It is a float-like property that just keeps updating based on time. You can copy values, reset the value, everything like a normal property.

Thanks for the confirmation.

To be honest, I just actually want to learn how to use properties properly

not sure there is a “proper way”. heck, i put whole classes in them. works great. but timer props are an easy way to get real time.