[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
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'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..
> > 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.
>
Yes, that makes sense. So we also always have a good test-case for the
compatibility wrapper (not that I find the compatibility wrapper should
be high priority).
> >
> > - 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.
> > - 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);
Yes, I'd prefer that. al_install_system(ALL).
> > - 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.
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?
>
> > - 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.
Ok.
--
Elias Pschernig