From owner-quake-dev-digest@gamers.org Wed May 8 12:18 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id MAA04436 for ; Wed, 8 May 1996 12:17:29 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id GAA18890 for quake-dev-digest-outgoing; Wed, 8 May 1996 06:16:50 -0400 From: owner-quake-dev-digest@gamers.org Date: Wed, 8 May 1996 06:16:50 -0400 Message-Id: <199605081016.GAA18890@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #6 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 26047 X-Lines: 677 Status: RO quake-dev-digest Wednesday, 8 May 1996 Volume 01 : Number 006 ---------------------------------------------------------------------- From: Bernd Kreimeier Date: Fri, 26 Apr 1996 23:04:58 +0200 (MET DST) Subject: ADMIN: reminder Reminder and warning: this mailing list does not, and cannot cover basics and well-documented graphics algorithms as source and in detail. I recommend the newsgroups comp.graphics.algorithms (FAQ) rec.games.programmers and the "recommended readings" listed on the QuakeDev support pages. The list is currently (despite the volume) low traffic, as compared to what we will face once Quake shareware is out. Any subscriber of this list should be aware that I am not able and willing to provide reminders, warnings and hints once the traffic (and the delivery failure bounces I am facing every day) increases. I expect every subscriber to read and stick to the posting guidelines. As soon as this list drowns in chats and talks, I will have to close and unsubscribe w/o warning. b. ------------------------------ From: Jim Bucher Date: Fri, 26 Apr 1996 16:26:15 -0500 Subject: Re: rendering question Thanks for the reply Jens. I am came up with this piece of code and it seems to work. Tell me if you think this is right. You need to pass the root node index as a parameter. curLeaf is a global variable that contains the leaf that the camera is in. void GetPos (short index) { Plane plane; while (index >= 0) { plane = planes[nodes[index].planeNum]; if (position.Dot (plane.normal) < plane.distance) index = nodes[index].back; else index = nodes[index].front; if (index < 0) { index = ~index; curLeaf = index; } } } ------------------------------ From: Squirrel Eiserloh Date: Sun, 21 Apr 1996 16:42:10 -0500 (EST) Subject: Re: Front or Back node? > I currently make a little program to display a wire frame of the quake levels. > But now i want know how can you decide if the camera is in the front or in the > back part of the plane that splits the node. A plane is defined by (A,B,C,D), where (A,B,C) are both the coordinates of the normal vector AND the co-efficients of the algebraic plane formula (Ax + By + Cz + D = 0 :: D is the shift/slide/offset). You know A, B, C, D. Plug in (x, y, z) of the camera and solve for d (so, actually the equation is Ax + By + Cz + D + d = 0). The decision you want (front vs. back) will be based on whether "d" is positive or negative, but I'm too braindead at the moment to figure out which. Basically, you're solving for d to find out "how much and which way" you would have to slide/offset the plane to get to your camera point. The +/- sign of that d-offset tells which way you had to slide the plane to get there, ergo on which side of it you are. Email me if you have any questions about this. ============================================================================= Brian "Squirrel" Eiserloh "The average woman would rather have squirrel@css.tayloru.edu beauty than brains, because the average www.css.tayloru.edu/squirrel man can see better than he can think" ============================================================================= ------------------------------ From: Jim Bucher Date: Fri, 26 Apr 1996 17:53:01 -0500 Subject: Re: rendering question void GetPos (short index) { Plane plane; while (index >= 0) { plane = planes[nodes[index].planeNum]; if (position.Dot (plane.normal) < plane.distance) index = nodes[index].back; else index = nodes[index].front; if (index < 0) curLeaf = ~index; } } The last piece of code I posted will get stuck in an infinite loop. Here is the correct version. ------------------------------ From: Bernd Kreimeier Date: Mon, 29 Apr 1996 10:54:24 +0200 (MET DST) Subject: Quake Developers Pages down The Quake Developers support pages will probably be unreacheable for the time being. The university I happen to be employed by is currently establishing regulations that will prohibit any private use, and already do prohibit even voluntary publication of office phone, address, e-mail, or department membership. In case you are wondering: this is a german university. The pages will be accessible again as soon as I have succeeded in transfering the pages to a new location. Any important piece of info in the meantime will be forwarded to the list. b. - ---------------------------------------------------------------- "Wo die Sonne der Kultur niedrig steht, werfen auch Zwerge lange Schatten" - ---------------------------------------------------------------- ------------------------------ From: Guy Gustavson Date: Tue, 30 Apr 1996 17:05:21 -0500 Subject: Re: Quake Developers Pages down Bernd Kreimeier wrote: > > The Quake Developers support pages will probably be unreacheable > for the time being. The university I happen to be employed by > is currently establishing regulations that will prohibit any > private use, and already do prohibit even voluntary publication > of office phone, address, e-mail, or department membership. In > case you are wondering: this is a german university. > > The pages will be accessible again as soon as I have succeeded > in transfering the pages to a new location. Any important piece > of info in the meantime will be forwarded to the list. > If you're looking for a machine to host the mailing list on I'd happily set you up an account on stomped.com. I'd ask that you still manage the list though, as I just don't have the time. ------------------------------ From: Bernd Kreimeier Date: Tue, 7 May 1996 15:25:44 +0200 (MET DST) Subject: Quake Developers Pages The Quake Developers support pages have found a new home, at http://www.gamers.org/dEngine/ I am currently reworking the pages and fixing the bugs and danglings links on the way. For the time being, please do not use any bookmarks except the main page, and my apologies for any inconvenience. The Quake related stuff is mostly done already, the pages missing should be up next weekend. In addition, the redirection mechanism I relied on at the former location did not work correctly, again my apologies to anybody who got "lost in Hyperspace". Please report any serious problems you are encountering at the new location to me. b. ------------------------------ From: Bernd Kreimeier Date: Tue, 7 May 1996 17:32:43 +0200 (MET DST) Subject: Porting QuakeEd? Quoting John Carmack: "QuakeEd is written for NEXTSTEP 3.3, while GnuStep is an implementation of the OPENSTEP spec. I haven't had time to port it to openstep yet, but it looks like it will take a little effort. NeXT has tools in NS 4.0 to help, but it still isn't automatic." The GNU GCC (and possibly DJGPP) supports ObjectiveC, and GNUstep is free software, see http://www.gnustep.org/ (US) http://www.NMR.EMBL-Heidelberg.de/GNUstep/ (european mirror) Quote from FAQ: "Base Library 85% done, GUI library 25% done". Add to this said differences between NS 3.3 and OS/NS 4.0, and the prospect of re-building QuakeEd using GNU GCC and GNUstep does not look to promising - way too early, I guess. However, ObjectiveC and NextStep references might be handy once QuakeEd should be ported to C++ and another GUI - see http://www.next.com/Pubs/Documents/OPENSTEP/ObjectiveC/objctoc.htm for ObjectiveC online reference, and http://www.next.com/Pubs/Documents/OPENSTEP/OpenStep.html for OpenStep online reference (and NextStep docs ordering info). There is a NeXTSTEP-alike window manager, "BowMan", based on "fvwm" at http://www-acs.ucsd.edu/~byang/bowman/, and a successor, "AfterStep", at http://woodward-52.rh.uchicago.edu/~frank/afterstep/, which might or might not be useful with regard to porting QuakeEd. Hope this is exhaustive :-) info for anybody planning on porting QuakeEd. b. ------------------------------ From: Bernd Kreimeier Date: Tue, 7 May 1996 18:05:21 +0200 (MET DST) Subject: The GUI of Choice? There is one thing about (prospective) writing of Quake Editing tools that is perfectly annoying IMO - namely which library or toolkit to rely on for doing the GUI. Point in case: QuakeEd, see related "Porting QuakeEd?" posting. However, things are not different for those of us starting from scratch. There is a good overview of freely available builders, toolkits and libraries at http://www-ocean.tamu.edu/~baum/graphics-GUI.html I have read and re-read the list, keeping in mind certain requirements (your mileage may vary): + Linux/X support + freely distributable sources & widgets + no OSF Motif required (optional is okay) + C++ or C, no scripts + preferably includes interface builder/editor + NT support higly desirable for cross-development + allow for Mesa/OpenGL and GLUT use and still have not taken a decision. I imagine that others are facing the same problem, and would like to see suggestions and comments. There are a few published "Quake Editor" projects I have seen so far (thanks to afterShock): Shaker - http://www.canweb.net/~fisty/shaker/, (formerly "QED", formerly using "AfterStep", now using XForms (see http://bragg.phys.uwm.edu/xforms/) QMapHack - http://www.eve.net/~rshields/, (Windows) QEU - http://www.montefiore.ulg.ac.be/~quinet/games/QEU/, no GUI mentioned, but I remember a home-brew SWAPI... omitting the MDL tools written for DO(W)S, of course, whose authors might want to share some insights, too. Anybody? b. P.S.: somebody asked whether GUI issues are on topic - my apologies for not getting back to this earlier, but guess here's the answer ;-). P.P.S.: I briefly considered a Java GUI (running as a separate process/thread), but abandoned the idea as the AWT is reportedly not a good choice. Anybody knowing a good toolkit that allows for a Native C (C++?) wrapper? ------------------------------ From: "Brian K. Martin" Date: Tue, 7 May 1996 13:40:04 -0400 (EDT) Subject: Re: The GUI of Choice? > > omitting the MDL tools written for DO(W)S, of course, whose > authors might want to share some insights, too. Anybody? > > b. I've spent some time now writing a gui for meddle (mdl tool). It isn't the funnest thing. It is a c++ (djgpp) gui for use with grx20 lib. If i ever finish, i'll include all source with the next meddle release. I started off using sword, which is nice, but not quite the right type of gui. I am planning on coding in windows as soon as I get an new hard disk. IMO, the gui makes or breaks an editor. In terms of newbies using an editor, only the best gui's will survive. Now die hards will write levels with an ascii editor, or will spend several hours learning the editor (like the original deus). So i am as eager as anyone to hear about a gui if you have any suggestions. brian ------------------------------ From: "Dark Shadow" Date: Tue, 7 May 1996 17:45:03 -0400 Subject: RE: The GUI of Choice? > IMO, the gui makes or breaks an editor. In terms of newbies using an > editor, only the best gui's will survive. Now die hards will write > levels with an ascii editor, or will spend several hours learning the > editor (like the original deus). So i am as eager as anyone to hear about > a gui if you have any suggestions. > > brian I personally agree with that statement (GUI making/breaking an editor). Part of the reason why current DOOM editors such as DCK, DEU for Win, and to some extent Waded are so popular is because they offer a GUI interface with organized menu structures and easy to use features. Personally I really couldn't stand the early DEUs, but I loved the first one for Windows. Also, although people scream at me when I suggest vis-bas 4 pro for an editor, the fact is that making a truly GUI-type, friendly interface is really child's play using ANY version of VB. As for the shouts that VB is slow as hell when compared to C++ etc (which is definitely true), external DLL files can be used for the functions needing speed (as you might have seen in earlier versions of Wintex which used LBWINTEX.DLL for external wad hacking functions). One of the advantages of using the 32-bit edition of VB is that it's much faster than its predecessors, and I think that it would now be possible to write a decent editor and / or utility using VB as an interface shell and using external DLL's for the actual hack and slash of the wads. Having said that, I've never really liked C/C++. Sure it's fast, but for most people who aren't necessarily computer science doctorates, C has a sharp learning curve. So we have to rely on a few geniuses in the field of C to write programs that don't crash and run correctly The best way to encourage development of good editors and utilities, in my estimation, is for a few of you C gurus to whip up some DLL's which cover basic needs for a utility, for instance, a DLL which functions like Meddle. Then you get the VB people like myself to write interfaces using those DLL's. So what's the result? The end result is a easy to use while slower program, but which is more advantageous? Speed, or ease of use? If you make a bad-ass editor that's 10,000x faster than what I wrote in vis-bas, sure, it's great, but only you and the people you force-fed it onto :) will know how to use it. The long lasting editors are the ones which combine all of the above (ease of use, speed, etc) into one package, and don't advance one end (speed) at the expense of the other (ease of use). - -j ------------------------------ From: Barry D Bloom Date: Tue, 7 May 1996 19:00:22 -0500 (CDT) Subject: RE: The GUI of Choice? On Tue, 7 May 1996, Dark Shadow wrote: > Also, although people scream at me when I suggest vis-bas 4 pro for an > editor, the fact is that making a truly GUI-type, friendly interface is > really child's play using ANY version of VB. As for the shouts that VB is > slow as hell when compared to C++ etc (which is definitely true), external > DLL files can be used for the functions needing speed (as you might have > seen in earlier versions of Wintex which used LBWINTEX.DLL for external > wad hacking functions). One of the advantages of using the 32-bit edition > of VB is that it's much faster than its predecessors, and I think that it > would now be possible to write a decent editor and / or utility using VB > as an interface shell and using external DLL's for the actual hack and > slash of the wads. Are you actually proposing writiing a 3D Wireframe real time editor in Visual Basic? HAHAHAHAHAHA! I'm sorry, that was rude. Really now, have you ever tried to write a real world app (as opposed to a little applet) in Visual Basic? VB is purely a tool for interface *design*. Trying to write a complete application in it is a waste of time. Especially if it is at all graphically intensive. At my real job, we started an Internet application for windows. By the time it was functional, it was so dog slow that it was unusable. We had plenty of external DLL's doing the grungy stuff. It didn't matter if it took the screen 2 secs for your form to update. [stuff about the difficulties of C deleted] Anyway, I admire your gumption, however, if a compromise is what you are looking for, then Visual C++ really is the choice. MFC is no bed of roses for sure, but many of the visual aspects of VB are present in some capactiy in VC4. Dialog boxes and the like are quite easy to design and program. Even GDI manipulations are relatively simple once you grasp the concept of the device context in the framework of the CDC class. Personally, I think it is going to take a Direct Draw appliction to acheive the ultimate goal of 3D Preview. I have done some preliminary testing with the Game SDK, and I can tell you that 640x480 full screen Quake-like apps will scream. So, a 1/4 of screen preview window should surely be doable. Barry Bloom bdb0004@jove.acs.unt.edu - ------------------------ ------------------------------ From: The Dewb <72614.2725@CompuServe.COM> Date: 07 May 96 20:25:50 EDT Subject: RE: The GUI of Choice? >Also, although people scream at me when I suggest vis-bas 4 pro for an >editor, the fact is that making a truly GUI-type, friendly interface is >really child's play using ANY version of VB. As for the shouts that VB is >slow as hell when compared to C++ etc (which is definitely true), external ... >Having said that, I've never really liked C/C++. Sure it's fast, but for >most people who aren't necessarily computer science doctorates, C has a >sharp learning curve. So we have to rely on a few geniuses in the field Expanding on this argument [not to be a walking MS advertisement, but avoiding it is becoming hard.. :) ] Visual C++ 4.0 is just as easy as visual basic with much more power and flexibility. In fact, with the new Foundation Classes (which admittedly _do_ represent a large learning curve) the GUI pretty much writes itself. VC even includes OpenGL support and lots of other nifty stuff that would help out in an editor project. >DLL which functions like Meddle. Then you get the VB people like myself >to write interfaces using those DLL's. So what's the result? The end This is actually a good idea, but stuff like this never seems to happen. ------------------------------ From: Jim Lowell Date: Tue, 07 May 1996 21:38:06 -0500 Subject: Quake Development Tools (was RE: The GUI of Choice?) At 08:25 PM 5/7/96 EDT, you wrote: >>Also, although people scream at me when I suggest vis-bas 4 pro for an >>editor, the fact is that making a truly GUI-type, friendly interface is >>really child's play using ANY version of VB. As for the shouts that VB is >>slow as hell when compared to C++ etc (which is definitely true), external >... >>Having said that, I've never really liked C/C++. Sure it's fast, but for >>most people who aren't necessarily computer science doctorates, C has a >>sharp learning curve. So we have to rely on a few geniuses in the field > >Expanding on this argument [not to be a walking MS advertisement, but avoiding >it is becoming hard.. :) ] Visual C++ 4.0 is just as easy as visual basic with >much more power and flexibility. In fact, with the new Foundation Classes >(which admittedly _do_ represent a large learning curve) the GUI pretty much >writes itself. VC even includes OpenGL support and lots of other nifty stuff >that would help out in an editor project. > >>DLL which functions like Meddle. Then you get the VB people like myself >>to write interfaces using those DLL's. So what's the result? The end > >This is actually a good idea, but stuff like this never seems to happen. Personal opinion follows: I gotta jump in here. I've been using Borland's Delphi since day one and have yet to find anything that it can't do as easier than VB and just as quick as VC++. I don't think there would be any disadvantages to using Delphi to develop a Quake editor, and I've always considered it (Pascal) superior to C just because the finished code is generally far more legible and therefore maintainable. VB is definatly out though, too much overhead to do anything usefull. If it was between VC and VB, I'd be writing C code in a heartbeat. :) Just my two cents. - -= Jim Lowell =- ------------------------------ From: Matt Houser Date: Tue, 7 May 1996 23:37:06 -0400 (EDT) Subject: Re: The GUI of Choice? Just to straighten some stuff up... I've been working on Shaker for some time... it was said that I use AfterStep for it's development... not ture... AfterStep is a window manager for X... plain and simple... Ok... real business, I chose to use xforms for development beause it has most of the features looked for (previous message mentioned these) + Linux/X support + freely distributable sources & widgets + no OSF Motif required (optional is okay) + C++ or C, no scripts + preferably includes interface builder/editor + NT support higly desirable for cross-development + allow for Mesa/OpenGL and GLUT use With the exception of the NT portability, xforms has all this, which makes it good... because I don't have NT to test and NT version on... ...Matt BTW: shaker's url is http://www.canweb.net/~fisty/shaker/ if you want to check it out - -- ================================================================== Matt Houser IRC: Fisty email: mwhouser@interlog.com, mwhouser@undergrad.math.uwaterloo.ca URL: http://www.undergrad.math.uwaterloo.ca/~mwhouser - -- "After all this time, fruit salid still starts with an 'F'!" ------------------------------ From: "Dark Shadow" Date: Wed, 8 May 1996 06:06:59 -0400 Subject: RE: The GUI of Choice? - ---------- > From: Barry D Bloom > To: quake-dev@gamers.org > Are you actually proposing writiing a 3D Wireframe real time editor in > Visual Basic? > HAHAHAHAHAHA! > > I'm sorry, that was rude. > > Really now, have you ever tried to write a real world app (as opposed to > a little applet) in Visual Basic? VB is purely a tool for interface > *design*. Trying to write a complete application in it is a waste of > time. Especially if it is at all graphically intensive. Yes sir, lots of them, mostly for my own use. I wrote an AOL program (hasn't everyone!), a FTP application, and a very very rudimentary telnet app (it really sux in my opinion, but it's better than the telnet.exe that comes with winblows 95). > At my real job, we started an Internet application for windows. By the > time it was functional, it was so dog slow that it was unusable. We had > plenty of external DLL's doing the grungy stuff. It didn't matter if it > took the screen 2 secs for your form to update. Not necessarily. The screen updatings were really quite a problem with vis-bas 3, 16-bit. Not only is vb4 a complete 32-bit package, but it's also MUCH MUCH MUCH faster than it's predecessors. > Anyway, I admire your gumption, however, if a compromise is what you are > looking for, then Visual C++ really is the choice. MFC is no bed of > roses for sure, but many of the visual aspects of VB are present in some > capactiy in VC4. Dialog boxes and the like are quite easy to design and > program. Even GDI manipulations are relatively simple once you grasp the > concept of the device context in the framework of the CDC class. Hmm. Yeah, I certainly like VC++. And i certainly agree about MFC being no bed of roses, it's much like a bed of thorny roses that you ocasionally get stuck in :) > Personally, I think it is going to take a Direct Draw appliction to > acheive the ultimate goal of 3D Preview. I have done some preliminary > testing with the Game SDK, and I can tell you that 640x480 full screen > Quake-like apps will scream. So, a 1/4 of screen preview window should > surely be doable. Well of course they will, SDK is one of the better Microsoft contributions to the world, but most of the SDK functions can be accessed through vis-bas API calls or other external functions with as little loss of speed as possible. Mabye I ought to demonstrate this fact and whip something up. > Barry Bloom > bdb0004@jove.acs.unt.edu > ------------------------ > > > ------------------------------ From: "Dark Shadow" Date: Wed, 8 May 1996 06:09:51 -0400 Subject: RE: The GUI of Choice? > Expanding on this argument [not to be a walking MS advertisement, but avoiding > it is becoming hard.. :) ] Visual C++ 4.0 is just as easy as visual basic with > much more power and flexibility. In fact, with the new Foundation Classes > (which admittedly _do_ represent a large learning curve) the GUI pretty much > writes itself. VC even includes OpenGL support and lots of other nifty stuff > that would help out in an editor project. Yes, I have to agree. Even your rudimentary C++ packages have more power and flexibility than vis-bas. The whole reason, however, that vb was written, is to allow users who like the high-level programming language of Form1.Visible rather than void void void. Yes, you are right, I've seen vc 4 and the learning curve isn't really a curve, it's more like a spike. > >DLL which functions like Meddle. Then you get the VB people like myself > >to write interfaces using those DLL's. So what's the result? The end > > This is actually a good idea, but stuff like this never seems to happen. Well, mabye I can convince some of my C guru friends to actually develop some. If I ever do get my hands on the DLL's, you can be sure I'll write the program. ------------------------------ End of quake-dev-digest V1 #6 ***************************** From owner-quake-dev-digest@gamers.org Sun May 19 19:31 MET 1996 Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id TAA26133 for ; Sun, 19 May 1996 19:31:13 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id NAA04436 for quake-dev-digest-outgoing; Sun, 19 May 1996 13:30:53 -0400 From: owner-quake-dev-digest@gamers.org Date: Sun, 19 May 1996 13:30:53 -0400 Message-Id: <199605191730.NAA04436@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #7 Reply-To: quake-dev@gamers.org Errors-To: owner-quake-dev-digest@gamers.org Precedence: bulk X-gamers.org: quake-dev@gamers.org Content-Type: text Content-Length: 28090 X-Lines: 733 Status: RO quake-dev-digest Sunday, 19 May 1996 Volume 01 : Number 007 ---------------------------------------------------------------------- From: "Dark Shadow" Date: Wed, 8 May 1996 06:13:07 -0400 Subject: RE: Quake Development Tools (was RE: The GUI of Choice?) > >Expanding on this argument [not to be a walking MS advertisement, but avoiding > >it is becoming hard.. :) ] Visual C++ 4.0 is just as easy as visual basic with > >much more power and flexibility. In fact, with the new Foundation Classes > >(which admittedly _do_ represent a large learning curve) the GUI pretty much > >writes itself. VC even includes OpenGL support and lots of other nifty stuff > >that would help out in an editor project. > > > >>DLL which functions like Meddle. Then you get the VB people like myself > >>to write interfaces using those DLL's. So what's the result? The end > > > >This is actually a good idea, but stuff like this never seems to happen. > > Personal opinion follows: > > I gotta jump in here. I've been using Borland's Delphi since day one and have > yet to find anything that it can't do as easier than VB and just as quick as > VC++. I don't think there would be any disadvantages to using Delphi to > develop a Quake editor, and I've always considered it (Pascal) superior to C > just because the finished code is generally far more legible and therefore > maintainable. I absolutely agree there. I personally actually prefer Delphi to vis-bas because of the powerful functions it has. I consider Delphi to be a cross between vb 4 and vc. And no, I can't see any disadvantages at all to using Delphi, except that I'll have to shell out another 400 bucks to get it :) Yes, pascal is more legible than C. This is why there's so many VB programs out there; you can publish your code and people go "wow! i can actually understand this!" > VB is definatly out though, too much overhead to do anything usefull. If it > was between VC and VB, I'd be writing C code in a heartbeat. :) > This I don't agree with. Have any of you used or programmed with the new vb4, 32 bit for win95/NT? It's about a 10,000% improvement over the originals. ------------------------------ From: Bernd Kreimeier Date: Wed, 8 May 1996 12:44:52 +0200 (MET DST) Subject: Re: The GUI of Choice? >From: Matt Houser >I chose to use xforms for development beause it has >most of the features looked for (previous message mentioned these) > > + ... > + freely distributable sources & widgets > + ... > >With the exception of the NT portability, xforms has all this Correction: according to T.C. Zhao (zhao@bragg.phys.uwm.edu), the "source of xforms is not publically available and probably will remain so for quite some time." Which is why I decided not to use XForms. b. ------------------------------ From: matt.tagliaferri@pcohio.com (Matt Tagliaferri) Date: Wed, 08 May 1996 08:27:00 -0500 Subject: RE: The GUI of Choice? I agree with all the Visual Basic comments for ease of programming, etc, and would like to throw Delphi into the ring. I wrote DoomCad IN VB, and it was a popular editor for its ease of use, but unpopular due to its speed. I then rewrote it in Delphi, and got the same look but much faster speed. If you are a VB programmer, but took a bit of Pascal in college or somewhere, learing Delphi is an easy jump to make. Someone on the Doom mailing list helped me make the jump, and I'm happy to help anyone interested do the same. (thanx Jim :)) matt tag _ _ ------------------------------------------------------------- |_|_| PC-OHIO PCBoard Online * pcohio.com * V34+ 33.6: 216-381-3320 |_|_| The Best BBS in America * Cleveland, OH * Go Tribe ------------------------------------------------------------- ------------------------------ From: Raphael.Quinet@eed.ericsson.se Date: Wed, 8 May 1996 17:10:44 +0200 (MET DST) Subject: Re: The GUI of Choice? (a second opinion) Wow! I see that the GUI is a hot issue... The traffic on this mailing list has increased very quickly. As long as this doesn't turn into holy wars, this is OK, but I hope that we won't see too much of "my (programming) language is better than yours"... ;-) On Tue, 7 May 1996, Bernd.Kreimeier@NeRo.Uni-Bonn.DE wrote: > I have read and re-read the list, keeping in mind certain > requirements (your mileage may vary): > > + Linux/X support > + freely distributable sources & widgets > + no OSF Motif required (optional is okay) > + C++ or C, no scripts > + preferably includes interface builder/editor > + NT support higly desirable for cross-development > + allow for Mesa/OpenGL and GLUT use My requirements for the GUI for DEU and QEU are a bit different: + Provide a common interface to the native GUI functions of several operating systems and graphical interfaces. The systems that should be supported are, by order of importance: . UNIX/X (not only Linux), especially Solaris because this is my main development environment, . Windows 3.1 or 95, because this is what most people will want to use, . DOS (without Windows), because most people who run Quake or Doom under DOS do not want to start Windows every time they make a small change to a level, . Macintosh, . OS/2. + freely distributable sources & widgets. + no commercial libraries required (this includes OSF/Motif), except if they are part of the standard OS (i.e. Windows). + C or Java, no C++. + preferably includes interface builder/editor. Most of the problems with existing multi-platform GUIs is that they do not support at least two of the OSes/GUIs that I want to use (usually, DOS and Macintosh are missing from the list). That's why I thought about developing my own, since I have a good knowledge of X11, Windows and DOS graphics (and some limited knowledge of OS/2 and Mac). Also, a lot of libraries use C++ and I want to use ANSI C only (although I use some object-oriented concepts in my code). The requirements on freely distributable sources and no dependencies on commerical libraries mean that I want to be sure that anyone is able to compile (an maybe modify) the toolkit without needing any commercial packages, except maybe the operating system which they already have anyway. There are already lots of free toolkits, but alas none of them are available on all platforms that I would like to support. > using XForms (see http://bragg.phys.uwm.edu/xforms/) I also thought about XForms, which I have been using for something else, but this is too limited (no support for other OSes) and, as Bernd said, the sources are not freely distributable. > QEU - http://www.montefiore.ulg.ac.be/~quinet/games/QEU/, > no GUI mentioned, but I remember a home-brew SWAPI... Well, the page describing the draft version of SWAPI (Simple Windowing Application Programming Interface) should be at this URL: http://www.montefiore.ulg.ac.be/~quinet/swapi/ ... but I just realized that I forgot to upload the pages to my server after I wrote them. This stuff is outdated anyway, because I wrote that in December and I haven't updated it since then. > P.P.S.: I briefly considered a Java GUI (running as a separate > process/thread), but abandoned the idea as the AWT is > reportedly not a good choice. Right. Working around the limitations of the AWT means at least as much work as writing an interface from scratch in C. The basic widgets are too limited, and there are some things that you cannot do, even by sub-classing them. Also, some of them are not very good-looking (e.g. the list widget under X). Still, I seriously considered using Java for the interface to QEU, and I will probably use it anyway for some small tools. But the AWT is not good enough for a "real" editor, so Java is not an option for a full-featured editor. Unless Sun or some other company creates a new windowing toolkit that is better than the current AWT. > Anybody knowing a good > toolkit that allows for a Native C (C++?) wrapper? Very good question, indeed! :-) I haven't found any toolkit that meets my requirements, so I'm left with the only solution of developing my own. That's why I started with SWAPI. But it would be a lot less work for me and the members of the DEU team if such a toolkit existed somewhere... - -Raphael ------------------------------ From: Bernd Kreimeier Date: Wed, 8 May 1996 17:47:42 +0200 (MET DST) Subject: Re: The GUI of Choice? Here is the current list of those I am considering. Each comes with source, and reportedly compiles with Linux/X and NT:

          | XToolkit |_Lang. | Builder | Mesa/GLUT | ---------------------------------------------------
