Re: [AD] Proposed changes for Allegro 5 (6?)

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> > - window resizing support
>
> Is this really needed? I think it'd require so much overhead it isn't
> worth it at all. Who really needs window resizing in games? Ok, Allegro
> is also for general multimedia apps, but again I'm not convinced on
> adding support for this...

And I'm already scared by simply thinking of resizing a DirectDraw overlay
surface with two backbuffers attached to it !

> > - Message based (see SDL)
>
> The callbacks suggested by Eric sound also interesting. Could you
> elaborate more?

I don't know if the 'you' is for Bob or me or both. Either way, I'm
elaborating: part of the elegance of Allegro is that you don't have to
bother writing a message loop in order to make the most tiny program work
and appropriately respond to the flood of messages the OS sends.

A dedicated background framework is in place to do that (threads on most
platforms) and does the hard work for you. Then, when you want to get some
input, you either simply read some shared variables the threads have cooked
for you (mouse_x, mouse_y, key[]) or you use a communication channel like
readkey().

Within this framework, the most straightforward way to implement
asynchronous events is the slot/callback mechanism: you register a callback
function for each event you want to be informed of.

Allegro already sort of implements this mechanism via:
extern int (*keyboard_callback)(int key);
extern void (*keyboard_lowlevel_callback)(int scancode);
extern void (*mouse_callback)(int flags);
int set_display_switch_callback(int dir, void (*cb)());

We could devise an unified slot/callback API: providing a list of events
with one or more slots attached to each, in order to let the programmer
register its callback functions. Of course this would require the
synchronization API we have been talking about for months.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx