Re: [AD] Keyboard timing problem

[Peter Wang <novalazy@xxxxxxxxxx>]

On 2007-06-01, Colin Ward <lists@xxxxxxxxxx> wrote:
> Hello Peter
> 
> On 02/06/2007, you wrote:
> > 
> >> > I didn't realise you were targeting the 4.9 branch.  Cool.  The
> >> > events/input stuff won't be changing much any more, but other stuff
> >> > like graphics will be changing, so if you want something stable you
> >> > should target the 4.2 branch, or maybe the 4.3 branch that we are
> >> > planning on opening.
> >> 
> >> Um, I think I'm missing something here.  I have ported 4.3.1, which I
> >> downloaded from a Sourceforge link that I found on www.allegro.cc.  In
> >> docs/txt/allegro.txt it says "Version 4.3.1 (WIP)."  Does this use the
> >> new keypress system?
> >
> > Yes.  Ok, it's a bit confusing right now but what used to be called 4.3
> > is now going to be called 4.9.  The other "4.3 branch" that I mentioned
> > is something else.  See http://wiki.allegro.cc/AllegroRoadmap
> 
> Right, so the 4.3.1 (WIP) tarball that I downloaded *was* the 4.3 branch in
> Subversion but is now the 4.9 branch.  I notieced in branches/4.9 there was
> a commit comment "Move allegro/branches/4.3 to allegro/branches/4.9".  So
> that 4.9 branch is the same as my 4.3.1 tarball but with some additional
> work, and will be released as 4.9.2?  And the old 4.2 branch is going to
> have some newer stuff such as AllegroGL retrofitted into it, becoming 4.3.9
> and then ultimately 4.4.  I think I got it.  :-)

Yup, that's it.

> So the question is: Which one should I be working on?  Also, will the user
> level API be the same on the different branches (ie. only the backend will
> change)?

The user level API will be different (see the AllegroRoadmap for the
places in which they will differ).  What you see in the src/compat
directory are our best attempts at emulating most of the 4.2 API on top
of the 4.9 API to provide compatibility for older programs.

I'd have to recommend doing a 4.2(4.3) port first.  4.2 has the
advantage that it is stable (inside and out) so your work definitely
won't be lost.  We still haven't worked out all the details of 4.9 (the
graphics parts) so your work might be for nothing.  It should not be
that hard to backport your changes to the 4.2 branch.

But since you've done something on the 4.9 branch already, no need to
waste that work :-)  We can include that in the 4.9 tree even if it's
incomplete.

> >> This new keyboard API that you mention, is it in 4.3.1?  If so, could
> >> you give me a pointer to the files/functions to look at?
> >
> > Incredible, you implemented it without knowing what it is :-)  See
> > here:
> >
> >   http://wiki.allegro.cc/NewAPI/Events
> >   
> >   http://alleg.sourceforge.net/internaldocs/files2/allegro/events-h.html
> 
> Hmmm, I thought that was just how it worked.  Took ages to figure out!!! 
> Especially given that the Amiga OS4 implementation of
> pthread_cond_broadcast() has a *nasty* bug that locks up the entire system!
>  *shudder*  Gotta report that one to the OS4 beta list and get it fixed
> (using pthread_cond_signal()) just for now.
> 
> But more questions: Using this system, Allegro is still going to suffer the
> keyboard problem because I send and event from my input thread to the
> cokeybd thread, which then updates the key[] array which gets read in the
> main thread.

Polling key[] won't be the recommended way to get input anymore.  In the
new system you'd create an event queue and register a keyboard with it.
Any keys pressed or released would inject events into the event queue,
which you can't miss.

> And before this events system came into play, how did the
> keyboard input system work in terms of threads and who checks for input?

See Julien's reply.  It's worked okay so far.

> My apologies for all of these questions - I have had a crash course in
> Allegro architecture over the past week so I still have many question marks
> hanging over my head!  :-)

No problem.

Peter