Re: [AD] new API

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


On 2006-02-21, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> On Wed, 2006-02-22 at 00:45 +1100, Peter Wang wrote:
> > 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.
> 
> Intersting how you are using the timer events, I must think about if I
> like this more or less than my method with al_current_time and al_rest.
> 
> Hm, and nothing happened when I touched the yellow block (which is easy
> for an old ZD player :) ).

I think it was level 10 that I copied :)

> 
> > 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).
> 
> Do you have such a tree? Maybe you could make a new SVN branch with it..

It's out of date but I will try to see what changes I made.

> > > - 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.
> 
> Ok. I'd still like a simpler way to start up Allegro.. and not for the
> main app, but for the 100 throw-away tests I likely write during
> developing the one main app.

You can easily do that without putting the functionality into the
library.

> > 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.
> 
> Well, not sure. Assume, I make a program with two windows (we said we
> want to allow that at some point). Wouldn't I need two keyboard event
> sources, one for each window?

No, all keyboard events are from the same event source.  However you can
tell which window was focused at the time by looking at the `display'
field in the AL_KEYBOARD_EVENT structure.  This is so the user doesn't
need to keep track of one keyboard and one mouse event source for each
and every window.

The way I was thinking the auto registration would work is:

    al_enable_auto_registration(true);	/* off by default */
    al_install_keyboard();
    al_install_mouse();

Then the keyboard and mouse event sources would be registered to some
event queue, e.g. `al_main_event_queue' to follow `al_main_display',
although it is a bit long.

We would have an `AUTO_REGISTER' bit for al_install_system(), so you
could write al_install_system(KEYBOARD | MOUSE | AUTO_REGISTER);

Peter





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