Re: [AD] new API

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


On 2006-02-20, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> I added a temporary example to see how the new API looks, already seems
> to work quite well :)

If you're interested, I've attached a small clone of the game mechanics
from Zep's Dreamland which I wrote at some stage (without any
animation).  You have to get to the yellow square by placing blocks
using the space key in combination with the arrow keys.  Standing on
different colours blocks restricts what kind of blocks you may place.

I've also got a small sokoban demo, but that uses OpenGL so is not
compilable with 4.3 at present (you'd need to graft the AllegroGL
sources into the 4.3 tree manually).

> I thought such an example is better for now than starting to adjust the
> old examples, since API details might change. And also, as we have no
> documentation yet, so a public example is a good thing to document what
> works already.

Yes.  We might want to create a new directory for examples using the new
API and leave the old examples unchanged.

> Anyway, writing this example gave me some more thins to wonder..
> 
> - Do we really want flags parameters not at the end? I'd prefer them as
> last parameter..
> 
> - Maybe we could reserve the value 0 to always mean auto-detect, e.g. if
> used as graphics driver, and also when used as update method. 99% of
> users could then just use al_create_display(0, 0, w, h, 0) - saves
> unnecessary typing.

It's a rarely used function (approximately once per program).  The extra
typing is worth the clarity.

> - Do we still need the install_* functions? I assume, they are useful to
> throw out stuff when static linking, but I think it would be more in the
> spirit of Allegro if input just works, without having to "install" it
> all.. also see below.

I think we still need them.  Not every program requires joystick or
sound support, and some programs may choose only to use Allegro's
keyboard or mouse routines, say.  On the other hand we might want
something like SDL where you would specify all the subsystems to
initialise at once, e.g. al_install_system(KEYBOARD | MOUSE);

> - Do we want event sources to be used like in the example? I.e. always
> create an explicit EVENT_QUEUE, then attach various sources to it? I'd
> somehow prefer a more high level approach, maybe something like:
> 
> EVENT_QUEUE *al_get_display_event_queue(AL_DISPLAY *display)
> 
> And it would return a queue, ready to query keyboard, mouse, display,
> joystick, and possibly more, events.

Event queues are not specific to displays, so that doesn't really make
sense.  However, maybe we can add a "default" event queue, just as we
have a "default" display.  Then, if you allow it, all event sources
installed would be automatically registered with the event source.

> 
> - i really like the event API :)

Great!

> - can we back-port al_current_time to 4.2? I think it's a very useful
> function..

Probably, but let's leave it for 4.2.1 as there are more platforms to
cater to.

Peter

Attachment: zep.c.gz
Description: application/gunzip



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