‎10-31-2012 08:39 AM - edited ‎10-31-2012 08:43 AM
@JW-L3CE wrote:
Jeff·Þ·Bohrer wrote:
No I won't post the source I hacked at the OPs stuff without renaming and he would justifiably harm me.
You mean the stuff that's currently zipped and already placed in public view? Heh. Either way, thanks for the discretion. I guess I don't get to justifiably harm you today. You can "Report to moderator" and have it pulled back.
Ok, so the theory is that the ms rollover caused this? That might explain a few discrepencies that have been confusing me. We ran this all weekend and it worked before. It is a theory with no supporting evidence, unless you did take a look at the ms timer value on the machime that caused the error divided by 1000 and subtracted from current timestamp and found that rollover was proximal to the timing change. Did you?
Finally, on the topic of wait until next ms multiple. Would this would only cause a problem once during the rollover and only cause the next frame to be delayed? So if I'm doing 5000ms, the last iteration before rollover would be at 4.294965e9, it would then run 2296ms and another 5000ms. So I would only be off by 2.3 seconds? That's noise for me if that's the only potential problem. delayed once every 49.710269 days (about) now you know why I seldom use timed loops- I hate ms timer rollover and try not to depend on timing that has a discontiuity that I know about
‎10-31-2012 09:05 AM - edited ‎10-31-2012 09:09 AM
@JÞB wrote:
Ok, so the theory is that the ms rollover caused this? That might explain a few discrepencies that have been confusing me. We ran this all weekend and it worked before. It is a theory with no supporting evidence, unless you did take a look at the ms timer value on the machime that caused the error divided by 1000 and subtracted from current timestamp and found that rollover was proximal to the timing change. Did you?
Just did. Had to compile this.
686394629 with a timestamp of 10/31/2012 9:47:39.768 AM. This places the last rollover at 10/23/12 11:07 AM
The original test started at 10/23/12 1:20PM and sped up 65.25 hours in. That places the problem at 10/26/12 6:35 AM
Unless I'm messing up my excel math... easy to do because I hate managing excel timestamps (No, No, Stop doing that Excel!)
‎10-31-2012 09:33 AM
‎10-31-2012 09:45 AM
Summary:
The msTimer Rollover theory has been debunked. unless there are any other ideas it looks like the dt buffer in the timed loop was corrupted. the always copy will (Should) work. A loop with timing dependant on a Wait or Wait until next ms multiple would also fill the needs of the system.
Whoo... go get em JW
‎10-31-2012 09:48 AM
Works for me. Thanks for the help.
*drum roll* Solutioned!