[Quest-ed-devel] Globalization, and Variable passing in call backs.
Brought to you by:
alexm
|
From: stephen p. <cyb...@ya...> - 2001-08-14 14:29:00
|
>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/ |