Millisecs() = 0
Blitz3D Forums/Blitz3D Beginners Area/Millisecs() = 0
| ||
| How often does Millisecs() reset to 0? Does anybody bother to code failsafes for this occuring during a game's execution? |
| ||
| Millisecs() resets to zero in think it's 30 years time. It's a similar problem to the Y2K bug of clocks, but moreso. The timer counts up to umpteen billion and then rolls-over, at which point timer based functions go pear-shaped and all hell breaks loose and just like the year 2000, all computers stop and the world is thrown into anarchy and a new Dark Age as we regress to animals without our computers working. Just looked it up on the Wikipedia http://en.wikipedia.org/wiki/Year_2038_problem |
| ||
That's Unix epoch time that runs out of bits in 2038, which is measured in seconds. MilliSecs() has 1000 times more resolution than seconds and therefore should run out of bits 1000 times faster.days_since_millisecs_was_zero# = millisecs()/1000.0/60/60/24 print days_since_millisecs_was_zero This code yields 18.5ish days. |
| ||
| Sorry, wrong widget. I believe the system timer is reset to zero on a reboot. Hence every time you start your computer millisecs()=0. This'll mean that unless someone leaves their computer on for 18.5 days straight there won't be a wrap-around. I actually make the figure nearer 50 days. The counter is 32 bit, so 2^32/1000 = number of seconds number of seconds/60/60/24 = number of days = 49.7 |
| ||
| Wow, it's been a while since I've rebooted! I guess that says something good about XP SP2 for once. I believe integers in Blitz are always signed, so you won't get that last bit. That leaves us with ~25 days. So does anyone bother to code safely enough to survive a Millisecs() overflow? |
| ||
| Not for just any program. |
| ||
| I've never programmed anything where this would matter (I pretty much only ever use Millisecs to seed the random number generator,) but this issue is good to know about in case I ever do write something where this matters. |
| ||
| just like the year 200, all computers stop and the world is thrown into anarchy and a new Dark Age ... yeah, those druids forgot to re-boot that Stonehenge computer in the year 200. It's all been downhill since then. |
| ||
| For more info on this subject, check out the topic linked below, and in particular, Floyds contribution. http://www.blitzbasic.com/Community/posts.php?topic=49285#548324 Here's some testing code I made up while I was mucking around with this. Graphics 800, 600, 0, 2 Const MAX_POSITIVE = 2147483647 Const MAX_NEGATIVE = -2147483648 current_time = MAX_POSITIVE deadline_time = MAX_POSITIVE + 1 ;current_time = -1 ;deadline_time = 0 ;Print "Millisecs() wrapover occurs every " + ( ( ( ( MAX_POSITIVE / 1000.0 ) / 60.0 ) / 60.0 ) / 24.0 ) + " days." Print Print "current_time = " + current_time Print "deadline_time = " + deadline_time Print Print "Time remaining = " + ( deadline_time - current_time ) Print ; -- Check if 'current_time' has exceeded 'deadline_time'. This should work even if one or both times have ;~ wrapped over to negative, or if one or both times have wrapped from negative to zero or positive. ;~ Substitute '>=' for '>' when testing if 'current_time' has reached or exceeded 'deadline_time'. If ( current_time - deadline_time ) > 0 Print "Timeout occurred" Else Print "No timeout occurred" EndIf ;^^^^^^ WaitKey () End |
| ||
| Thanks Bill! |
| ||
| Well, if you had your computer on for agggggges, and your game used millisecs to time frames or other such things, when it rolled over... i'm not sure what would happen, but something def would :D |
| ||
| Wow, it's been a while since I've rebooted! I guess that says something good about XP SP2 for once. I wonder how much nuclear energy is wasted this way. No offence, but people have no sense for economy these days. Try to make this amount of energy with your bicycle light generator. </offtopic> |
| ||
| Hibernation does not reset the system timer. ;) |
| ||
| I really had a bad day :) |
| ||
| Wouldnt this only occur if the program was running constantly for 25 days too... I mean, personally, Im always only looking for the change in millisecs sinve the last check to stop quick key-repetition... nothing serious would happen for me, I guess, just once evry 25 days the gun wouldnt fire for about 1/10 seconds! |
| ||
| Wouldnt this only occur if the program was running constantly for 25 days too No, try reading the thread. ...the system timer is reset to zero on a reboot... Some people might have larger problems - such as their game stopping working. Others might not be happy with their gun not firing for the tenth of a second. |
| ||
| I would think it would turn into a negative number at some point but abs() should fix that if you are really worried. |
| ||
| ABS can't fix it since it would invert the value. But as suggested elsewhere, if you try this: Example given: old_time is milliecs, taken 15 millisecs before the rollover happens, new_time is taken 15 millisecs after the rollover. Now, if you calculate: new_time - old_time you'll get 30, ignoring the fact that new_time is about 4 billion less than old_time. (mathematicly correct result would be about minus 4 billion, but the integer 32 Bit rollover is doing the trick also for subtractions) |
| ||
| Example given: old_time is milliecs, taken 15 millisecs before the rollover happens, new_time is taken 15 millisecs after the rollover. Now, if you calculate: Do your calculations include the three years that have passed since this thread was started? ;) new_time - old_time you'll get 30, ignoring the fact that new_time is about 4 billion less than old_time. (mathematicly correct result would be about minus 4 billion, but the integer 32 Bit rollover is doing the trick also for subtractions) |
| ||
| I was searching for something. This happens to me sometimes: I see something that I have to comment. Later then I realize how old the thread was. This is my worst sin. |
   |