indi...I use this code in nearly every program because you will need the actual timer value to stay clear of frame rate dependencies. I think that Cash was telling you that above, but...if you implement a loop counter, you will be locked to a different time base almost each frame, really. If you use the milliseconds elapsed since the last loop, you will free yourself from that dependency, and also...calculations based on time are closer to actual real-world physics, and definitely required for decent simulated physics, imo. As an added bonus, now your game is an alarm clock, too.
global lasttime as dword = 0
global nowtime as dword = 0
global timesegment as dword = 0
global milliseconds as integer = 0
global seconds as integer = 0
global minutes as integer = 0
global hours as integer = 0
.
.
.
lasttime = timer()
do
nowtime = timer()
timesegment = nowtime - lasttime
inc milliseconds, timesegment
if milliseconds > 999
inc seconds
dec milliseconds, 1000
tick = TRUE
if seconds > 59
inc minutes
dec seconds, 60
if minutes > 59
inc hours
dec minutes, 60
endif
endif
endif
.
.
.
if tick = TRUE
tick = FALSE
.....do something once a second.
endif
lasttime = nowtime
loop
end
tick is a one second heartbeat. You can make them any size you want, and fire timed events from that code like tick does. You can also maintain a runtime counter with it. The code is far less obtrusive than you might imagine. The maximum penalty for use is only on the hour, and most times, its in, then out. timesegment is a particularly nice variable. I also count frames per second, which is not evident here, but...the more the game loop knows about elapsed time and frame numbers, the better equipped it is to perform tasks efficiently. That is a particularly good example of having smart data drive an essentially stupid program. I don't care if my program is stupid, as long as it does what I want it to do.
As to objections about timer(), I don't see them for a number of reasons. First of all, it is derived from Windows' GetTickCount(), or whatever its name is...the point is that it is not supposed to be a millisecond timer anyway, but...it is pretty accurate. Attempting to get better than that is missing the point on several fronts, imo...and not as feasible as you might think. Plus, you'll probably end up wasting time being so accurate.
Anyway, that is my 2p.
EDIT: - BatVink...can you just call timer() once in that loop? (It may be a tick different in the second call, after all, and it takes time. I get timesegment, which is the time since the last frame, at the same point in the frame. It should be valid for all calculations since the last frame.
One last thing : It is a multiplexer. The only "difference" is that most multiplexers divvy up time evenly, and we are not doing that, so this is a "time differential sequenced multiplexer."
