Quote:Because I need to be different :). Partically it is a performance issue, just from tests, I can definately see a speed improvement when using the integers only vs the floats or doubles. If I need to go down that road, I will. I'm just looking to see if there is an integer solution.

Oh lordy. In what situation is getting a timestamp absolutely time-critical?
The closest I've seen is an in-game profiler, which when used *everywhere* ends up fairly heavy. What you do in that case is store the raw undecoded RDTSC value without any kind of calculation at all, so it doesn't matter if the calculation takes 3 clocks more or not.
You are being bitten by premature optimization!

BTW, again about the integer thing. To paraphrase some US senator (who was probably talking about the budget): here a billion, there a billion, pretty soon we're talking about real money.
Integer truncation during division will eventually add up to quite some errors. You could implement fixed-point arithmetic, but that would be utter madness, since FPU is faster and easier.

Quote:There is less precision in a double than in an int64.

True, but let's be realistic here.
1) 53 bits of mantissa give you 16 decimal places of accuracy. Let's write off 2 of them for fun (and calculations on your timestamps), 6 for microsecond precision, and that leaves 8 of range, which is enough to exactly represent something like 3 months.
2) assuming we are talking about relative timestamps as used in games, that is PLENTY.

Do not allow yourself to be swayed by arguments applying to something else entirely. TomF is talking about storing game coordinates - numbers that tend to get very large (unlike relative timestamps).

Well part of the precision issue is this is being applied to a Mud some friends and I are developing. So being able to track more that a month is important. Which is why I am using the data structure that has support for years and using the TimeSource in the configuration it is in to just get the difference between the last call and the current call. Now what I might have to go back to is just storing the milliseconds/microseconds in a floating point value all its own.

What kind of stinks is the fact that the current system DOES work fine with timeGetTime() calls using the integer system. When it gets a hair out of sync (and I'm talking the most I have ever seen it get out of sync is like .03 milliseconds), it seems to correct itself.

Storing time [seconds] in a double easily works across intervals of years.
My figure of 3 months was a back-of-the-envelope calculation as to when *one Unit-in-the-Last-Place* error would occur - at microsecond accuracy.

I'm kind of amazed you're implementing your own system when double is the easiest solution and there exists POSIX struct timespec and tm, but hey.

The problem with using just a double is as the number of seconds increases, the subsecond decreases, its gradual, but it is there.

Also I use a custom class to store it mostly for doing comparisons. Right now I can do most comparisons with just 2 integer based if operations, since I am storing all my time data into 2 32-bit numbers. I could easily combine it into a single 64-bit variable in the current state. Plus it is based more on elapsed time than an actual clock time. Right now I'm just starting the timer off at the same point as the clock for accuracy comparisons.

[edit]
PS - I do appriciate all of the input. I'm not trying to say that I'm right or my system is better in anyway. Right now, I am just trying to get it to work.

Quote:Original post by Rattrap
It still drifts. Right now my only guess is I'm loosing extremely small fractions of seconds when doing the integer division (which is something that the timeGetTime() doesn't do, it is just subtraction).

That is my suspicion. You can rule out differences in the timers by checking the values returned by timeGetTime and QPC at the end of the test and making sure that they have kept in sync.