[Quest-ed-devel] Globalization, and Variable passing in call backs.

[stephen p. <cyb...@ya...>]

>It is true that GLUT has a main loop of its own, and all your code
>must be callbacks to events.  But this is not unusual; practically
>every event handling system is like this. GTK+ is the same way. 

As long as you don't have to maintain timing correctness this is fine
however if you have any time related issues.  I don't see this as a
problem with quest so not a big deal. I just hate having to have
something else have control, I guess it's a perspective of does your
program have control or does GLUT have control. I prefer my program
to have control, too many years of real time control (heh).

>SDL lets you have your own main loop, but that's only because it
>doesn't offer you any events (i.e., widgets).

Which is kind of my prefered way of doing it, widget sets are handy but
they can also be an impedment. In either case it's often best to use 
what you are familiar with and understand well.

>Please "discuse" the problems with GLUT.  It having its own
>control loop is only natural, considering that it gives you menus,
>windows, etc.

Yes and many GUI's allow you to have your own control loop.  I think
the biggest issue really is keeping control in your own loop.  Granted
timing isn't an issue here, but still you can keep things more ordered
in your own loop. I'll have to dig in the cob webs of my brain the
specifics of the problem. Your reaction by the way is not uncommon to
the idea that GLUT is not really ideal for all applications. There is
something about GLUT I'm forgetting, haven't used it in a while, it's a
real anoyance too.

>SDL is an abstract interface between your environment and OpenGL,
>just like glX, GLUT, or that thing Windows uses (wingl?  I dunno what
>it's called.)  

DirectX8 or OpenGL 1.1?

Yes the difference is you can control SDL not visa versa, control can
be big issue especially is something fails in there loop.  Error
recovery I've had hammered into me is more important than the program
looking nice.

>Huh?  WTF are you talking about?  No matter what we'll be writing
>our own interface. But life can be made much simpler by having a
pre-existing widget
>set.  

Yes life is a lot simpler with a pre-existing widget set.  Also the
consistancy across multiple platforms is better. Which is what I was
saying (but sometimes my thoughts just don't get out fast enough)
nothing more anoying than having to rewrite a bunch of GUI function
calls to implement a dialog box, and finding all things are not created
equal between GUI calls. Premade libraries are work already done in
this arena, I always look to see if I can use something already made,
before I start whiping out my own widget set.  Granted it might be
easier to fix my own widget set, but I would consider it a distraction
from the main focus of the project, and using time better spent on
something of greater import to me.

>I thought the string parsing would be really slow, but it's not. 
>Quake uses the same argv/argc system, and it's fast enough for my game
>engine.  For a windowed app like Quest, it would be even less
>noticable. 

Perhaps using the vararg passing convention instead? It's relatively
simple and yet you can identify the elments passed as well.

>-> and how would you pass eg. a brush in a string in an efficient way?

>
>That I don't know.  My stuff grabs all it needs through a single
>global pointer to a "Client" struct, which then provides anything else
>the callback might need.  Entities are referenced via integer indexes
into
>a globally available array, I supposed you could do the same with
brushes. 
>Quake uses all sorts of globals all over the place (which is really
>hard to follow but the same basic idea). --Derek

About globals, you should read the "How to write unmaintainable code"
page. I got a real laugh from it myself.  Anyhow (ahems) I can see
using a global to hold the root structure of the map but, using a
global for passing information can lead for potential trouble. Now
assuming you make no mistakes, and assuming nothing modifies the global
client structure, nothing should go wrong.  Of course even passing a
structure can go wrong, but I think that might be more minimal than
using a global too pass information.  Basically you can possibly forget
variables as globals and or forget what is modify the global and where.
This problem will get worse as the size and scope of the project grows
or how much a hurry you are in.  I've made my share of global messes so
I'm only speaking out of personal disaster. :)

I don't see any problem using vararg for passing the information, this
leaves the number of parameters at 2 (all callbacks in this case are
the same therefore), allows you to pass as many things as you want to a
callback function, and has a well defined methodology to be used. I've
abused varargs in all sorts of odd little functions that would have
been a real pain otherwise.  Most importantly you can pass structures
or strings with the vararg convention. It won't require string parsing
but does incure overhead.

Well that was longer than I wanted to type. Anyhow sounds like you are
thinking that's always a good start, I need to grab quest 3 a code to
look at it myself.

Happy coding :)

Stephen

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/