mIRC Home    About    Download    Register    News    Help

Print Thread
#126157 26/07/05 04:57 AM
Joined: Aug 2004
Posts: 11
H
harl Offline OP
Pikka bird
OP Offline
Pikka bird
H
Joined: Aug 2004
Posts: 11
hi,

is there any possible way to create or implement a _real_ time(stamp)-format counting milliseconds ?
i know there's all the ways like $ticks and multimedia-timers to workaround with and i've been trying to combine them to a working time-format, relatively resetting a milliseconds-variable to 0 when the seconds advance, so that a 'full' second indeed (relatively) goes from theoretical 0 to 999 ms (though the timer counting 'realtime' ticks by 1 to about 16 milliseconds mostly budges to the same milliseconds (between about 13 and 18) over and over again).
sofar the milliseconds aren't as accurate as i'd like them to be, firstly because the whole thing uses up way too much system resources that way, and secondly because the milliseconds aren't really 'realtime' because of that 'budging' (like when setting a simple 1-millisecond-timer nearly repeats the same milliseconds (differing by those 13-18 seconds from each other) every second, as it doesn't actually seem to be calculating or getting them directly from the cpu-clk somehow, but simply 'reads' a windows-internal timer (?). or where do the milliseconds for the $ticks function come from ?

so my forward question is, if there's no more resource-saving method of counting or calculating 'realtime'-ms (not ticks- or timer-ms) ?
and -if not- why's the $ticks function exactly bound to the system's install time ? would it somehow be possible to add a variable/placeholder to the $asctime function, say 'lll' or 'LLL' for milliseconds like 'hh' for hours, so that $asctime(LLL) would actually give me the 'realtime' milliseconds of the current second ?

i hope someone aproximately realizes what i'm up to.
something like such a 'high resolution' time would come in handy, ex. when i'd want my time to be based on another time deviding logic than the common sexagesimal time system.

-harl-

edit1: moved post from "mIRC Help" to "Scripts & Popups"

edit2: an additional fact working against a possible usage of milliseconds manually is, that even when i wanted to devide a day into 1.000.000 pieces instead of 86400, mirc still updates the timestamp backgrounds/internally only once per second, so trying to split a second into 10 small pieces doesn't really work, as mirc shows 10 times the same timestamp regardless of the deviding logic, because my transformation's based on the sexagesimal seconds by $asctime.

Joined: Aug 2004
Posts: 423
C
Fjord artisan
Offline
Fjord artisan
C
Joined: Aug 2004
Posts: 423
hiya,

i'm not exactly sure if i'm following what you mean.. and not sure what you mean by "REAL TIME"... but, you have mentioned about multimedia timers and such(which states in the help file that they use system resources heavily)... i was just curious if you have tried something simple as /timer -mc ? the -c switch repeats the timer untill it catches up the you pc time "REAL TIME" if thats real enough for ya.. hehe j/k.

what your talking about, i must admit is beyond me but, i just thought i'd give a mention... it probaly doesn't even apply to what your doing..
oh well, just my 2 cents worth.. take how ya like or don't like, your choice. wink

Joined: Sep 2003
Posts: 4,230
D
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
Code:
;usage /ctimems : well revaluate the the offset values used to produce the $identifier results (2 second delay during this processing)
;usage $ctimems : returns $ctime and 3 digit decimal place being miliseconds, (2 second delay if no /ctimems call is made prior to this $identifier being used)
alias ctimems {
  if (!$var(%milliseconds.ticks,0) || !$var(%milliseconds.ctime,0) || (!$isid)) {
    var %ctime = $calc($ctime + 1)
    while (%ctime >= $ctime) { }
    set -u1000000000 %milliseconds.ticks $calc($ticks - 1000)
    set -u1000000000 %milliseconds.ctime $calc($ctime - 1)
  }
  return $left($calc(%milliseconds.ctime + (($ticks - %milliseconds.ticks) / 1000) + .0001),-1)
}


I listed this somewhere before, but couldnt find the thread when i did a search.

Joined: Aug 2004
Posts: 11
H
harl Offline OP
Pikka bird
OP Offline
Pikka bird
H
Joined: Aug 2004
Posts: 11
that's nice. thank you very much. smile

i nearly had it that way, but still based on a high-resolution timer counting the ticks and there's a curious ~100 ms dilatation between the two timers i can't explain. but i'll only use one of them anyways, so that won't matter.

and i still wonder why mIRC's timing only relies on those ~15.8 ms cycles (which may be an explanation why the time functions are at most only updated ~63 times per second).
though even a 1-ms high-resolution timer internally is a bit faster (~1/20th) than 1 ms, all the mIRC functions related to time seem to be based on those regular cycles (which as well explains, why the same millisecond values repeatedly appear again and again and start changing when cpu-time is 'drawn away' from mirc).

hm. ok. enough of that, i guess.

Joined: Jul 2005
Posts: 5
G
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
G
Joined: Jul 2005
Posts: 5
You should know that the windows tick counter is updated every 11-12 ms in NT machines (this was done every 65ms in win9x/me machines). All windows timer events and time updates are done with that interval so you will never get more precision when using the normal windows functions. You can use the "Performance Counter" (assuming the system has one, and most systems do) to get precise time differences and program high-precision timers but HP timers done this way use a lot of resources. If you set a windows timer to 1000 you will get anything from 990 to 1010ms so you will never get exactly 1000ms with the windows timers (even if it's close).


Link Copied to Clipboard