Okay, let''s say I want to make a OGL program (or part of one) which displays scripted events, or "movies". The current way that I implement this is by having a ''timer'' integer, which starts at zero, and is incremented at the end of drawing every frame. And then different things are done depending on the value of ''timer''. However, I myself consider this to be "bad" code, and it is obviously flawed--e.g., someone with a faster computer will see the movie quicker than someone with a slower computer. My alternate solution would be to have one integer, ''timestart'' be initialized to timeGetTime() (at the start of the program). And then have timer be changed relative to this time. E.g., timer = (timeGetTime() - timestart) / 10; The above code should give me 10 "ticks" per second, and all computers will run the simulation at the same speed (although not the same fps). However, yet again, I see a flaw with this. MSDN notes that timeGetTime() wraps every 50 days. I''m interested in having robust code--which works under any context. If my new code was ran when the "50 day wrap" happened, and timeGetTime() started over again at 0, then, well, that wouldn''t be good. Is there any other way to accomplish this--a way that isn''t hurt by timeGetTime()''s 50 day wrap? And no, I don''t want to "ignore this problem", I want to *fix* this problem. --Rob

Some solutions for fixing this would depend partially on what exactly you are doing for "movies" and on how your engine works (and what type of engine would effect it too).
One way I can think of to fix it (I'm coming up with this now, so I don't know for sure if it would work, but it's an idea...)
BTW, I think timeGetTime() returns a DWORD, but if it doesn't, this will need to be change.

if(timeGetTime()<<30==0)timer++;

If that works like I think it would, it should give you 28 tics a second, that's not the number you said before, but it's the only way I could get it to divide into a second evenly...

Wouldn't this be a faster way than the other is too? Can somebody tell me if this would acctually work?

Hope my recent brainstorm helps.


Edited by - Drakonite on June 2, 2001 7:22:34 PM

I don''t know if this helps, but 0x00000000 - 0xffffffff = 0x00000001 and 0x00000000 - 0x00000001 = 0xffffffff whether you are signed or unsigned. Wrapping every 50 days should only be a problem when timing things longer than 50 days.

Just keep track of the previous value of the timeGetTime() function, if the new value is less than the old value you''ve wrapped over, take how much the last one was less than the max and add that to your current and thats how much time has elapsed since then.

Hamhed