On 07/09/2019 8:42 pm, Zoe Peterson wrote:
> GetTickCount and GetTickCount64 are Windows API functions that are
> explicitly documented as returning milliseconds,
I have to agree with you. If FPC keeps basing its implementation and
API's on Win32 or Delphi, then it should adhere to their document
On 08/09/2019 1:07 am, Alexander Grotewohl wrote:
> every call to gettickcount is something
> like 10-15ms or so off.
Martin's suggested documentation "The minimum resolution may vary"
makes that very clear.
Also anybody that works with timing API's should know that each platform
has differ
> If you're going to be insulting and personal, you might consider
> unsubscribing yourself from the mailing list: this is a technical
> discussion mailing list, not a tabloid where such things are permissible.
Oh, given that I've been called various things worse than a simple "that's not
how thi
El 8/9/19 a les 19:08, Michael Van Canneyt ha escrit:
On Sun, 8 Sep 2019, Luca Olivetti wrote:
El 8/9/19 a les 18:23, Michael Van Canneyt ha escrit:
Besides, Now could go backwards (if system time is adjusted), while
GetTickCount cannot
It can if the fallback is used.
Well, that's a b
On Sun, 8 Sep 2019, Luca Olivetti wrote:
El 8/9/19 a les 18:23, Michael Van Canneyt ha escrit:
Besides, Now could go backwards (if system time is adjusted), while
GetTickCount cannot
It can if the fallback is used.
Well, that's a bug then.
It's the best you can do in absence of an ac
El 8/9/19 a les 18:23, Michael Van Canneyt ha escrit:
Besides, Now could go backwards (if system time is adjusted), while
GetTickCount cannot
It can if the fallback is used.
Well, that's a bug then.
Bye
--
Luca
___
fpc-pascal maillist - fpc-p
On Sun, 8 Sep 2019, Martok wrote:
Am 08.09.2019 um 13:17 schrieb Yuriy Sydorov:
Sure, measurements using GetTickCount is not precise (+-20ms on Windows).
On any reasonably recent kernel, it has 16ms granularity and even before that
was always guaranteed to be a monotonically incrementing (ex
On Sun, 8 Sep 2019, Luca Olivetti wrote:
El 8/9/19 a les 13:17, Yuriy Sydorov ha escrit:
if GetTickCount - FStartTime > 3000 then ;
I actually use
if DWORD(GetTickCount-FStartTime) > 3000 then
the former is affected by the rollback after 49 days, the latter isn't.
vs
if Now - FSta
Am 08.09.2019 um 13:17 schrieb Yuriy Sydorov:
> Sure, measurements using GetTickCount is not precise (+-20ms on Windows).
On any reasonably recent kernel, it has 16ms granularity and even before that
was always guaranteed to be a monotonically incrementing (except for the
rollover) number of millis
El 8/9/19 a les 13:17, Yuriy Sydorov ha escrit:
if GetTickCount - FStartTime > 3000 then ;
I actually use
if DWORD(GetTickCount-FStartTime) > 3000 then
the former is affected by the rollback after 49 days, the latter isn't.
vs
if Now - FStartTime > 3/SecsPerDay then ;
Besides, Now c
On 08.09.2019 13:42, Michael Van Canneyt wrote:
On Sun, 8 Sep 2019, Yuriy Sydorov wrote:
Strictly defined measurement units are important for cross-platform (and Delphi) compatibility. So GetTickCount_2 -
GetTickCount_1 must return how many milliseconds have elapsed between calls of GetTickCo
On Sun, 8 Sep 2019, Yuriy Sydorov wrote:
On 08.09.2019 10:09, Michael Van Canneyt wrote:
On Sat, 7 Sep 2019, Zoe Peterson wrote:
From: Martin Frb
But that does not mean, it needs to be changed on existing targets.
And if it is not going to be changed, then it can be documented.
I agree
On 08.09.2019 10:09, Michael Van Canneyt wrote:
On Sat, 7 Sep 2019, Zoe Peterson wrote:
From: Martin Frb
But that does not mean, it needs to be changed on existing targets.
And if it is not going to be changed, then it can be documented.
I agree with everything Martin has said, though IMO
On Sat, 7 Sep 2019, Zoe Peterson wrote:
From: Martin Frb
But that does not mean, it needs to be changed on existing targets.
And if it is not going to be changed, then it can be documented.
I agree with everything Martin has said, though IMO GetTickCount must
return values in ms on every s
14 matches
Mail list logo
