Re: [Quest-ed-devel] Couple of 3a notes...

[Malmberg <mal...@ma...>]

>         I started looking through the Quest 3a alpha that was available
> off the website.  It looks really good.  I really like the design.
> Looking at this, implementing a GLUT+GLUI version should be trivial.
> 
>         Two things, off the top of my head:
> 
> 1. The command system uses a callback signature of "void (*func)(void)".
> In my game's command system, I allow for the arguments "int argc" and
> "char **argv", where argv[0] is always the name of the command that caused
> the callback to execute.  I've been very happy with this system, as any
> command can take any kind of argument it wants to, and any number of
> commands.  I don't need any marshallers, because it's up to the command to
> parse its arguments out of argv**.  Furthermore, it makes it easy to do
> things like map a command directly to a system() call, which is always
> fun.
> 
>         I'd recommend using that for Quest's command system.

The current version uses three different types depending on the return
type. The arguments are passed in a list. Syntax is currently really
ugly, but I think it could be reasonably clean with a couple of helper
functions/macros. A bit more trouble, but faster than parsing strings,
and how would you pass eg. a brush in a string in an efficient way?

> 2. The program is currently architected such that Quest provides the
> framework for the main program, with setup calls like
[snip]
>         I need to look at the code some more, but my first impression is
> that this is bass ackwards.  It seems like it would be much easier to have
> Quest export all of its modules/API as a .so (that's .DLL for Windows
> weenies), and then let an individual program worry about its init and
> cleanup however it sees fit.

It was backwards. It's fixed now. main() is in the frontend. It just
needs to call three functions in Quest and then the keyboard/menu/mouse
hooks (called by the frontend) should take care of everything.

> This way I won't be limited to GUI elements like
> 
> int S_GUI_Dialog(const char *title,const char *text, ...);
> void S_GUI_DialogOK(const char *title,const char *format,...);
> int S_GUI_YesNo(const char *title,const char *format, ...);
> int S_GUI_FileDialog(const char *title,const char *button,
>                      const char *wildcard,char *name);

These remain, though. There needs to be some way for the plugins to do
these things. (Actually, they aren't strictly necessary, but you'll lose
a lot of functionality if they aren't there.)

>         Instead, I can use GUI elements like the 3D RollerBall, or maybe
> colorselector, that GLUI provides, and just pass the inputs from my
> widgets to the appropriate Quest function.

The frontend can add things like this through its own plugins.

>         Having a quest.so would also make it easy to link Quest into my
> game, so I can have an in-game editor that shares model data with my game
> engine in realtime.

Possible with the current version (and that's what I currently do,
libquest.so with all the core code, libquest-cmd.so with all the
commands, two executables for the frontends).

>         Anyhow, this is just food for thought.  I hope to take a closer
> look at the source within the next couple of weeks, after Alexanders posts
> his latest code to CVS.
> 
> --Derek S.

- Alexander Malmberg