Re: [AD] Proposal for an input model

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Martijn Versteegh wrote:
> I for one always liked the simplicity (for the user) of allegro's
> global-variable asynchronous system,

Yes, it makes up an important part of Allegro's ease-of-use.

> Imho 3 is no different from 1, but more complicated.

I don't think so: IMHO they have roughly the same level of complexity,
both internally and from the user viewpoint.

> Though maybe processes using only the polling system would benefit from
> using less threads.

That's the big advantage of model 3 over model 1. More flexibility.

> Since we need a framework for asynchonous stuff anyway (timers), I don't
> really see the advantage of dropping out the (very convenient)
> asynchronous input system.

Timers are handled separately from input so the two topics can be disjoined.

> I guess
>
> if (al_key[AL_SPACE])
> ....
>
> is not more efficient then
>
> al_poll_keyboard();
> if (al_key[AL_SPACE])
> ...
>
> or
>
> if (al_key(AL_SPACE))
> ..

That's a synchronous case, so polled and asynchronous inputs are not here
very different. When it comes to true asynchronous input, it's another
story.

> Still I don't really see the asynchonous system as a design flaw, and I
> don't think it would be wise to change too many features from allegro.
> It is rather popular the way it is, and a lot of people will get scared
> away if too many things change. IMHO we should only change whats
> really wrong.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/