[AD] SetTimer for the timer |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: [AD] SetTimer for the timer
- From: Chris <chris.kcat@xxxxxxxxxx>
- Date: Mon, 9 Jan 2006 00:16:45 -0800
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:mime-version:content-disposition:message-id:content-type:content-transfer-encoding; b=jzX/N2Ep5uWxJaM0iDGu+9CeuBr/dvgSYjUY845FW/XZdAIE0bjMqArNgBHObHEHZRqeyKz/72kAXhcrXVWDrl9tmYqv5q+IAewVb0M/1GE8/+D8swY2iF4tHDukGAAFtgplvbJ7Uc9H1tqTKUcnUZ4ZVzc55rwwE+wXphA0Pt4=
Has anyone thought about using the SetTimer function to implement Allegro's
timer routines? It seems these would fit better than the current hackish way
of running a timed thread.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/timers/timerreference/timerfunctions/settimer.asp
UINT_PTR SetTimer(HWND hWnd, UINT_PTR nIDEvent, UINT uElapse,
TIMERPROC lpTimerFunc);
Since Allegro stores the timer callbacks in an array, you could simply pass
off the array index as the nIDEvent, then the specified timer function (or
the default WinProc) will get a WM_TIMER message with the appropriate
nIDEvent which can be used to reference the array and call the function (as I
understand it, a timer with a unique nIDEvent can have its own speed). It
seems this would be a much cleaner solution since the SetTimer function is a
closer match to the functionality Allegro's timers provide.
The only issue would really be if the timer messages block the main program,
which would cause problems for the functions that would do a mutex lock.
Though, to get around that, it can probably be made to attempt a lock but
fail if it can't (so it doesn't freeze up), reset the timer to be called very
fast until a lock can be grabbed, then reset back to the proper speed.
Another solution would be to leave the mouse/sound/input callbacks in a
thread, but put user-callbacks in a SetTimer timer (much the same way the X
port puts locking callbacks in a dedicated thread away from the other
non-locking callbacks). Either way, user-callbacks would not be able to do
mutex locks.. which they shouldn't be doing now anyway.