Millisecs() causing an issue

This might not be considered a bug because it is documented correctly but it is wierd.

millisecs() returns Milliseconds since computer was turned on.

well I use that function to determine if an amount of time has passed by doing:

if millisecs()-lastUpdate > frameSpeed then ....

well for the first time, I had code that was working perfectly and now doesn't because my machine has not been rebooted in a very long time. Millisecs() is now returning a negative number which screws up the code shown above.

shouldn't millisecs() be returning the current time in milliseconds instead of the number of milliseconds from the time the machine was turned on?

If not what is the recommended fix?

That is not a bug, but common behavior between 24 and 48 days of no reboot (overflow of int)

What you need to do is to use absolute differences. So use abs(millisecs() - lastUpdate) > frameSpeed


Alternative you can check the millisecs() at boot time and if it is < 0, then do lastUpdate - millisecs() instead of millisecs() - lastUpdate

EDIT: Reason for the second solution is, that it does not cost any time and due to the existing function pointers in BM, you could easily create to TimeDiff functions which you assign to a global timeDiff function :)

great, thanks a bunch

In many cases, the 'abs()' is not necessary.

As long as lastUpdate an int, stuff like 'elapsed=MilliSecs()-lastUpdate' will work fine.

But I guess, if in doubt, use abs!

As a small side note, in BlitzBasic using :

if a < 0 then a = -a

was faster than using abs(). Im not sure if this is the same for blitzmax but its probaly just because of the overhead due to the function call. Its a preaty insignificant optimization thats not realy worth it.

You could also just use a masked Millisecs (millisecs() & $7fffffff) and would get rid of the problem. Thats what I do - get this value at the beginning of my mainloop and use it everywhere a timer is set. I think this one-time operation won't cost that much of speed.