Yes, but when timer starts getting irregular updates, your elapsed time will go from nothing, to chunk values, which will really screw up your code. The code I posted is really just to show how messed up timer() can be, even after just a few days. I tend to use an elapsed variable like yourself, but with irregular timer() updates that elapsed time updates in chunks...
like:
Loop1 : 1ms
Loop2 : 1ms
Loop3 : 1ms
Forward a week...
Loop100503052 : 1ms
Loop100503053 : 0ms
Loop100503054 : 0ms
Loop100503055 : 0ms
Loop100503056 : 5ms
Loop100503057 : 0ms
Loop100503058 : 0ms
Loop100503059 : 3ms
Loop100503060 : 0ms
Loop100503061 : 0ms
So timer based movement means it can end up updating like that - things moving smoothly, then eventually things stop, or move in big chunks. It's not something that can be solved with internal handling, unless you lock the frame rate and forgoe timer based movement. Ideally.... we need to be able to reset timer() on program launch, and even during the program, if the timer() get's too unruly.
Or!!!
If it's possible to set the interval for perftimer, then it might be pretty useful for this stuff - sometimes we don't need 1000th second accuracy, sometimes just 100th is enough, depending on the project. Would probably be better suited to non-movement timer systems though - like virtually locking the frame rate to 50, then passing back any remaining resources to Windows, or internal jobs like path finding and AI. Like, we could set the perftimer to increment according to a specific frame rate, then just wait on the timer changing value. But that way, it would reduce the accuracy of the DWORD, it wouldn't need to be so 'infinite' - and that means it's less likely to hit the jerky numbers.
Oh, if it could have 2 parameters, like a straight second counter DWORD, so 1 seconds = 1 instead of 1000... then have a second timer for just the miliseconds, that resets to 0...
Anything really that helps avoid the inaccuracies would be a benefit.

Health, Ammo, and bacon and eggs!
