Re: [AD] Menus and Callbacks

[Elias Pschernig <elias@xxxxxxxxxx>]

On Tue, 2004-11-09 at 00:05 -0800, Chris wrote:

> Well.. personally, what I would like to see in the new API is
> something where you could load the DLL/.so durring runtime and still
> have the same functionality as if you staticlinked or used a
> dependancy DLL/.so (that's loaded at loadtime). I would also hope that
> one could support both things with one DLL. AFAIK, the former is
> possible as long as there's no global variables, though that obviously
> means that we'd have to put the backwards compat stuff in a seperate
> DLL or static lib.
> 

I like that idea. It wouldn't be that much different from libaldat for
the static case. And the dynamic case could be just e.g. the GUI module
or compatibility module in unix. Actually, if we change the Makefile a
bit, the current modules could be linked into static libraries when they
are not dynamic, instead of being linked into liballeg.a. So this could
simply done with the existing modules mechanism.

> So I still think if we're going to redesign the API for it at all, we
> should attempt to do so in a way that will match the rest of the new
> API. This would mean no global variables (only functions), proper al_
> prefixing, and a cleaned up/properly documented design. Adding extra
> _ex members or functions is something I'd like to avoid where
> possible.
> 

I agree. I meant the above for the current API - the only way to fix
this two shortcomings in the menu code would be _ex functions. Let's
hope we will design the new API well enough so we will never need _ex
functions there :)


> Hmm.. I don't mind the idea of a target bitmap. So you could render
> the GUI to a seperate bitmap that has the mask color for the
> background and just masked_blit that as needed to the screen or
> another buffer. Though we should probably add callback methods so the
> user can know when something was updated and which part, so they're
> not continuously masked_blit'ing the whole buffer every frame.
> 

Yes. Every MSG_DRAW could just trigger a user-provided callback, called
right after the dialog proc returns from handling MSG_DRAW. The GUI
procs currently never modify graphics outside their dialog rectangel, so
this would work quite well. Things like scare_mouse_area even rely on
this fact already.. so there should be no problems.

> In my mind what I see is... someone running the GUI in a secondary
> thread, which draws to an off-screen buffer and has a callback
> installed to blit to the game screen (which could be off-screen as
> well) for the main program. The main program would take care of
> re-blitting the parts of the GUI buffer whenever the game/app updates
> the main screen so the output stays in sync. This would allow
> asyncronous GUI usage along with the main program (which means the
> GUI's frame rate would be completely independant from the game's, and
> vice versa). If both the main buffer and the GUI buffer are video
> bitmaps, and masked video blits are supported, you could get some
> really wicked (as in cool) things going on, speed wise.
> 

I think the MSG_DRAW callback would work. The Allegro GUI keeps doings
its logic of intermixed input processing and graphics updating, but
every graphics update returns the dialog rectangle that was modified.. I
like this a lot, I'll put experimenting with its on my TODO :)

The user callback could just be, in the case you described above:

void my_draw_callback(DIALOG *d)
{
    blit (off_screen_buffer, game_buffer, d->x, d->y, d->x, d->y, d->w, d->h);
}

> > > bland. We could actually change how the default procedures look,
> > > though.. AFAIK there's nothing stating what they look like.. as long
> > > as they behave right.
> > 
> > Could use one of the basic AGUP themes.
> 
> I'd probably go for a more basic Windows-like one. Nothing too flashy,
> which fits in well with most other OS themes. Though I can't say I've
> seen any AGUP themes myself.. any links?

Well, it has a windows-like one, which we could just use. I would
actually have used the Photon one, since it looks best (IMHO). Or the
GTK one, which is more OS-neutral than the windows one.

Screenshots are here: http://agup.sf.net

Or maybe it could just be one of those "official addons", once that idea
gets realized.. but the standard GUI theme really is ugly in any case.

-- 
Elias Pschernig