Re: [AD] Proposal for an input model

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> - polling only: the user must poll to update the status variables,
> asynchronous callbacks are not supported. The most lightweight solution
> and the cleanest (no more difference between keyboard, mouse and
> joysticks), but the asynchronous framework is dropped.

After investigating a little, I've come to the following conclusion: given
the cross-platform nature of Allegro, polled input is a Bad Thing (tm) or,
more precisely, a wobbly solution (in the sense of a wobbly chair, my
dictionary doesn't give me a better term).

On several systems, namely those with a GUI (Windows, X11, QNX), except
maybe BeOS, you have to process messages (called events under X11 and QNX,
but IMHO the term is somewhat misleading) sent by the system. Therefore a
game library to be written on top of them faces the following alternative:
either to make message processing explicit or to make it implicit.

The former approach is that of SDL: low-level, light but requires a message
API and a message loop.

The latter approach is that of Allegro 4: more high-level, heavier but no
need for a message API and a message loop, hence less complexity for the
user.

Now my point: once you have chosen the latter approach, asynchronous input
comes at virtually *no* cost, because once you have a background thread up
and running, using it to handle input is free:
- under QNX and X11, input messages are intertwined with the other messages,
- under Windows, it is possible to process Windows messages and catch
DirectInput events while still blocking, using the multiplexed blocking
functions MsgWaitForMultipleObjects() (I have a patch on my hard drive for
more than a year that merges the three message/input threads under Windows
that way, but I've never proposed it because I thought using many threads
was a design decision).

Moreover, mixing asynchronous message processing and polling can be more
complex than asynchronous processing alone: you have to filter the messages,
separating those handled asynchronously from those handled synchronously.

Therefore I now think model 2 and model 3 are plain wrong if Allegro 5
keeps using the Allegro 4-style approach.

I'm waiting for the flame ;-)

--
Eric Botcazou
ebotcazou@xxxxxxxxxx