Amulet    | own      | C++   | not yet |     ?     |
Fresco    | Xt, own  | C++   | ?       |     ?     |
V         | Athena   | C++   | no      |     ?     |
wxWindows | XView    | C++   | yes     |     ?     |

Use of OSF Motif is optional, but not required with Fresco, wxWindows and (not yet) V - Amulet is completely standalone. I do not favor use of Motif anyway - the free Lesstif is far from being finished, and using Motif usually means distribution of bloated (statically linked) binaries. V and wxWindows run with looseDOWS 3.1, all of them claim to support looseDOWS 95 (sorry, couldn't resist :). No DOS support, obviously. All of these seem to be under active development, including mailing lists, and recent changes. Gut feeling says that Fresco will progress slowly, and is probably bound to be a memory hog, but I have no evidence whatsoever. Next-step [sic!] will be picking a choice, and checking out how reliable and easy to use/port the packages really are. Interaction with Mesa/GLUT is the main issue now, as far as I am concerend. b. Specifics Amulet: available for Mac, too. Fresco: standardization by X Consortium pending, Mac in prep., CORBA, the big leagues... and Tcl/Tk support :( V: keeps the look & feel of target platform, which might or might not be advantageous wxWindows: Cygnus GNU-WIN32 should compile this one some day, DJGPP with RSXDK does not work URL's: Amulet: http://www.cs.cmu.edu/afs/cs/project/amulet/www/amulet-home.html Fresco: http://www.faslab.com/fresco/HomePage.html V: http://www.cs.unm.edu/~wampler/vgui/vgui.html wxWindows: http://www.aiai.ed.ac.uk/~jacs/wxwin.html ------------------------------ From: Tom Wheeley Date: Tue, 07 May 96 23:50:50 GMT Subject: The GUI of Choice? In article <199605072215.PAA29174@dfw-ix5.ix.netcom.com> you write: > Also, although people scream at me when I suggest vis-bas 4 pro for an > editor, the fact is that making a truly GUI-type, friendly interface is > really child's play using ANY version of VB. As for the shouts that VB is > slow as hell when compared to C++ etc (which is definitely true), external > DLL files can be used for the functions needing speed (as you might have > seen in earlier versions of Wintex which used LBWINTEX.DLL for external > wad hacking functions). One of the advantages of using the 32-bit edition > of VB is that it's much faster than its predecessors, and I think that it > would now be possible to write a decent editor and / or utility using VB > as an interface shell and using external DLL's for the actual hack and > slash of the wads. I hope this isn't drifting _too_ far off the topic of the list (or is it on topic?), but have you tried Delphi? I've found it to be a very good mix of C/C++ power/speed with VB's ease of GUI creating and programming. I have a poor memory at best, but I believe Olivier Montanuy mutterred something about moving to it for Wintex (apologies if _completely_ wrong here... :-) > Having said that, I've never really liked C/C++. Sure it's fast, but for > most people who aren't necessarily computer science doctorates, C has a > sharp learning curve. So we have to rely on a few geniuses in the field Some people consider writing in Delphi easier than VB > of C to write programs that don't crash and run correctly is not an example!!> The best way to encourage development of good > editors and utilities, in my estimation, is for a few of you C gurus to > whip up some DLL's which cover basic needs for a utility, for instance, a > DLL which functions like Meddle. Then you get the VB people like myself > to write interfaces using those DLL's. So what's the result? The end Well it _would_ be nice if djgpp could make DLLs... (I believe there is a thread on this in the djgpp newsgroup) > result is a easy to use while slower program, but which is more > advantageous? Speed, or ease of use? If you make a bad-ass editor that's .splitbung - -- * TQ 1.0 * The 'Just So Quotes'. "They're filming Rocky V now. This one's being billed as `Rocky's Greatest Challenge', so I guess there's an IQ test involved." -- Jay Leno ------------------------------ From: Olivier Montanuy Date: Thu, 9 May 1996 10:51:00 +0200 Subject: VB and DLL for Quake editing >Are you actually proposing writiing a 3D Wireframe real time editor in >Visual Basic? >HAHAHAHAHAHA! >I'm sorry, that was rude. Indeed. But I can confirm, because I tried, with WinTex 4.3 2 frames per second on a DX4/75, with a 400x300 picture, on even the smaller Quake levels (without hidden face calculations of course). That was under windoze 3.1, 256 color. Of course, all the calculations are done in C, but the linking to Visual Basic is so damn slow that you can't expect any decent performance. BTW: I've got a long experience of external DLLs linked to Visual Basic. For any decent WAD editing to be done by DLL, you end up with several dozen of DLL functions, much more than one can find in reasonable DLLs. WinTex didn't explode yet, but I expect it will. > VB is purely a tool for interface *design*. >Trying to write a complete application in it is a waste of time. That's completely true. Microsoft didn't provide fast or even convenient access to graphic features in VB. When WinTex blasts pictures to the screen, Vb controls are painted a hell lot too slow. Not to mention that the VB listbox take hours to load. If you want fast prototyping, use Python. All the advantages of C/C++ syntax, minus all the bore. It's interpreted, but half pre-compiled stuff. Not as fast as C on calculations, but then you can link C code to Python. Also, Python is a free tool. Which means it doesn't depend on the Microsoft commercial policy, especially the one that makes VB 3.0 programs crash when running in VB 4.0 (guess why WinTex 4.3 is still a 16-bit app). (Note: WinTex is a VB program, that uses a C (object oriented like) library to speed up all WAD manipulations.) > if a compromise is what you are looking for, then Visual C++ really is >the choice. MFC is no bed of roses for sure, We're talking normal human with a life, not geeks who can learn a poorly documented hundred-class C++ library, when not working for money. I assume you learned MVC as part of your job? > Even GDI manipulations are relatively simple once you grasp the >concept of the device context in the framework of the CDC class. And with every line of code you write with GDI, there can be a bug. >Personally, I think it is going to take a Direct Draw appliction to >acheive the ultimate goal of 3D Preview. That's probably right. We're all counting on hackers like you to write the middleware, so that normal human can use DirectDraw ;-) Olivier ------------------------------ From: "Brian K. Martin" Date: Thu, 9 May 1996 07:52:44 -0400 (EDT) Subject: Re: The GUI of Choice? > > In article <199605072215.PAA29174@dfw-ix5.ix.netcom.com> you write: > > Well it _would_ be nice if djgpp could make DLLs... (I believe there is a > thread on this in the djgpp newsgroup) > There is a zip file at the djgpp main site that shows you how to do this. (i'm surprised the rars guys haven't used it..) Also, to throw one more language into the discussion, I must mention that 'envelope' is a visual basic type of language for win95/NT and is completely free. I've played around with it and found it to be really easy. Again, speed may be a problem. I just thought I'd mention envelope. brian ------------------------------ From: Barry D Bloom Date: Thu, 9 May 1996 06:40:56 -0500 (CDT) Subject: Re: VB and DLL for Quake editing On Thu, 9 May 1996, Olivier Montanuy wrote: > > if a compromise is what you are looking for, then Visual C++ really is > >the choice. MFC is no bed of roses for sure, > We're talking normal human with a life, not geeks who can learn a poorly > documented hundred-class C++ library, when not working for money. > I assume you learned MVC as part of your job? Yes, I have, and I am not a eyes closed pundit about it either. It is wonderful for the management of an application framework. I am suprised anyone would honor me with the term "geek with no life" for learning it. The truth is, if you want a wiz-bang interface for your Quake editor with good speed, VC++ is the answer. I find it hard to believe that anyone could produce a more solid framework to build upon than the one generated by VC. All the nice and neat common controls of the Win32 development enviornment are nicely packaged up and the code, even though microsoft, is better tested than anything I could write. > > >Personally, I think it is going to take a Direct Draw appliction to > >acheive the ultimate goal of 3D Preview. > That's probably right. We're all counting on hackers like you to write > the middleware, so that normal human can use DirectDraw ;-) > DirectDraw is not that hard. There are plenty of good examples on how to use it, and it provides the basic functionality any game would need. The cool thing about it is that if I have model X video card which has all sorts of hardware gadgets, any direct draw code will use these directly. While, someone else who has model Y with no hardware gadgets, gets all those wizbang features in software emulation, but I don't have to change anything about my code. All while I have a very tiny layer of abstraction between me and the video card itself! Anyway, enough chanting.... Barry Bloom bdb0004@jove.acs.unt.edu - ------------------------ ------------------------------ From: The Dewb <72614.2725@CompuServe.COM> Date: 09 May 96 14:22:04 EDT Subject: RE: VB and DLL for Quake editing >> if a compromise is what you are looking for, then Visual C++ really is >>the choice. MFC is no bed of roses for sure, > We're talking normal human with a life, not geeks who can learn a poorly > documented hundred-class C++ library, when not working for money. > I assume you learned MVC as part of your job? This is getting way off-topic, but I'm learning VC and MFC in my scant spare time, and it's not _that_ much of a chore. > That's probably right. We're all counting on hackers like you to write > the middleware, so that normal human can use DirectDraw ;-) DirectDraw isn't really that complicated.. it's just everything else around it that's a pain. ------------------------------ From: "Dark Shadow" Date: Fri, 10 May 1996 06:29:23 -0400 Subject: Wintex / etc - ---------- > From: Olivier Montanuy > To: quake-dev@gamers.org > Subject: VB and DLL for Quake editing > Date: Thursday, May 09, 1996 4:51 AM > > > >Are you actually proposing writiing a 3D Wireframe real time editor in > >Visual Basic? > >HAHAHAHAHAHA! > >I'm sorry, that was rude. > > Indeed. But I can confirm, because I tried, with WinTex 4.3 > Speaking of WinTex (this is hideously off topic)....When will it support the registered version of Duke Nukem? ------------------------------ From: "Dark Shadow" Date: Fri, 10 May 1996 06:28:21 -0400 Subject: RE: VB and DLL for Quake editing - ---------- > From: Olivier Montanuy > To: quake-dev@gamers.org > Subject: VB and DLL for Quake editing > Date: Thursday, May 09, 1996 4:51 AM > > > >Are you actually proposing writiing a 3D Wireframe real time editor in > >Visual Basic? > >HAHAHAHAHAHA! > >I'm sorry, that was rude. > > Indeed. But I can confirm, because I tried, with WinTex 4.3 > > 2 frames per second on a DX4/75, with a 400x300 picture, on even the smaller > Quake levels (without hidden face calculations of course). That was under > windoze 3.1, 256 color. > Of course, all the calculations are done in C, but the linking to Visual Basic > is so damn slow that you can't expect any decent performance. Hmm. Graphical applications that I've written in VB4 seem to get much better performance due to the Games SDK that Microsoft was so nice to include. It's not the same when you run it under win 3.1, wing or no wing, performance will still suck. But all I'm saying is I don't expect the same terrible performance under VB4. > BTW: I've got a long experience of external DLLs linked to Visual Basic. > For any decent WAD editing to be done by DLL, you end up with several dozen > of DLL functions, much more than one can find in reasonable DLLs. WinTex > didn't explode yet, but I expect it will. Why not link all the DLL's into one library? Is it really necessary to include 9 million DLL files to do one function (rip MDL's, open PAK, etc) > > VB is purely a tool for interface *design*. > >Trying to write a complete application in it is a waste of time. > That's completely true. > Microsoft didn't provide fast or even convenient access to graphic features > in VB. When WinTex blasts pictures to the screen, Vb controls are painted > a hell lot too slow. Not to mention that the VB listbox take hours to load. > > If you want fast prototyping, use Python. All the advantages of C/C++ syntax, > minus all the bore. It's interpreted, but half pre-compiled stuff. Not as fast > as C on calculations, but then you can link C code to Python. > Also, Python is a free tool. Which means it doesn't depend on the Microsoft > commercial policy, especially the one that makes VB 3.0 programs crash when > running in VB 4.0 (guess why WinTex 4.3 is still a 16-bit app). Really? That's odd. I recently had an FTP program that I wrote under VB3 and I ran it under 4.0 just fine. All you have to do is change the way the program calls external DLL files. > (Note: WinTex is a VB program, that uses a C (object oriented like) library > to speed up all WAD manipulations.) > > > if a compromise is what you are looking for, then Visual C++ really is > >the choice. MFC is no bed of roses for sure, > We're talking normal human with a life, not geeks who can learn a poorly > documented hundred-class C++ library, when not working for money. > I assume you learned MVC as part of your job? Eech, I completely agree. I'd just rather use Borland 5.0, it has great documentation. > > Even GDI manipulations are relatively simple once you grasp the > >concept of the device context in the framework of the CDC class. > And with every line of code you write with GDI, there can be a bug. > I especially love the GDI bugs that turn your screen into something out of a 60s LSD trip. That's why I'd rather just use internal API calls to the GDI (cough, vb4 does this quite well). Much safer, if you ask me. > >Personally, I think it is going to take a Direct Draw appliction to > >acheive the ultimate goal of 3D Preview. > That's probably right. We're all counting on hackers like you to write > the middleware, so that normal human can use DirectDraw ;-) > > Olivier DirectDraw isn't THAT hard. Sure, it's difficult, but if you learn it it's very rewarding. And mabye that's true (needing a DD app for 3D preview). But, I don't. I know, I know, "He's a madman! Look at the crazy person trying to write a graphical 3D wireframe preview program in VISUAL BASIC!!@#$". I think it can be done, however. We'll just see... ------------------------------ From: jschuur@globalnews.com Date: Sun, 19 May 1996 15:53:18 +0000 (GMT) Subject: QuakeEd source code released for those of you who haven't heard yet (all three of you). johnc has released the source code for QuakeEd (but not all the other developement tools, specifically not qbsp, vis and light). ftp://ftp.idsoftware.com/idstuff/source/QuakeEd.tar.gz -- joost schuur, Online Magic Ltd. ----------- Tel: +44 171 820 7766 -- ----------------------------------------------------------------------- ---------------------------------------------------------------------- - --- http://www.nuqneH.org/~jschuur/ ---- jschuur@onlinemagic.co.uk --- ------------------------------ From: "Frans P. de Vries" Date: Sun, 19 May 1996 17:11:53 +0200 (MET DST) Subject: QuakeEd source released Hi, FYI, John Carmack released the current source of QuakeEd, id's map editor: ftp://ftp.idsoftware.com/idstuff/source/QuakeEd.tar.gz ftp://ftp.cdrom.com/pub/idgames/source/QuakeEd.tar.gz (& mirrors) Here is the .txt file (lines wrapped for readibility): 5/18/96 This is a dump of the current source code for QuakeEd, our map editing application. This does not include everything necessary to build maps. There are graphics files, prog files, and other utilities needed. I plan on releasing a full development set of tools after the game ships. This is just intended to help out anyone working on their own map editor. This is a NEXTSTEP application, so hardly anyone is going to be able to use the code as is. This is not an OPENSTEP application. It doesn't even use the foundation kit, so porting to gnustep or openstep-solaris/mach/nt would not be trivial. There are lots of mixed case and >8 character filenames, so I'm using unix gnutar (compressed) format. Because most people won't have access to a NEXTSTEP machine, I took pictures of some of the more important stuff from interface builder: mainwindow.tiff : a screenshot of the primary window inspectors.tiff : a screenshot of the important inspector views help.txt : a dump of the (minimal) help inspector's contents. I included some sample data to help you follow the code: quake.qpr : our current project file jrbase1.map : a sample map triggers.qc : a sample qc source file that includes some /*QUAKED comments There will not be any major changes to this code base. I am eagerly looking forward to writing a brand new editor for windows NT + open GL as soon as Quake ships. This application was really not a very good fit for NEXTSTEP. The display postscript model fundamentally doesn't fit very well with what we need here -- if you run in an 8 bit color mode, the line drawing runs at an ok speed, but the texture view goes half the speed it should as it dithers from 24 bit color down to 8 bit. If you run in 24 bit color mode, you get less screen real estate and significantly slower line drawing as a 3 megabyte XY view is flushed. Sigh. If anyone does actually run this on NEXTSTEP be advised that you want a fast machine. I never had the time to properly optimize QuakeEd. The texture view rendering code in here is crap. Anyone coding a new editor is strongly advised to just use an available optimized library, like open GL or direct 3D. John Carmack Id Software johnc@idsoftware.com - -- Frans P. de Vries | fpv@ftp.cdrom.com | Doom/Quake archive backup maintainer ------------------------------ End of quake-dev-digest V1 #7 *****************************