[ 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