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

[Derek S. <de...@re...>]

	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.


2. The program is currently architected such that Quest provides the
framework for the main program, with setup calls like

   S_InitSignals();
   S_InitInput();
   S_InitMenu();
   S_InitMessages();
   S_InitToolbar();
   S_InitViewports();
   S_InitTexturePicker();   

	...and clean up code like...

   DoneQuest();

   S_DoneViewports();
   S_DoneInput(); 

	...and then whatever library (GTK+, GLUT, etc.) maps itself into
those functions.

	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.

	As it stands, implementing a new "front end GUI" for Quest really
boils down to writing an all-new main().  I'd rather remove all of these
special init/cleanup requirements, let me write my main() however I see
fit, and just use the structs and functions that Quest already has.  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);       

	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.

	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.

	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.