It would be nice to be able to create timers with resolution in the milliseconds. This would be useful for one-off timers to go off in the future rather than perform a busy loop in Lua which locks up the client.
Timer resolution in milliseconds
Posted by Kahenraz on Wed 05 Oct 2016 10:36 PM — 6 posts, 27,672 views.
The underlying messages from the operating system don't have that granularity. This isn't a real-time game client.
What are you using to create a timer? Win32 SetTimer() has millisecond granularity.
Yes, I use SetTimer.
https://github.com/nickgammon/mushclient/blob/master/mainfrm.cpp#L394
But here's the thing ... there is a difference between precision and accuracy. You can specify millisecond precision. But accuracy?
See: WM_TIMER message
When the timer expires you get a WM_TIMER message. From that page:
So, you can put in a request that you get a message after 10 milliseconds. But if the Windows message queue is full of incoming data from the MUD, you might wait 10 seconds!
https://github.com/nickgammon/mushclient/blob/master/mainfrm.cpp#L394
But here's the thing ... there is a difference between precision and accuracy. You can specify millisecond precision. But accuracy?
See: WM_TIMER message
When the timer expires you get a WM_TIMER message. From that page:
Quote:
The WM_TIMER message is a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue.
The WM_TIMER message is a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue.
So, you can put in a request that you get a message after 10 milliseconds. But if the Windows message queue is full of incoming data from the MUD, you might wait 10 seconds!
There's no guarantee that any timer will fire at the expected time. But there is a big difference between 500ms and 1s which shouldn't be an issue.
Timers aren't great for my use case in general but it's the closest thing available to a scheduler and would still be better than halting the client on a busy wait. Providing perceived accuracy in the milliseconds would go a long way.
Timers aren't great for my use case in general but it's the closest thing available to a scheduler and would still be better than halting the client on a busy wait. Providing perceived accuracy in the milliseconds would go a long way.
The timer already has a resolution of 0.1 seconds. That is 100 ms.