Result value of GeGetTimer()

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 13/03/2012 at 02:28, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   R12/R13 
Platform:   Windows  ; Mac  ;  Mac OSX  ; 
Language(s) :     C++  ;

---------
The GeGetTimer() function currently returns the internal current timer count in milliseconds as a LONG value.

Does this counter value wraps after 2^31-1 to zero (like a formal LONG) or after 2^32-1 (like an ULONG)?
In the first case: May negative values be occured ?

My assumtion is, that the return value of GeGetTimer() should be an ULONG.

Has anyone experience in that ?

Andre

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/03/2012 at 05:49, xxxxxxxx wrote:

Originally posted by xxxxxxxx

<ADDRESS>
User Information:
Cinema 4D Version:   R12/R13 
Platform:   Windows  ; Mac  ; 
Mac OSX  ; 
Language(s) :    
C++  ;

---------
</ADDRESS> The GeGetTimer() function currently returns the internal current timer count in milliseconds as a LONG value.

Does this counter value wraps after 2^31-1 to zero (like a formal LONG) or after 2^32-1 (like an ULONG)?
In the first case: May negative values be occured ?

My assumtion is, that the return value of GeGetTimer() should be an ULONG.

Has anyone experience in that ?

Andre

It wraps after 2^31 -1 (as LONG is suggesting) and then the return value can get negative.

In other words: As long as your startTime and endTime value are within 2^31 - 1 ms (roughly 25 days), the resulting difference will be definite and positive.

If the period you're measuring can be longer than those 25 days, then you could try to count the number of wrap-arounds and reset the counters (but that isn't 100% fool-proof, as there is no guarantee that the measuring thread has been executed within these 25 days).

If you really need to monitor a long period of time (which exceeds the range of GeGetTimer), using GetDateTimeNow() might be an option.

Best regards,

Wilfried

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/03/2012 at 11:36, xxxxxxxx wrote:

Hi Wilfried,

thank you so much for your fast response.

In Windows we have a "DWORD GetTickCount(void)" function (DWORD is defined in Windows as an unsigned long).
This system counter runs up the full range and wraps to 0 after 49,7 days.

So the question for the counter value of GeGetTimer() is: What will be happened when the counter arrives 2^31 ? Will the counter moves to 0 or to -1 ?
If it goes to -1, then we can cast the LONG result into an ULONG because the counter will (most likely) continue counting in the negative range.

I would test this stuff, but I dont want to wait 49 days for results
Do you have an idea if there is any possibility to manipulate this internal counter (setting the counter to a high value) out of C4D ?

Best regards,

Andre.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/03/2012 at 13:28, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Hi Wilfried,

thank you so much for your fast response.

In Windows we have a "DWORD GetTickCount(void)" function (DWORD is defined in Windows as an unsigned long).
This system counter runs up the full range and wraps to 0 after 49,7 days.

So the question for the counter value of GeGetTimer() is: What will be happened when the counter arrives 2^31 ? Will the counter moves to 0 or to -1 ?
If it goes to -1, then we can cast the LONG result into an ULONG because the counter will (most likely) continue counting in the negative range.

I would test this stuff, but I dont want to wait 49 days for results
Do you have an idea if there is any possibility to manipulate this internal counter (setting the counter to a high value) out of C4D ?

Best regards,

Andre.

There is actually no way to modify the "internal" counter of the time function - this is the time that elapsed since system start. GetTickCount isn't necessarily what you want to call (as it isn't as precise as timeGetTime() - for a longer explanation see: http://blogs.msdn.com/b/larryosterman/archive/2009/09/02/what-s-the-difference-between-gettickcount-and-timegettime.aspx).

The Timer wraps around from 0x7fffffff to 0x80000000 (which is the highest neg. number). So technically you could cast it to ULONG (to get an extended range), but you're relying on undocumented behaviour then.

Best regards,

Wilfried

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 14/03/2012 at 14:45, xxxxxxxx wrote:

Thanks Wilfried,

I will risk the undocumented behaviour and I hope the MAXON developers had been ensured that GeGetTimer() returns reliable values 26 days after system start always.

So, Thanks a lot again.

Best regards,

Andre.