quest-ed-devel Mailing List for Quest
Brought to you by:
alexm
Menu
▾
▴
quest-ed-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(1) |
Apr
(6) |
May
(4) |
Jun
(20) |
Jul
(2) |
Aug
(14) |
Sep
(27) |
Oct
(3) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(4) |
Feb
(5) |
Mar
(9) |
Apr
(1) |
May
(4) |
Jun
|
Jul
|
Aug
(27) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Malmberg <mal...@ma...> - 2001-09-04 06:53:21
|
> SDL will also give us sound support for free (well, not quite) if we choose to > use it in the entity editor, though the wishlist is perhaps a bit full ATM.. Reworking entity set handling and the entity editor is on the todo-list, and (hopefully; I haven't figured it all out yet, but I'd like it to work) the new code will be able to use a plugin to play sounds. (On Linux, piping the sound to sox might be easier than using SDL, though.) - Alexander Malmberg |
|
From: Remy H. <rh...@br...> - 2001-08-31 02:32:46
|
> > Since SDL doesn't do its own GUI (hence variations in host windowing systems > > not being an issue), porting should be a screwdriver job. > Yes. I think SDL on win32 works better than gtk+ on win32. Just tried GTK + Win2000.. worse than i rememebered.. :( I'll give it another go sometime though.. SDL will also give us sound support for free (well, not quite) if we choose to use it in the entity editor, though the wishlist is perhaps a bit full ATM.. /me needs sleeep... |
|
From: stephen p. <cyb...@ya...> - 2001-08-28 14:06:19
|
> On Fri, Aug 24, 2001 at 12:12:45AM +0200, Malmberg wrote:
> > > Perhaps using the vararg passing convention instead? It's
> relatively
> > > simple and yet you can identify the elments passed as well.
> >
> > The main problem with using varargs is that you can't (easily and
> > portably) construct vararg calls. Since I'm having lots of calls
> between
> > c functions and the lisp-like configurations, I need to be able to
> do
> > that (ie. parsing (foo "zot" 42) to a function pointer, a string
> and an
> > int works fine, but if you want to actually call the function using
> > varargs you'd need a marshaller for every combination of
> arg-types).
>
> not really, if I'm understanding your needs correctly. you can use a
> mechanism similar to vsprintf/vsnprintf. eg:
>
> void my_printf (const char *fmt, ...)
> {
> va_list args;
> char buffer[1024];
>
> va_start (args, fmt);
> vsnprintf (buffer, sizeof (buffer), fmt, args)
> va_end (args);
>
> /* do something with the formatted string in buffer */
> }
>
> I've used this in places in qf. I hope this helps.
>
> Bill
I believe what he's refering to is the fact that he would need to have
a way of determining the objects in the varargs IE functions versus
data etc. If the Lisp engine supported a vararg type call function it
wouldn't probably be so bad.
In his example '(foo "zot" 42)' it's simple and trivial to determine
each arguement. '(' function string int ')'
The functionality would be more like this instead.
Text would pass the type of the arguements IE Function integer or
string etc.
void my_vararg_function(char * Text, ...)
{
va_list args, last;
va_start(args, Text);
last = args;
/*
for each element of Text scan and return the proper arguement
*/
while ((va_arg(last, int)) != 0)
{
// magically find out what the arguement is here :)
// perform the correct type cast
// advance last to args and see if we are done yet
last = args
}
va_end(args);
// we do the next thing
}
It's not simple or trivial to do ... as for what to do that's easier..
donno. vsnprintf knows the types from the arguement parsing of fmt
that's how it handles that. One would have to do the same thing. Again
complicated and lengthy.
Stephen
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
|
|
From: Bill C. <bi...@ta...> - 2001-08-27 03:11:31
|
On Fri, Aug 24, 2001 at 12:12:45AM +0200, Malmberg wrote:
> > Perhaps using the vararg passing convention instead? It's relatively
> > simple and yet you can identify the elments passed as well.
>
> The main problem with using varargs is that you can't (easily and
> portably) construct vararg calls. Since I'm having lots of calls between
> c functions and the lisp-like configurations, I need to be able to do
> that (ie. parsing (foo "zot" 42) to a function pointer, a string and an
> int works fine, but if you want to actually call the function using
> varargs you'd need a marshaller for every combination of arg-types).
not really, if I'm understanding your needs correctly. you can use a
mechanism similar to vsprintf/vsnprintf. eg:
void my_printf (const char *fmt, ...)
{
va_list args;
char buffer[1024];
va_start (args, fmt);
vsnprintf (buffer, sizeof (buffer), fmt, args)
va_end (args);
/* do something with the formatted string in buffer */
}
I've used this in places in qf. I hope this helps.
Bill
--
Leave others their otherness. -- Aratak
|
|
From: Malmberg <mal...@ma...> - 2001-08-26 11:35:18
|
> > (Which I think is quite amazing considering the original 1.* version of > > grid drawing. Every now and then it'd mess up and draw the line from the > > top of the viewport way down past the end of the framebuffer and on top > > of all kinds of other things. If you loaded up the texture selector, you > > could see where the line had passed through the textures! :) Somehow, > > though, it always managed to avoid map data.) > > I suspect it is down to the memory allocation putting the big blocks (ie > images) at higher memory addresses than the map data. Alternativly i'm writing > fiction.. :) I suppose it'd have to be something like that, though it still seems a bit odd. :) [snip] > Since SDL doesn't do its own GUI (hence variations in host windowing systems > not being an issue), porting should be a screwdriver job. Yes. I think SDL on win32 works better than gtk+ on win32. > I'l investigate > since i might also use SDL for the 3D engine i'm writing.. - Alexander Malmberg |
|
From: Malmberg <mal...@ma...> - 2001-08-26 00:23:49
|
Well, not quite weekly. :) Still, if I can't think of anything else to
write, I suppose I could just quote and comment interesting parts of the
ChangeLog for those who don't feel like keeping up with the checkins
mailing list. So:
The cvar system now works as I intended it to, so most of the remaining
changes to the configuration system are high-level things (like giving
the user a way of loading/unloading them). Viewports seem to update
properly, though a few more changes are needed there.
I've updated a bunch of old commands: Quake I support works (though some
things need to be cleaned up), texture setting and the texture picker,
most generic camera commands, selecting and moving stuff, the linear
transformation commands (scaling, rotating, mirroring), the clipboard,
and some other small things. Still lots left, so an easy way to help
would be to pick a file in src/cmd/ and update it (make it compile and
work and add bindings to conf.ql, src/cmd/trans.c is probably a good
reference). Most of them should be easy to update.
> 2001-08-26 01:33 alexm
>
> * src/: cmd/games/qengine/q_tex.c, quest/config.c, quest/ql.c,
> quest/qsymbol.c, quest/qsymbol.h: Made final changes to the cvar
> system. Letting configurations grab cvar:s from the Quest config
> now works properly, as do definitions, defaults, and saved values.
> The system is now working as designed. Updated Quake I support.
>
> 2001-08-25 02:10 alexm
>
> * conf.ql, src/Makefile: Add Quake 1 support and texture selection.
>
> 2001-08-25 02:10 alexm
>
> * src/cmd/games/qengine/: q_tex.c, qmap.c, qmap.h: Update Quake 1
> support.
>
> 2001-08-24 18:14 alexm
>
> * conf.ql, src/Makefile, src/cmd/trans.c, src/cmd/edit/clipboard.c,
> src/cmd/edit/move.c: Add back old commands, update, cleanups.
>
> 2001-08-24 18:14 alexm
>
> * src/cmd/rflags.c: Add back old commands. Changed to use a popup
> for a sortof toggle menu effect.
>
> 2001-08-24 09:49 alexm
>
> * src/Makefile, src/cmd/edit/misc.c, src/cmd/edit/select.c,
> conf.ql: Brought cmd/edit/{misc,select}.c up to date again. Cleaned
> up and added to files Makefile and bindings conf.ql .
>
> 2001-08-23 22:54 alexm
>
> * conf.ql, src/cmd/cam.c: Clean up camera commands, add bindings
> for all of them.
>
> 2001-08-23 22:54 alexm
>
> * src/: fe/gl/render.c, fe/gtk/input.c, quest/edsel.c, quest/sel.c,
> quest/fe/3d.h, quest/fe/render.h: Change S_R_SelUpdate() to generic
> S_R_SetUpdate() and add S_R_HandleUpdate() to make sure viewports
> are updated after commands.
>
> 2001-08-11 18:07 alexm
> Initial revision
- Alexander Malmberg
|
|
From: Remy H. <rh...@br...> - 2001-08-26 00:17:22
|
> How so? I've been using glade with great success. I'm not sure I'd call > it 'integrated', but it's worked fine (modulo gtk+ on win32 problems). Many of the interface designing tools i've come across caused more problems than they solved (even some single-platform ones). However, if you think i'm just being stupid again, you're probably right.. :) > Error handling is done now (at least backend stuff, presentation might > need some work), and works (IMO) really nice, both WRT API and > capabilities. It was intended as a more general point, although i had forgotten how much of a forethought on error recovery had been made.. :/ > (Which I think is quite amazing considering the original 1.* version of > grid drawing. Every now and then it'd mess up and draw the line from the > top of the viewport way down past the end of the framebuffer and on top > of all kinds of other things. If you loaded up the texture selector, you > could see where the line had passed through the textures! :) Somehow, > though, it always managed to avoid map data.) I suspect it is down to the memory allocation putting the big blocks (ie images) at higher memory addresses than the map data. Alternativly i'm writing fiction.. :) > SDL doesn't have any GUI features; ah. thought so. > in this context, it just provides a > portable way to get an OpenGL window on the screen, and receive events. > Still, I think an SDL/OpenGL frontend is a really good idea. OpenGL's > performance with v2.*'s GUI and keyboard handling would be a nice > combination, and probably quite portable to win32. Since SDL doesn't do its own GUI (hence variations in host windowing systems not being an issue), porting should be a screwdriver job. I'l investigate since i might also use SDL for the 3D engine i'm writing.. |
|
From: Malmberg <mal...@ma...> - 2001-08-23 22:50:19
|
> Since we want portability between X and W32, i doubt there's any hope of a > suitable interface designing tool coming along. How so? I've been using glade with great success. I'm not sure I'd call it 'integrated', but it's worked fine (modulo gtk+ on win32 problems). > I suspect that is because error handling tends to be pushed into a back seat, > by which point, we've limited what we can do. Error handling is done now (at least backend stuff, presentation might need some work), and works (IMO) really nice, both WRT API and capabilities. > Anyone else remember losing Doom levels because of 16-bit version of DEU running > out of memory..? :) All too well! However, in all the time I've used and worked on Quest, I've only lost data due to a crash once. (Which I think is quite amazing considering the original 1.* version of grid drawing. Every now and then it'd mess up and draw the line from the top of the viewport way down past the end of the framebuffer and on top of all kinds of other things. If you loaded up the texture selector, you could see where the line had passed through the textures! :) Somehow, though, it always managed to avoid map data.) > I think we are only using OpenGL for map view drawing. I suspect using OpenGL > for everything will be rather painful. If SDL (which i don't know well) has > any GUI features (like GTK has), then it'll be worth a look. SDL doesn't have any GUI features; in this context, it just provides a portable way to get an OpenGL window on the screen, and receive events. Still, I think an SDL/OpenGL frontend is a really good idea. OpenGL's performance with v2.*'s GUI and keyboard handling would be a nice combination, and probably quite portable to win32. - Alexander Malmberg |
|
From: Malmberg <mal...@ma...> - 2001-08-23 22:50:14
|
> Perhaps using the vararg passing convention instead? It's relatively > simple and yet you can identify the elments passed as well. The main problem with using varargs is that you can't (easily and portably) construct vararg calls. Since I'm having lots of calls between c functions and the lisp-like configurations, I need to be able to do that (ie. parsing (foo "zot" 42) to a function pointer, a string and an int works fine, but if you want to actually call the function using varargs you'd need a marshaller for every combination of arg-types). - Alexander Malmberg |
|
From: Remy H. <rh...@br...> - 2001-08-16 15:59:49
|
On Fri, 10 Aug 2001, you wrote: > Well GTK isn't too bad. GTK+ is a little immature but still I believe > Borland supports this now (via Klyx interface for delphi and in > december for C++). GTK's biggest weakness is a lack of integration of > form generating tools with actual coding tools and a compilor. Yes this > seems trivial but it's not, many programers are spoiled with VC++ and > Visual Basic. :) Since we want portability between X and W32, i doubt there's any hope of a suitable interface designing tool coming along. > CVS source only? that explains the quietness of the discussion list. I > remember the last discusion was error handling gracefully. I think we > concluded we get what we get with error handling (chuckles). I suspect that is because error handling tends to be pushed into a back seat, by which point, we've limited what we can do. Anyone else remember losing Doom levels because of 16-bit version of DEU running out of memory..? :) > GLUT is dangerous only use if you have to. GLUT has some serious > control issues unfortunately. Once you call the main GLUT loop, don't > call it, it will call you. This can lead to control issues that I don't > want to discuse. Its been a long time since i last used Glut, but i think it also suffers from a lot is minimalism. Would be good for portability, but the price is a bit high rom my POV. > OGL is fine I suppose but you can call OGL from SDL I think that is > better. I think we are only using OpenGL for map view drawing. I suspect using OpenGL for everything will be rather painful. If SDL (which i don't know well) has any GUI features (like GTK has), then it'll be worth a look. |
|
From: Remy H. <rh...@br...> - 2001-08-16 15:59:28
|
> nothing wrong with renaming files in cvs, other than it's a bit of a hassle Problem is that if you are moving a lot of files around, you may as well start a new project, as the moving does not maintain pre-moving updates. |
|
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/ |
|
From: Derek S. <de...@re...> - 2001-08-12 00:59:10
|
-> 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, 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. -> 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 |
|
From: Malmberg <mal...@ma...> - 2001-08-11 23:06:05
|
OK, I've uploaded the latest source to http://w1.423.telia.com/~u42303319/quest-3.tar.bz2 (180k) and it's in the SF cvs in the module quest-3b. Edit src/Config.mk (specifically, fix the .so path or switch to static linking by commenting/uncommenting the relevant parts) and run make in src/ and it should compile. There are some documents about it in doc/. It doesn't really do much right now. You can start it and create brushes and move around, but the display won't automatically be refreshed, so you'll need to drag the window off the screen and back again to see the changes. I'll try to make it at least somewhat useful as soon as I can (next couple of days, hopefully). If anyone has any questions about some part of the source, ask and I'll try to explain. - Alexander Malmberg |
|
From: Malmberg <mal...@ma...> - 2001-08-11 23:06:05
|
> 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 |
|
From: Derek S. <de...@re...> - 2001-08-11 02:39:51
|
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.
|
|
From: Derek S. <de...@re...> - 2001-08-10 22:11:57
|
-> SDL actually looks good. It's worked great for my Quake2 game engine. -> GLUT is dangerous only use if you have to. GLUT has some serious -> control issues unfortunately. Once you call the main GLUT loop, don't -> call it, it will call you. This can lead to control issues that I don't -> want to discuse. It's been discused on the Worldforge client lists -> already. Just think of it this way, IT has control not your program. 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. SDL lets you have your own main loop, but that's only because it doesn't offer you any events (i.e., widgets). Please "discuse" the problems with GLUT. It having its own control loop is only natural, considering that it gives you menus, windows, etc. -> OGL is fine I suppose but you can call OGL from SDL I think that is -> better. 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.) -> Custom is ok.. just realize that YOU have to support the interface, and -> the interface won't support you. It makes things very difficult to -> maintain then. 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. I'm leaning towards the GLUI stuff... hopefull this weekend I can play around with it a little bit. --Derek |
|
From: stephen p. <cyb...@ya...> - 2001-08-10 19:11:22
|
Well GTK isn't too bad. GTK+ is a little immature but still I believe Borland supports this now (via Klyx interface for delphi and in december for C++). GTK's biggest weakness is a lack of integration of form generating tools with actual coding tools and a compilor. Yes this seems trivial but it's not, many programers are spoiled with VC++ and Visual Basic. :) CVS source only? that explains the quietness of the discussion list. I remember the last discusion was error handling gracefully. I think we concluded we get what we get with error handling (chuckles). Oh and someone asked what was happening too. SDL actually looks good. GLUT is dangerous only use if you have to. GLUT has some serious control issues unfortunately. Once you call the main GLUT loop, don't call it, it will call you. This can lead to control issues that I don't want to discuse. It's been discused on the Worldforge client lists already. Just think of it this way, IT has control not your program. OGL is fine I suppose but you can call OGL from SDL I think that is better. A standard interface makes things more managable when something goes beyond the scope of one person. Standards are important. Qt is Ok, I just don't use it. Custom is ok.. just realize that YOU have to support the interface, and the interface won't support you. It makes things very difficult to maintain then. Stephen __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ |
|
From: Bill C. <bi...@ta...> - 2001-08-10 04:53:25
|
On Fri, Aug 10, 2001 at 02:57:37AM +0200, Malmberg wrote: > Certainly not. Now is probably a good time to experiment with different > frontends, and the OpenGL renderer is supposed to be easy to reuse. > Anyway, I'll upload my latest version somewhere tomorrow, and I suppose > I'll import it as a new cvs module as well (and hope I don't decide to > rename all the files again). nothing wrong with renaming files in cvs, other than it's a bit of a hassle mv foo bar cvs rm foo cvs add bar cvs ci Bill -- Leave others their otherness. -- Aratak |
|
From: Malmberg <mal...@ma...> - 2001-08-10 01:03:00
|
> -> Development is now on the GTK-based Quest v3, which has yet to have support > -> for various game added. I think it is currently only available via CVS. > > This is something I'd like to scrutinize. > > I've seen the beta of the GTK+ version that Alexander released > many months ago. It still had much work to be done. The Windows version > promptly crashed on me :) The win32 port of gtk+ wasn't that great, at the time. I don't know if it's better now. > If litte/no development work has gone into that tree since the > beta (as indicated by the website), I'd like to consider some other > options: There has been a fair amount of work on it since the beta. Most of the necessary code is there. However, Quest v3 is supposed to be able to have many frontends, and this seems to work (I've been using a pure text frontend for easy testing), so it should be fairly easy to add more of them. > 1. GLUT. It's easier to maintain, less code, and more popular than GTK+, > i.e., more 3D/game developers are already familiar with it. It would work, but you'd have to write your own OpenGL-based GUI. Might not be too bad. Does glut support multiple windows? > 2. GLUI. Based on (and requiring) glut, GLUI is a complete (fancy!) > widget set that renders directly to OpenGL. I've never used it, but it > looks very cool. Like GTK+, it looks the same everywhere--and it's OpenGL > accellerated! (Unfortunately it's C++ code.) c++ in the frontend shouldn't be a problem. > 3. Pure OpenGL for the GUI, and something like SDL for system-independence > and portability. The 2.4 line did its own menus and GUI rendering, > avoiding all special widget libraries altogether. Personally, I find that > to be very cool. Blender is this way, as was Gig3D before it. The nice > thing is that we could make non-X windows SVGAlib binaries, which really > appeals to me (and now SDL supports PlayStation 2, whoop!). Also, it > avoids all the Window Manager and MDI bullshit that comes with a prefab > widget set. True, custom GUI:s have always been better, and the v2.4 GUI will remain as a frontend, if only for the DOS/svgalib version. Supporting extra 'frontend-backends' like SDL shouldn't be too hard. Last I checked, SDL didn't support multiple windows, which is annoying. I would like to support dragging popup windows out of the way. > 4. Of course, I really love GTK+, so we shouldn't forget about that, too > :) (I have no real interest in Qt.) gtk+ is really nice for the dialogs. Maybe a hybrid would be useful, one big OpenGL window for all the viewports, and gtk+ for the GUI in dialogs? > I'd like to look at all of these options, but if Alexander is > still actively involved I'd like to hear what he has to say. Perhaps it's > too late to think about these again. Certainly not. Now is probably a good time to experiment with different frontends, and the OpenGL renderer is supposed to be easy to reuse. Anyway, I'll upload my latest version somewhere tomorrow, and I suppose I'll import it as a new cvs module as well (and hope I don't decide to rename all the files again). > FYI, Quest is about to become very important to me. I have 11,000 > lines of code in a [Linux compatible] game engine I've written, and I want > Quest to be the de facto editor for my SDK (with Blender being the > modeller). So I'm willing to put the time and effort into one of the > above, at least for the next few months. > > Thanks, > Derek Simkowiak > de...@re... - Alexander Malmberg |
|
From: Malmberg <mal...@ma...> - 2001-08-10 01:03:00
|
> Is this list still alive? What's the current status on Quest? (I > notice the website hasn't been updated in many months...) Well, v2.4 still works fine for actually getting some mapping done. My latest v3-alpha is very low on functionality, but the architecture is very nice (and mostly finished). Most of the remaining work is rewriting all old stuff to work with the new version, and generally getting things to work again. There's bound to be at least a few major problems, but it should be possible to solve them (ugly hacks, at worst). > I'm about to dump some time into Quest, possibly development time. > Seems like priority #1 is Half Life and Q3 support. I want to know what > people think... 2.4 supports both Halflife and Quake 3. What will become v3.0 currently supports Quake and Quake 3, but those are the only complicated ones. Adding support for Halflife or Quake 2 would be fairly easy. > Thanks, > Derek Simkowiak - Alexander Malmberg |
|
From: Derek S. <de...@re...> - 2001-08-09 17:58:23
|
-> Development is now on the GTK-based Quest v3, which has yet to have support -> for various game added. I think it is currently only available via CVS. This is something I'd like to scrutinize. I've seen the beta of the GTK+ version that Alexander released many months ago. It still had much work to be done. The Windows version promptly crashed on me :) If litte/no development work has gone into that tree since the beta (as indicated by the website), I'd like to consider some other options: 1. GLUT. It's easier to maintain, less code, and more popular than GTK+, i.e., more 3D/game developers are already familiar with it. 2. GLUI. Based on (and requiring) glut, GLUI is a complete (fancy!) widget set that renders directly to OpenGL. I've never used it, but it looks very cool. Like GTK+, it looks the same everywhere--and it's OpenGL accellerated! (Unfortunately it's C++ code.) 3. Pure OpenGL for the GUI, and something like SDL for system-independence and portability. The 2.4 line did its own menus and GUI rendering, avoiding all special widget libraries altogether. Personally, I find that to be very cool. Blender is this way, as was Gig3D before it. The nice thing is that we could make non-X windows SVGAlib binaries, which really appeals to me (and now SDL supports PlayStation 2, whoop!). Also, it avoids all the Window Manager and MDI bullshit that comes with a prefab widget set. 4. Of course, I really love GTK+, so we shouldn't forget about that, too :) (I have no real interest in Qt.) I'd like to look at all of these options, but if Alexander is still actively involved I'd like to hear what he has to say. Perhaps it's too late to think about these again. FYI, Quest is about to become very important to me. I have 11,000 lines of code in a [Linux compatible] game engine I've written, and I want Quest to be the de facto editor for my SDK (with Blender being the modeller). So I'm willing to put the time and effort into one of the above, at least for the next few months. Thanks, Derek Simkowiak de...@re... |
|
From: Remy H. <re...@re...> - 2001-08-09 02:38:22
|
On Wed, 08 Aug 2001, you wrote: > Is this list still alive? What's the current status on Quest? (I > notice the website hasn't been updated in many months...) It goes quiet every now and then. > I'm about to dump some time into Quest, possibly development time. > Seems like priority #1 is Half Life and Q3 support. I want to know what > people think... Most of the work in supporting various games will be writing config files (eg entity lists), rather than adding extra code to Quest. Much of the internal stuff is game independent (as long as it uses a Quake engine). |
|
From: Remy H. <re...@re...> - 2001-08-09 02:38:18
|
>I thought Half Life and > Quake 3 support was > already in Quest ? (running on old 2.3 or 2.4 I think) Development is now on the GTK-based Quest v3, which has yet to have support for various game added. I think it is currently only available via CVS. |
|
From: Martin F. <m.r...@we...> - 2001-08-08 22:59:18
|
At 15:02 08.08.01 -0700, you wrote: > Is this list still alive? What's the current status on Quest? (I >notice the website hasn't been updated in many months...) > > I'm about to dump some time into Quest, possibly development time. >Seems like priority #1 is Half Life and Q3 support. I want to know what >people think... > > >Thanks, >Derek Simkowiak i'm still listening : ) but i don't know more than the lack of updates... so maybe a few me-too's? maybe from alex? cheers, martin fuchs |
