Re: [AD] Using HPET in Linux/Unix? |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: Re: [AD] Using HPET in Linux/Unix?
- From: Chris <chris.kcat@xxxxxxxxxx>
- Date: Fri, 26 Aug 2005 06:20:03 -0700
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=ovEGpntKuAbHtT84UP+WL5kXtnkErqbsRYxg7L+sbNN7hiBq0cVGd8B0k4yjw8vgIEzrDImSBdNTA/iLYdqAGOZyuU7hYNjYeZQpD+H3WWozKfjNAN0B0DI2xGLE2JxrcsgAq2Z1OE/SUg3/tJdNtjQyaP4gfWc5FZI2h/igIjQ=
On Friday 26 August 2005 02:55 am, Elias Pschernig wrote:
> Basically, it does just what Allegro timers do, right?
That's how it sounds to me.
> We also have forward compatiblity according to abi._tx. But it could fo
> into 4.3.x.
I thought we were forgoing forward compatiblity in 4.2, instead leaving just
backward?
> Shouldn't it be done as a separate timer driver?
Of course. But what I'm saying is that we could move the sound callback
function to a user timer (which can use HPET or threads), while leaving the X
input/graphics callbacks in the bg manager, which will continue to use
threads only.
> On the subject of timers, I assume the al_get_ticks() in 4.3.x will get
> rid of 95% (or more) of the use of timers in current Allegro programs,
> since usually all they do is incrementing some frame counter :)
That's what I would guess. And hopefully we could encourage using pthreads for
threads (since that's what the majority of the multi-tasking world uses, and
there is a Win32 version) which would all but eliminate need for timers. But
my thought is that if we're going to have/keep Allegro's timers around, we
might as well implement them properly (which is what an HPET driver would be
for).