From owner-quake-dev-digest@gamers.org Mon Jun 3 20:08 MET 1996 Received: from olymp.informatik.uni-bonn.de (root@olymp.informatik.uni-bonn.de [131.220.4.1]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id UAA05084 for ; Mon, 3 Jun 1996 20:08:07 +0200 (MET DST) Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with ESMTP id TAA24439; Mon, 3 Jun 1996 19:49:55 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id NAA16581 for quake-dev-digest-outgoing; Mon, 3 Jun 1996 13:46:41 -0400 From: owner-quake-dev-digest@gamers.org Date: Mon, 3 Jun 1996 13:46:41 -0400 Message-Id: <199606031746.NAA16581@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #8 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: 34124 X-Lines: 882 Status: RO quake-dev-digest Monday, 3 June 1996 Volume 01 : Number 008 ---------------------------------------------------------------------- From: Bernd Kreimeier Date: Mon, 20 May 1996 18:43:31 +0200 (MET DST) Subject: Re: The GUI of Choice? Concluding summary (as far as I am concerned): 

          | XToolkit |_Lang. | Builder | Mesa/GLUT | ---------------------------------------------------
Amulet    | own      | C++   | not yet |     ?     |
Fresco    | Xt, own  | C++   | ?       | possible  |
V         | Athena   | C++   | no      | possible  |
wxWindows | XView    | C++   | yes     | supported |
wxWindwos supports Mesa/OpenGl since mid of 1995, with GLX (Linux/SGI), and with NT. The author of V indicated he had not tried nor heard of any attempts, but it should work: "The vCanvas class provides methods to retrieve both Widget and Drawable handles for X, and HWNDs for Windows, which is what I understand is required by OpenGL." The same is likely to be true for Fresco. I have received no response whatsoever from the authors of Amulet. ... and the winner is ... In case anybody could care less: I will try wxWindows with Linux, as the GLX-based Mesa support is the most decisive issue. See QED :-). b. ------------------------------ From: Raphael.Quinet@eed.ericsson.se Date: Mon, 20 May 1996 19:07:41 +0200 (MET DST) Subject: Anybody still using Turbo C 3.0? Hi there! Here is an article that I just posted in the Doom/Quake editing newsgroups. It is barely on-topic for these lists, that's why I encourage you to post your replies to the newsgroups or to send them to me directly instead of sending them to the lists. If necessary, I will post a summary of the replies here. Here is my question: I made some progress on GAEL, my portable Doom/Quake editing library (which will be released as part of QEU 0.4), but some parts of the code get a bit messy if I still support Turbo C 3.0. Following the good tradition of DEU, I try to support as many operating systems and compilers as possible (DJGPP, Borland, Watcom under DOS and many other compilers under UNIX), but some workarounds for the bugs in the old Turbo C 3.0 make the code less readable and I would like to get rid of these kludges. Description of the most annoying bug: TC 3.0 cannot increment huge pointers with the "++" operator. Try writing a short program which declares a pointer as "char huge *p" and then print the value of p before and after "p++" and "p = p + 1" and you will see the difference! That was one of the most frustrating problems that I had when debugging some early versions of DEU two years ago. Because of that, I have to put some #ifdef's in my code, and this is not very pretty. For example: #ifdef __TURBOC__ *p = x; p = p + 1; #else *p++ = x; #endif When this is a single statement, that solution is still bearable, but it gets really annoying when the "++" is embedded in another statement or when there are several huge pointers involved in a loop. I would like to know if there are some people out there who are still using TC 3.0 for compiling C programs, or if I can assume that everybody has switched to a newer version of Borland C++ or to another compiler, such as DGJPP (which is very good, and free). If I don't have to support TC 3.0 anymore, I would be glad to get rid of these #ifdef's in the code. Note that I will still be supporting 16-bits DOS compilers as well as 32-bits compilers; it's only TC 3.0 which is a problem. - -Raphael - -- +---------------------------------------------------------------------------+ | WWW: http://www.montefiore.ulg.ac.be/~quinet | | E-mail: Raphael.Quinet@eed.ericsson.se or quinet@montefiore.ulg.ac.be | | S-mail: Raphael Quinet, 9 rue des Martyrs, 4550 Nandrin (Belgium) | +---------------------------------------------------------------------------+ ------------------------------ From: Bernd Kreimeier Date: Tue, 21 May 1996 12:42:48 +0200 (MET DST) Subject: Re: QuakeEd source released I updated the QuakeDev pages at http://www.gamers.org/dEngine/quake/. There is a (preliminary) Source Overview page, the screenshots page has been updated (the GIF files are a lot smaller), and the links I posted earlier this month have been added. If anybody is going to work on porting QuakeEd, I would appreciate reports. I am considering a port using C++, wxWindows and Mesa just as a feasibility study, and will put whatever insights on the pages. b. P.S.: there is one file in DOS format, cmdlib.h - perhaps a really ancient one :-). Besides the two screenshots itself, the other TIFF files (icons) are in a 12bit format inaccesible to most tools available to me, but the Gimp loads it - and vx grabs it. Whatever it's worth. Anyone happen to know a UNIX/C-equivalent of the UserPath lib? ------------------------------ From: Bernd Kreimeier Date: Mon, 3 Jun 1996 19:03:07 +0200 (MET DST) Subject: Info from John Carmack (1) I am going to forward a couple of mails to the list, with permission. This should have happened way earlier, btw., but work got the better of me the last weeks. b. This one immediately followed the mail about editing qtest1. - ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Sun Apr 7 20:26 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Sun, 7 Apr 96 13:25:22 -0500 To: Bernd.Kreimeier@NeRo.Uni-Bonn.DE Subject: Re: qtest1 editors? >Problem: billboard object (sprite) support might be removed, or >incomplete. Billboards allow for good use of partly transparent >textures. They are going to stay in. All of the sprite types you mention are currently supported, and there is also a sprite type that always has the XY normal pointing towards the view, which is slightly different than parallel to the view plane. >1.1 The trailing zeros in a plane like > "( 0 816 0 ) ( 0 512 0 ) ( 16 512 0 ) TECH07_2 0 0 0" > >are s_ofs, t_ofs, and flags? I.e. a texture offset s_ofs=16, >t_ofs=-32, with negate_s, negate_t, and exch_st all set would read Exactly. In case you didn't figure it out already, the points that define the plane are not necessarlily points on the brush, but just three non colinear points on the plane. I chose this representation instead of a normal/distance form because it allows me to keep perfect precision with integral values. I fear floating point creep in many forms. >2.1 How does "qbsp" handle two brushes that do not intersect, but > merely "touch"? Contacting faces are merged out of existance. I'm pretty sure that a brush that has no thickness in a given dimension would clip itself out of existance and not show up at all in the bsp file, but I'm not positive. > >Levels carry their own textures with them. > > Would it be possible to include a dummy entry of two long int in > the BSP header? As a placeholder for an optional list of "15 > BIGDOOR" entries, to be ignored by the engine. I don't think any app specific data should be stored raw in bsp files. Store it in a key/value pair in the world entity. An unrecognized key name will get a warning from Quake, but you can either define a new variable in defs.qc (when I release the compiler), or just use a valid string variable key like "netname" or "weaponmodel". Or perhapse I should just ignore (or make notification a development option) unknown keys at load time? It is nice to know when you make a typo... > I wish you only had... I figured this out last week, and it will > hamper level design in the most subtle ways. I don't see any > convenient fix, though. It was originally a speed issue for building the surface caches, but a later insight rendered the problem moot. I would like to fix it, but it probably won't show until Quake 2. The current limitation that annoys the map guys most is that texture shifting is by multiples of 16. If I put in The Fix, the primary benefit would be pixel level shifting, but it would also allow arbitrary rotation and scaling. That is an easily abused feature, though... Overall, natural alignment makes creating good looking maps a lot easier, because you usually don't have to offset things at all to get them to line up. John Carmack - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Mon, 3 Jun 1996 19:12:02 +0200 (MET DST) Subject: Info from John Carmack (2) - ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Thu Apr 11 23:28 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Thu, 11 Apr 96 16:26:16 -0500 To: Bernd Kreimeier Subject: FYI Content-Type: text/plain; charset="us-ascii" Content-Length: 1199 For your information, prompted by the comment about the limit of 255 textures in a qtest1 level, the current format has expanded miptex, sofs, tofs, and flags to 16 bits. While we probably won't ship a level with more than about 64 textures in it, I agree, 256 is never really enough of anything. The limit on offsets also prevented us from using >256 size textures in some situations, which people will probably want to do even before hitting the 256 unique textures limit. All better now, in any case. On the NAT front, I am considering changing the .map definition to use arbitrary texture origin and S and T vectors on each plane, instead of the sofs / tofs / flags values that are currently there. That would enable any affine texture arrangement, including arbirary rotation and size changes. I still don't think that capability is going to make it into the .bsp format for quake1, but it seems very probably for quake2, and I might as well get the .map format ready for it. Its good to see some reasoned comments about my architecture. I will be trying to address as many things as I can while under the pressure of shipping the game... John Carmack - ----- End Included Message ----- - ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Tue Apr 16 21:07 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Tue, 16 Apr 96 14:07:50 -0500 To: Bernd.Kreimeier@NeRo.Uni-Bonn.DE Subject: another FYI Content-Type: text/plain; charset="us-ascii" Content-Length: 400 On the subject of storing additional info in .map and .bsp files, I decided that all key names that begin with an underscore will be dropped by quake, so you can store whatever you want in them for utility communication. I am probably going to change all of our map uses of "wad" and "light" to "_wad" and "_light" so I can remove the unused dummy variables from the progs. John Carmack - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Mon, 3 Jun 1996 19:14:57 +0200 (MET DST) Subject: Info from John Carmack (3) - ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Fri Apr 26 20:22 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Fri, 26 Apr 96 13:21:10 -0500 To: Bernd Kreimeier Subject: Re: q&a Content-Type: text/plain; charset="us-ascii" Content-Length: 2988 You wrote: > Q's: > > 1. I want to forward a posting of yours (to Brian Martin) > concerning z-fill/z-buffer usage to the QuakeDev list, to settle > the occasional "z-buffer?" threads. Do you have any objections > against making any of your mails to us public? I never say anything that can't be quoted. > 2. Will billboards (sprites, decals) be mipmapped in 1.0/2.0? Hadn't planned on it, because it would require alpha channel to properly mipmap a mixture of transparent and opaque pixels. > 3. Will the texture names in the BSP mipmaps lump stay? I want to > use them to store the info needed to add mipmaps to a BSP file w/o > mipmaps - use of "_wad" optional. Yes, they should still be there. Are you planning to use miptex without any pixels as placeholders for another utility to fill in? I don't really think that is a great idea. Yes, it takes a couple hundred K to cary the graphics with a level, but it is rarely more than 20% of a full sized map's disk footprint. We are going to give free license to redistribute our art in user maps for non-commercial purposes. Packaging it all into one file makes distribution so much easier -- people don't need to get both graphics and levels. > 4. qtest1 and your log seem to indicate that Quake will try to > preserve view_up as much as possible (except on being > dead/strifing). Does that mean that there will be no builtin > support for 360 degree rotations around LOS/no rotate_ccw/cw > commands to bind to a key? There is no direct way to do it, but you can set cl_rollangle to 45 or so to get a whole lot of roll... A linked in input driver can set the view angle to anything it wants, so HMD can roll arbitrarily. qc code can set any angle for other objects, but there are some restrictions on player views, due to the client side short-circuiting of view control (to reduce latency). > 5. I am looking at GNUstep, trying to guess the changes of a > QuakeEd Linux port using GNU gcc ObjectiveC support and the > (supposedly 85% done) GNUstep libraries. Have you ever considered > this option? What classes/libs does QuakeEd require? 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. > 6. Is there any real gain in not doing the mipmapping down to 1x1? Yes, I need to keep a cache pointer for each surface and each mip level, so adding four more mip levels would eat 160k of ram on a 10,000 polygon level. > 7. Idle curiosity: what became of the spherically mapped sky? It is a very squashed sphere now. A true sphere looked like you were inside a beach ball. Currently on the hardware 3D boards, it is a flat mapping, but that looks pretty poor. We are probably going to subdivide on them to get the spherical projection. John Carmack - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Mon, 3 Jun 1996 19:19:25 +0200 (MET DST) Subject: Info from John Carmack (3a) This is that earlier posting on z-buffer usage, as provided by Brian Martin. b. - ------------------------------------------------------------------- >From johnc@idnewt.idsoftware.com Tue Mar 26 17:12:36 1996 Message-Id: <9603262211.AA22560@idnewt.idsoftware.com> Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Received: by NeXT.Mailer (1.118.3) From: John Carmack Date: Tue, 26 Mar 96 16:11:40 -0600 To: "Brian K. Martin" Subject: Re: quake models References: <199603261430.JAA27076@minerva.phyast.pitt.edu> Status: RO You wrote: > Yes, it would be a real pain in the ass to download a different mdl > file to the server for each player. That is out of the question. > But why don't you allow to add one more peice of info to be sent on > initialization besides the colors, that is a string for a name of > the mdl to use. like 'player2.mdl'. This would allow so many more > cool possibilities. You guys don't have to worry about supplying > the models, just make it possible to use them. My idea was to have > quake load up the default player.mdl, then if someone wanted to use > a different one, and the client had it on their disk, they could > use it. Of course the color values could still be used and maybe > even you could just overwrite existing mdl info so you don't need > to read in all the frames, maybe just the texture. I've been considering the options for a while, and an "optional model" field is probably pretty good. I wouldn't count on it for 1.0, but that is the type of thing that might make it in on a revision. > -- Also, would you be kind enough to give the relevance of the byte > in the frame data after the max bound values in the mdl files. It is unused. Three byte structures are non-portable, so it's just padded. > Also the precalculated indecies go up to 161, but there are some 255's > in the models that are set to dark with no gouraud shading. I found > that values like 162 could be used to make things like sparkles and > stuff. Is this planned of just on accident (i.e. should I pursue > this if I wanted to hack an mdl file? but I would never do that.) There shouldn't be any 255s. What model did you see them in? It may be a bug. > one other little thing. I was arguing to several people about quake > using a z-buffer to render models. I can find no proof, no one > believes me. Every one says it's too slow. (and it is, but it works > good). Any words? The alias models are z buffered. The world is rendered with Z fill, which costs about 15% over just the drawing. Yes, the z buffering hurts on really large models, but for the majority of them, it is a speed advantage. If the average polygon size is only a dozen pixels or so, doing a compare and store to the z buffer for each pixel is less work than sorting against the other polygons in the model (let alone properly sorting against the world). As for speed... We will ship about 20% faster than qtest1. The 486 performance will still be hopeless, but that is the price for going to a floating point intensive design. I still stand by it as the right decision for the lifespan of the product. John Carmack - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Mon, 3 Jun 1996 19:24:50 +0200 (MET DST) Subject: Info from John Carmack (4) - ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Sat May 11 05:46 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Fri, 10 May 96 22:46:23 -0500 To: Bernd Kreimeier Subject: Re: q&a (2) Content-Type: text/plain; charset="us-ascii" Content-Length: 2727 You wrote: > 1. The Quake registered (==shareware?) will still be released as > DJGPP-linkeable modules? The initial 0.9 will not, but some later version will. I'm not sure if the initial CD pressing will, because there won't be any external drivers yet. The will be net released at some point for sure. > Followup: Iff, will the linux version be on the same CDROM? As > modules (gcc-linkeable) as well? I would hate to see DOS get the > better of this. Or looseDOWS. I have intentions to do so, but since Dave Talor left id, there is nobody here actively running linux, so it can get pushed out of the way by other issues pretty easily. Dave is still going to support the unix ports for us, but it is less of a priority. Yes, unix versions are cool, but they don't rank that high on the priority list. > 2. The COLORMAP remapping of the WAD2 palette for lighting (32 > steps again?) is part of the EXE now? Its an external data lump now, so the palette and colormapping (including fullbrighting) can be completely changed. > Followup: like the normal vectors used with the MDL, wouldn't it be > a better idea to keep any lookups outside the EXE, to prevent EXE > hacking, and ease configuration? ;-) > 3. Is the design of QuakeC vs. physics of the game flexible enough > to separate "blast" (momentum transfer) from "damage", i.e. pushing > an armored target without hurting it (area effects, not direct > hits)? Absolutely. Romero has asked me to do this a number of times, but I haven't gotten around to it. A while ago, we had mosnter cannons that chucked bad guys out of a piston, but it went away with some redesign. > Followup: will involuntary movements (like being pushed by an > explosion) change the view_up (including roll)? Whatever > restrictions on GUI/net packet size, preserving the view_up during > involuntary movements (falling) seems to make things "stiff" by > design. I let the client short curcuit the view angle in most cases, so the server doesn't usually override it. It's possible, though. > 4. Just a confirmation: the z-fill is done as a separate pass, not > within the texture mapping loop, because of (lack of) registers on > i586? Exactly. > Better performance on other CPU's? Alpha? Unlikely, because we have a fair amount of hand coded intel ASM. A 21164 certainly won't be a slug, though. I still need to fix a little 64 bitism in my code before it is going to work on alphas, though. I will get that done for sure. John Carmack - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Mon, 3 Jun 1996 19:38:32 +0200 (MET DST) Subject: Info from John Carmack (5) - ----- Begin Included Message ----- >From johnc@idcanon1.idsoftware.com Sat May 18 04:38 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Fri, 17 May 96 21:38:15 -0500 To: Bernd Kreimeier Subject: Re: q&a (3) Content-Type: text/plain; charset="us-ascii" Content-Length: 7321 You wrote: > Two shorts, one int. Two longs you might want to ignore. > > Q: you are using the "portals" mentioned in the worklog during PVS > computation, as described in Seth Tellers PhD? Similar idea, different implementation. Someone refered me to Teller's papers after I had a non-robust version of Quake PVS running, and it clarified some things in my mind, but was definatly a different tack from what I would up doing. I certainly don't retain any of the portal chain information for run time culling -- the map files are too huge as it is. I use a gross leaf to leaf PVS bit table, then the hierarchal BSP bounding volumes for frustom culling. > Q: I understand the short circuiting of view control on the client. > Is it correct that only yaw/pitch (determining movement along > current LOS and aiming) are transfered to the server? Is this > "hardwired" in the net packet structure? The server only rarely sends view angle information to the clients (enteting level, teleporters, etc). The client has full control over the view angles (all of them) most of the time, and sends all three view angles to the server each frame. This can be removed for things like tracking the monster that killed you when you are on the ground. > > Q: if I understood correctly - mipmpas are created by qbsp each > time anew, using a WAD file (old style? TEXTURE1/2, PNAMES?). There > is no Mipmaps WAD lump. > > Suggestion: how about including the DOOM > shareware/registered/commercial patches, PNAMES and textures on the > Quake CD, too? Removing all the monster frame rotations will > protect DOOM sales (as far as this is possible anyway). Permitting > redistribution will ease conversions a lot. It increases the pool > to draw [sic!] from. It looks good in the shops (added value). The > artwork was a major part of DOOM's success, it deserves a mipmapped > afterlife ;-). The mipmaps are creaated by qlumpy into new format wad files (just about the only remaining use of them -- they were intended to be used heavily, but I wound up going with the much superior search path / directory hierarchy aproach), but those are only referenced by QuakeEd and qbsp, which copies the needed ones into the map .bsp file directly. We used some DOOM graphics early on, but the palettes are different enough that the artwork is damaged in the conversion. Artists tend to be picky about showing degraded versions of their work :-) Don't worry, there are lots of really good Quake graphics. > > > Q: have you at some point thought about entities that are not > occluded by surfaces, i.e. always rendered on top of everything > else if within the view frustrum (no PVS)? > > Purpose: there is no automap for good reasons. I have tried a > look-through 2D automap with a DOOM-style renderer and found it > confusing, a 3D one is prolly even more useless. > > However, the concept of an (annotated) marker entity seems worth > bothering: an object that can be dropped, or shot at/attached to > another entity, that is always visible even through walls (in a > certain view mode, at least). It gives the player a sense of > direction to move along, but he still has to remember the structure > of the map. The advantages for hunting games are obvious: a tagged > target will always be visible, but is still difficult to hunt down > and trap. > I don't think that is a good idea. When an object shows through it's natural occluders, it give a pretty serious optical illusion that the things it is showing through are translucent, damaging the rock-solid feel of the world. > > Q: this is a not too specific remark (thus lengthy). If I > understood correctly, RGBA support is supposed to be a major > benefit of upcoming hardware (i.e. might be available in 1997 :). > It seems to me that the current engine design is biased with > respect to index color mode. Examples: > > + WAD2 Palette now contains 256 RGB values, it might as well > contain a NoOfColors field (256, 4096), and RGBA entries (32bit or > 48bit) at virtually no costs (ignored in index color mode) > > + Mipmaps and billboards implicitely reference one Palette, they > might as well explicitely reference a Palette (ignored in index > color mode) > > + billboards do not have mipmapping (no blending in indexed color > mode), but they might as well have (if w/o blending, it is still > LOD, and sprites will show more variation) > > Low overhead suggestion: bright objects (light sources) might > (implicitely) use a second, different Palette in 24bit modes. > > Followup: How is the lightmap+mipmap -> surface cache processing > done in 24 bit mode? Same LUT with same 256 colors? Or > NoOfLightlevel*256 true color values? Some comments: originally, we maintained 8, 16, and 32 bit code for all of our drawing, and we worked in every conceivable video mode. This was a major pain in the ass to maintain. 16 bit color looked noticably WORSE than 8 bit color, because while we have smooth 16 color gradiants of some non primary colors that look fine in 256 color mode (18 bits of color precision), in 15 or 16 bit mode there is a noticable hue change every time you are forced to drift a bit off of your ideal color. 24 bit color looked better than 8 bit, but not a whole lot. This is mostly due to good source images. For an arbitrary image processing solution where you can chuck any old set of pixels at it, any direct color mode is going to be a ton better, but when you have control over your source data you can pick and choose to make 8 bit outperform 16 bit, and save all the extra space and processing time. We do occasionally take a lose in the mip map creation process for lack of good colors in the palette, but I do an error diffusion during the resampling, which helps a lot. Lighting direct color images hurts a fair amount, too. MMX is really nice for that, but without it you either need huge tables or lots of bit twiddling. All that said, Quake is still my last indexed color engine. I still think it is the right call for this moment in time, but the future is definatly direct color. > Followup: is the current 3D hardware worth to be taken into account > in renderer design? I.e. are there ways to use RGBA e.g. for > processing lightmaps (as Alpha-map implicitely blending with a > solid black)? How does the lightmap+mipmap processing fit with > on-board texture memory anyway? A max-throughput engine is still going to use small, tiled textures in hardware, just as in software. I think the image quality tradeofs of surface caches are worth the speed cost, though. 3DFX has done some light map building demos with the hardware, and rendition could certainly be programmed to do it. I suspect that all of the Quake drivers will still build the surface caches in software, because many of the current 3D boards have high setup overhead per primitive, and drawing tons of little boxes would suck. Rasterization hardware is definatly the future. Soon you will not be able to buy a computer without it, because it can be implemented in the same single chip video controllers currently used, and it will become a checkbox item. John Carmack - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Mon, 3 Jun 1996 19:45:57 +0200 (MET DST) Subject: Info from John Carmack (6) In march, following the CeBit fair, I asked about support of the S3 ViRGE and ViRGE/VX. I add that one short reply to the discussion of 3D hardware in the more recent posting. b. - ----- Begin Included Message ----- From: John Carmack Date: Sat, 16 Mar 96 15:00:50 -0600 To: Bernd Kreimeier Subject: Re: Verite premier platform We are supporting both S3 and rendition for release. Rendition should be a bit faster. John Carmack - ----- End Included Message ----- - ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Fri May 24 22:32 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Fri, 24 May 96 15:32:46 -0500 To: Bernd Kreimeier Subject: Re: q&a (4) Content-Type: text/plain; charset="us-ascii" Content-Length: 3183 You wrote: > Q: Brush.h in the QuakeEd sources is obsolete, it refers to > EditWindow.h and is not imported at all. Is this part of something > new (Brush Editor) that is not released yet, or a leftover? > It was a leftover. Delete it. > > Q: qbsp, vis, light and qlumpy are written in C? ObjectiveC? If the > latter, using only common classes (in gcc libobjc.a), or anything > more NS specific? Pure C. ( Pure ANSI, in fact, except for cwd() ) They compile on practically anything. > > > Q: You wrote: > >I am eagerly looking forward to writing a brand new editor for > >windows NT + open GL as soon as Quake ships. > > Reminds me of two drawbacks I foresee with the Verite cards: > a) Rendition never indicated OpenGL support (but supports HEIDI) > b) judging from their zero-response, XFree86 support will suffer from > NDA and Matrox-style attitude. Am I wrong? I'd rather be wrong: the > Verite looks very interesting, esp. if programming the RISC would > be an option for pedestrians, too. The Technical Specs on the > Chromatic pages are much more promising in that regard, i.e. open > to the public. I doubt we will see a verite GL driver, but I did mention it to them. They are dram based, so it isn't a real workstation class card anyway. They are pretty decent folks, so I don't think XFree86 support is out of the question. I'll mention it next time I talk with them. I suspect they are just in crunch mode and don't have the time to devote to freeware projects. I think being open with the RISC programming would be to their best advantage, becaue demo-coder types would be able to do incredibly impressive stuff with it. > Q: In addition to S3 and Verite: have you had the time to evaluate > other cards/chips? Pyramid3D or Chromatic? Not the GLINT300SX for > obvious reasons. Too bad 3D Labs targets a different market, they > already support a Mesa driver project. GLINT300TX + GLINT delta will be a kick-ass workstation setup. 3DFX has the best fill rate around. ATI is no good, because it doesn't have a Z buffer at the moment. I haven't evaluated Pyramid3D or Chromatic. I have an intergraph GL workstation, which is a solid performer, and they have new technology coming out in a few months, but it isn't consumer level stuff. BTW, I just became aware of Mesa last week, and I am very impressed with it. I hope to contribute something to the project when I have more time. I may compatability check my new editor against it. > > Q: Idle curiosity: Michael Abrash mentioned a "Vertex-free > surfaces" approach to Visible Surface Determination that sounded > like using a MAP-like representation for rendering as well. Have > you looked at the NEC/VideoLogic PowerVR chip, which, to my > understanding, uses a similar representation? It was more like using an ultra simple bsp, like the clipping hull, to directly generate the scene. It was cool, and very very space efficient, but not fast enough. It would run great on the PowerVR chip, but because that is such a strange (not mainstream) paradigm, I don't predict great acceptance of PowerVR. John Carmack - ----- End Included Message ----- ------------------------------ End of quake-dev-digest V1 #8 ***************************** From owner-quake-dev-digest@gamers.org Thu Jun 6 23:01 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 XAA14332 for ; Thu, 6 Jun 1996 23:00:18 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id QAA19016 for quake-dev-digest-outgoing; Thu, 6 Jun 1996 16:54:35 -0400 From: owner-quake-dev-digest@gamers.org Date: Thu, 6 Jun 1996 16:54:35 -0400 Message-Id: <199606062054.QAA19016@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #9 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: 29546 X-Lines: 816 Status: RO quake-dev-digest Thursday, 6 June 1996 Volume 01 : Number 009 ---------------------------------------------------------------------- From: Bernd Kreimeier Date: Mon, 3 Jun 1996 20:13:28 +0200 (MET DST) Subject: Info from John Carmack (7) Last but one. Please note that this is the accumulated log since march, less than one q&q per week on average. Note the postscriptum. I will update the Hypermail archive ASAP, and encourage everybody to add other bits of information they got, to keep *me* from asking more stupid questions. Thanks. b. - ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Mon Jun 3 18:08 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Mon, 3 Jun 96 11:07:47 -0500 To: Bernd Kreimeier Subject: Re: q&a (4a) ? Content-Type: text/plain; charset="us-ascii" Content-Length: 3389 You wrote: > Q: In the qtest1 palette, there are >= 16 colors all white. Has the > palette changed, i.e. has it been unfinished? Would it be possible > to release the current/final version? We added another range of fullbright explosion colors, I don't think anything else has changed. > Q: Would you mind providing a hint on the "sealing" of a map? Does > this include a processing step like mentioned by Seth Teller, > fixing small gaps and holes to reduce vis computation and PVS size, > or is it determining "sky" surfaces? I don't fix any small gaps, but removing all the crud on the outside of the level more than halves the data size. After building the BSP tree of the world, I build a graph of the portals between the leaf nodes, then do a simple graph flood fill from the outside of the world. If it ever reaches a leaf with an entity (light, player, etc) in it, it assumes that it leaked inside the level and writes a pointfile containing a trail of dots that can be loaded into quake to find the path that went through the hole. > Q: on NATs and the new MAP format. You wrote: > > >On the NAT front, I am considering changing the .map definition > >to use arbitrary texture origin and S and T vectors on each > >plane, instead of the sofs / tofs / flags values that are > >currently there. > > I expected something like ( x,y,z,s,t ). Instead, there are two > additional values in jrbase1.map that seem to be always 1.0000. > This is supposed to be scaling, in addition to sofs/tofs/flags? > There are "sizing" buttons in the early screenshots of QuakeEd. Or > am I missing something? The textures are arbitrary now, but the definition is a bit confusing. My first thought was "just include S and T vectors on each surface". That is the simple, straightforward representation, but it is bad for editing, because every deformation of a brush needs to modify the vectors. I wound up representing the textures as modifications off of natural texture alignment. shift and scale on each axis plus rotation. It feels clunky, and I doubt it is The Right Thing. > > >BTW, I just became aware of Mesa last week, and I am very > >impressed with it. I hope to contribute something to the > >project when I have more time. I may compatability check my new > >editor against it. > > Actually, texture mapping (esp. mipmapping) is not yet complete (as > of 1.2.8, which is supposed to be the last release for about 6 > months). How about a i586 optimized driver, btw :-)? Mipmapping isn't crucial. I saw the basic wrap/clamp test running, and I glanced at the code, so I don't think it is too horribly far off. I did notice that the parallel array structure of the texture mapping polygon rasterizer is going to guarantee cache associativity collisions on every single scan line. If I can find some time, I would like to donate some work, but my time is a pretty damn scarce commodity. John Carmack ps: I encourage you to share my comments with the rest of the community that might be interested, in the hope of preventing my answering the same questions multiple times... - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Mon, 3 Jun 1996 20:40:14 +0200 (MET DST) Subject: Info from John Carmack (8) Done. From now on, I will simply forward any other info to this list as soon as I get it, which will simplify things a lot. Take your time to digest... b. - ----- Begin Included Message ----- >From johnc@idcanon1.idsoftware.com Sat Jun 1 20:00 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Sat, 1 Jun 96 13:00:27 -0500 To: Bernd Kreimeier Subject: Re: q&a (5) Content-Type: text/plain; charset="us-ascii" Content-Length: 3818 You wrote: > I stumbled across the following two quotes: > > "Carmack made mention of redoing Quake Ed file structure because of > this" (related to some intrusion attempt, I gather) > > Q: Is the MAP format going to change? Btw., sounds strange, what'd > be the advantage (in relation to some pirated pre-release engine)? If the registered pak file had been stolen, but a functional exe had been, then I would probably have made a change to make the final released exe not recognize all the .bsp files in the pirated registered pak file. In any case, they didn't get any data, so I'm not messing with it. > > "Carmack is about 1/3 finished with an NT version of our Map > editor" > > Q: The NT version is done using VC++? Are you going to release that > source? It'd be convenient to port a C++/OpenGL version to Linux. > And futile to reinvent the wheel after the fact. > 1/3 finished is a biiig overstatement. I have the editor view layout mostly functional on my intergraph GL accelerated NT system (its way cool to be running around the map with blended transparent walls in realtime), but it will take me at least a solid two weeks of work after quake's release before the editor is really ready for prime time. I don't know about "futile"... I was actually looking forward to seeing what other people come up with for editor interaction paradigms. If you mean a straight port of QuakeEd, yeah, it might be a waste of time. > You are moving way to fast for weekend code warriors. I managed to > built, change and toy around with QuakeEd (logged my first three > hours on a NeXT - too bad there is no IB and ObjectiveC for Linux). GCC does objective C right now, but it would still be a major porting effor to move it to objc-X or gnustep. > Q: are there any distribution restrictions you want me to put on > QuakeEd related stuff? That is: screenshosts, derivatives of > jrbase1.map, modified sources, NeXT binaries. There is no > qbsp&Cie., thus I cannot imagine any damage (besides spoiling > jrbase1 prior to SW release). However, please let me know. I put it up without consulting our lawyers :-) Consider it all available for any not-for-profit use. > > On the new editor: > > Q: are you going to include any DDE/IPC connection of Quake and > Quakeed? I.e. moving the camera in the editor moves the POV in > Quake, and switches start/stop monster animation etc. For entity > placement and even texture alignment (or lighting), no BSP built > should be necessary. OpenGL previewing might ease texture alignment > pains, but entity placement and fine-tuning the map needs test runs > using the AI. In principle, one needs a way to have server move one > client according to the commands of another client. > > Q: reminds me: still planning on releasing the server sources? All of the .qc code will be relased (QuakeEd parses it for entity names, anyway), but I have gotten a little more reticent about releasing object code and some C code just from a control point of view. Anyway, for large scale server issues it turns out that the best way to control quake is with a wrapper program, instead of modifying internal code. The qc compiler and source will come out withing a couple days of release. I could release the bsp tools around the same time, but I'm not sure if anyone can use them until a generally accessable editor is made. I will release the code for the NT editor when I get it nice and stable. In wireframe mode that should run acceptably even on an unaccelerated system, but it is being designed for hardware acceleration. When everything settles down (version 1.3 or so, probably) I may release the object code with some source files for serious internal tweaking. John Carmack - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Wed, 5 Jun 1996 16:35:23 +0200 (MET DST) Subject: QuakeDev pages update Minor update: + May and June mails + DOOM and Quake color palette page + a couple of NeXT QuakeEd GUI screenshots + draft of Quake Editing primer + removed some (not all) obsoletes See ChangeLog. b. ------------------------------ From: Bernd Kreimeier Date: Thu, 6 Jun 1996 12:51:48 +0200 (MET DST) Subject: QuakeEd 1.2 upload/test1.map I have uploaded with permission on http://www.gamers.org/dEngine/archive/ the following files: QuakeEd-1.2.bin.next-m68k.tgz - a QuakeEd binary QuakeEd-1.2.src.tgz - the current source version QuakeEd-1.2.map.tgz - map files, including test1 test1.map.gz - the qtest1 test1.map file This is not a production release, but it should be useful to anybody having occasional access to a NeXT (like me) and trying to design a GUI for editing. You might even be able to do some map editing. There is no miptex support (yet). Later releases will find their way to ftp.cdrom.com, but I do not think 1.2 is ready for widespread use. Please let me know about any problems ASAP. In addition, John Carmack released the test1.map source as used in the Quake qtest1 release. This offers every BSP builder out there a chance to compare the results on test1.map against the BSP file in qtest1. To anybody working with/modifying QuakeEd: I am maintaing the current sources with CVS. Please send me any patches/diffs/ extensions you are doing, and I will incorporate them in the base. You NeXT guys currently have an advantage :-) but by the time NeXTQuake might be available, QuakeEd might still be the only working editor available to you, so it makes sense to take care of it. Thanks to Steve Larsen who provided his sources and patches for this release, and to Jean-Paul, Jan and Jelske for providing help and NeXT access. Thanks to Vareck Bostrom as well. b. ------------------------------ From: jschuur@onlinemagic.com Date: Thu, 6 Jun 1996 12:31:54 +0000 (GMT) Subject: Re: QuakeEd 1.2 upload/test1.map can you clarify this bern: this version include patches and improvements made to quakeed by people other than id? what about changed johnc has made to quakeed? (his work log indicates that some things were changed in the past week or two). good to see someone is working on the code already. -- joost schuur, Online Magic Ltd. ----------- Tel: +44 171 820 7766 -- ----------------------------------------------------------------------- ---------------------------------------------------------------------- - --- http://www.nuqneH.org/~jschuur/ ---- jschuur@onlinemagic.co.uk --- ------------------------------ From: Bernd Kreimeier Date: Thu, 6 Jun 1996 14:00:58 +0200 (MET DST) Subject: Re: QuakeEd 1.2 upload/test1.map > can you clarify this bern: this version include patches and > improvements made to quakeed by people other than id? A few patches, yep, improvements, nope. > what about changed johnc has made to quakeed? (his work log indicates > that some things were changed in the past week or two) Not included. Yes, there seem to be at least the following ones: * QuakeEd: fixed crash when misselecting an entity angle * QuakeEd: forbid dragging position / direction when textured and some intended: QuakeEd: goto point in command window QuakeEd: view pos button QuakeEd: don't explode if /qcache isn't present QuakeEd: top trace for shearing is at 2048, increase to 8192 This is a problem for several reasons: a) his worklog technique makes it tedious to track this, because you will have to look fot those retrospect "+" entries, too. b) it is not worth while to bother anybody :-) on each single change as long as QuakeEd is not in widespread use c) I did not bother to import QuakeEd in CVS for tracking third party sources (which would have been appropriate for frequent updates) - as I do not benefit that much from the NeXT version, I simply cannot afford the time. I intend to get back to this once they shipped, and he abandoned QuakeEd for his new NT/OpenGL editor. In the meantime, it is more important to 1) get a mipmap WAD2 file done (thus NeXT users might be able to create maps) 2) get a bsp builder running (thus NeXT users will be able to generate maps they can`t play :) and, most important IMO: 3) get a working editor done for Linux :-). Hope this clarifies the issue. b. ------------------------------ From: jschuur@onlinemagic.com Date: Thu, 6 Jun 1996 13:33:43 +0000 (GMT) Subject: Re: QuakeEd 1.2 upload/test1.map On Thu, 6 Jun 1996, Bernd Kreimeier wrote: > 3) get a working editor done for Linux :-). speaking of that, for those who haven't seen it: http://www.canweb.net/~fisty/shaker/ although it appears the author doesn't currently have as much time as he'd like for this project, -- joost schuur, Online Magic Ltd. ----------- Tel: +44 171 820 7766 -- ----------------------------------------------------------------------- ---------------------------------------------------------------------- - --- http://www.nuqneH.org/~jschuur/ ---- jschuur@onlinemagic.co.uk --- ------------------------------ From: Bernd Kreimeier Date: Thu, 6 Jun 1996 17:13:53 +0200 (MET DST) Subject: Editor GUI design Joost wrote: >> a working editor for Linux > speaking of that, for those who haven't seen it: > > http://www.canweb.net/~fisty/shaker/ Reminds me. The screenshots there and incompetently toying around with QuakeEd raised a few issues I would like get some opinions on - namely what an editor should/should not do. Just to get things started (gee, from the looks of it I am the only one using this mailing list), here`s one. More to come. 1) The Axial Bias I haven`t had the opportunity to do serious work with QuakeEd, however, one thing that caught my eye is a certain bias towards axial blocks. First, it is the thing the most easiest to create and manipulate with QuakeEd. You will apply CSG operations to those, mostly. In the end, the overwhelming majority of brushes/polygons is axial. Possible solutions: - -Brush (Group) rotation operations - -Brush Templates, (sets of) polyhedra approximating curved, non-axial surfaces, just a libary - -a separate Brush Editor (Mode) - -DXF/3DS Import Btw. it seems that in QuakeEd there is no way to load a MAP file into a MAP file - the help says "a selection is not cleared when loading a new map, so selections can be brought over from other files", which works, but looks a bit like putting the horse in the saddle... if you catch my drift. Secondly, the View Modes encourage use of axial brushes. The look/down XY View does not invite editing multi-storey editing (there might be a decent z-clipping available, haven`t checked). The Z ScrollView emphasizes this. The CameraView is controlled by DOOM-style cursor movement - there is no mlook, not even a limited look-up/down (not even a fly mode, but a floor up/down). The engine is capable of 3 DoF in both movement and orientation, thus an editor has to have this feature, too. Possible solutions: - -mlook mode - -4 Views, three of them axial, one free Comments anybody? b. ------------------------------ From: Bernd Kreimeier Date: Thu, 6 Jun 1996 17:13:44 +0200 (MET DST) Subject: Re: QuakeEd 1.2 upload/test1.map At least two people seemed to have problems downloading the test1.map.gz. I took the opportunity and cleaned it up (the original NeXT mail from John Carmack had lots of CR/LF inserts breaking up brushes - a brush apparently has to be defined in a single line/removed the "wad" key/ removed "angle"/added "message"/moved "classname" to top), and checked it with QuakeEd. The download problems might be NerdsCraps fault - use SaveLinkAs, beware that the friggin decompresses on the fly. Observations I made on the occasion: a) the POV can be moved with mouse drag&drop, in both XYView and ZScrollView b) no auto-center is performed in XY View c) no auto-detect of current height is done d) on a NeXT cube, PageUp/Down for "next floor up/down" is not available - use ZScroll drag as workaround e) besides being smaller than jrbase1, test1 seems to be slower (or I am getting impatient :) You might get loads of warnings "Entity with no brush and esize_model" on loading the map (it happend with the original one, haven`t checked again). b. P.S.: 'nother thing I learned about how to do an editor is that switching to wireframe/solid, or omitting faraway brushes should be done automatically during movement, with check on framerate. User sets preference, not mode. ------------------------------ From: Olivier Montanuy Date: Thu, 6 Jun 1996 18:24:12 +0200 Subject: RE: Editor GUI design - -----Warning: this message is diplomatically challenged----- [cut-off from Bernd's message...] >The engine is capable of 3 DoF in both movement and orientation, >thus an editor has to have this feature, too. >Comments anybody? Comment is simple: Quake levels are closed. just like Descent mines. how the heck do you think one creates a mine? You walk inside and you cut your way throught the walls, using a suitably shaped object. The .MAP format made of filled convex blocks isn't suitable, in my not possibly humble opinion. That's the way you build houses in the open, not the way you dig mines. What do we care about the exterior of the level? How come it's even calculated? It can even cause errors (leakage). If the map files were substractive (i.e.made of empty blocks, in a filled space, instead of filled block in empty space, it would be much easier to edit and generate. And of course, you should be able to edit the level while walking inside, not via some lame combination of 2D views or delayed camera view. That screams for a portal based scheme. Another company will do it, and will bite market shares off id. Guess who. Not everyone is lost in the Realms of 3D. I might calm down once I get my hands on a PPro 200, but I doubt many Quake players/editors can afford one. The Arrogant Frog (who else?) ------------------------------ From: Bernd Kreimeier Date: Thu, 6 Jun 1996 19:03:17 +0200 (MET DST) Subject: RE: Editor GUI design >Comment is simple: Quake levels are closed. >a mine? You walk inside and you cut your >way throught the walls, using a suitably shaped object. Right. >If the map files were substractive (i.e.made of empty >blocks, in a filled space, instead of filled block in >empty space, it would be much easier to edit and generate. QuakeEd CSG supports this. I am currently working my way through the help.txt (RTFM, as always, my speciality), and naturally, it is possible to create a huge block and bite away. >The .MAP format made of filled convex blocks isn't suitable, I do not agree on this one. Your remark goes straight for the jugular, though - in "densely occluded environments" the empty space you walk in might be a convex or non-convex polyhedron - it cannot be described by a single Brush. Thus creating rooms always means creating a Group of Brushes. QuakeEd starts with empty space, and you start dropping Brushes. In a way, this seems counterintuitive, but the Sealing of the map takes care of the outside border. Not to difficult to get used to. I guess that most of us can handle those small plastic building bricks - not so sure about pickaxes. Surrounding yourself with six big solid brushes and start digging away might be more difficult - I usually loose sense of direction inside a building, not outside :-). Might be bad in terms of final brush count as well. Once you have created the rooms, you are placing furniture - as nobody digs a chair, so to speak. b. P.S.: new GUI checkbox: "Agoraphobia mode on/off". ------------------------------ From: Chris Carollo Date: Thu, 06 Jun 1996 01:17:16 -0400 Subject: Re: Editor GUI design Bernd Kreimeier wrote: [snip] > 1) The Axial Bias > > Possible solutions: > > -Brush Templates, > (sets of) polyhedra approximating curved, non-axial surfaces, > just a libary This seems like a good idea. Obviously primitives like cubes or tetrahedra should be implemented, along with extruded regular polygons. > -a separate Brush Editor (Mode) For designing complex brushes it might be desirable to not display all other brushes. Though I question how often people will be designing complex convex polyhedra. Certainly editing at the level of edge/vertex/entire-brush is necessary in some fashon, but each introduces problems (convexity of brush, coplanarity of faces) > -DXF/3DS Import Importing from 3DS seems to be an everpresent request, but it never quite seems applicable. IMO, an editor needs to be specialized (especially when dealing with brushes) to be really useful. [big snip re: view modes] > Possible solutions: > > -mlook mode A mlook mode seems useful in examining the layout of maps, and not so useful in actually editing the map. When looking at a map at some cockeyed angle, it no longer becomes clear how to easily manipulate entities and brushes in three dimensions. > -4 Views, three of them axial, one free In Quest, I'm including four primary look directions (+X, +Y, -X, - -Y), and also the ability to look in the +Z and -Z directions (in reference to primary look direction). All vertex/edge/brush editing is done perpenticularly to the camera direction. This way, the user cannot change the "depth" of any entity, which is fairly intuative. The downside is that designing very complex brushes (no faces pependicular to any of the view directions) can be a real pain. I'm thinking of adding a "edit-the-current-brush-only" mode where the camera can be rotated freely around the brush. My guess is that the vast majority of brushes will _not_ be complex, and this will not be a major problem, and I won't have to bother coding this. ;) I'm also considering letting the user allow intermediate look directions (i.e. at 45 degree increments instead of 90). Because I'm kind of coding blind (not having the ability to really edit a map yet), I'm not sure if this will be a problem or not. I guess time will tell... > Comments anybody? Likewise... - -Chris Quest page at http://www.cis.ohio-state.edu/~carollo/quest.html ------------------------------ From: Bernd Kreimeier Date: Thu, 6 Jun 1996 20:52:26 +0200 (MET DST) Subject: Re: Editor GUI design >editing at the level of edge/vertex/entire-brush is necessary >in some fashon, but each introduces problems (convexity of brush, >coplanarity of faces) Indeed. Add to the big ToDo list: - - Brush convexity checking - - Brush merge adjacent coplanar - - Brush remove redundant planes (will not create facets) >Obviously primitives like cubes >or tetrahedra should be implemented, There are two approaches: a) Dialog Boxes and GUI interacts (mouse) to create one of a fixed set of primitives b) a generic Load/Save Template mechanisms, and scaling/translation/rotation manipulating a bounding box rep c) both I think (a) and (c) tend to clutter the GUI, but that is a matter of personal preferences. >For designing complex brushes it might be desirable to not display >all other brushes. Again two alternatives: a) a Selection/Filter aproach - you are still within MAP space b) a separate Brush Editor, in model space >When looking at a map at >some cockeyed angle, it no longer becomes clear how to easily >manipulate entities and brushes in three dimensions. Add the major axises to the preview. Define six keys to move along +/- X/Y/Z. One or more slanted views? >an "edit-the-current-brush-only" mode where >the camera can be rotated freely around the brush. In a predominantly XY-plane aligned world (direction of gravity is alsway along Z) it might be useful to have a rotate around the Z axis. There is the tall/short extrude feature in QuakeEd. Taking a XY convex polygon and extending it along Z (or some sloped axis) is a possible mode. Drawing the convex polygon in XY (2D view) in a separate window, for example. There are surely a lot of useful simplifications, and the use of Axial Blocks surely fits man-made environments. However I keep thinking that more or less 2D biased editing will be done anyway. Consider what I call a "Poseidon" level - e.g. a ship wreck on the beach, or even toppled, pockets of air, water surfaces, slippery decks, and no a single XY aligned plane in sight. QuakeEd might or might not be up to the task, but NAT's will be a major pain. You can't even take a given MAP and tilt and roll it a couple of degrees w/o screwing texture alignment (might be fixed if arbitrary texture coordinates are indeed possible now). You can't even do a yaw-rotation (around Z) with a given map or brush selection w/o taking care of the texture alignments, but that's a different issue. b. ------------------------------ From: Bernd Kreimeier Date: Thu, 6 Jun 1996 21:12:45 +0200 (MET DST) Subject: Palette Matching Has anybody taken a look at the Doom PlayPal vs. the Quake palette? I did some matching runs with various metrics in RGB space, and there are very few exact matches, and a larger number of severe mismatches. I haven`t (yet) tried to convert an actual DOOM texture to the Quake Palette, but prospects do not look good. Dithering might help. Has anybody with some experience in handling limited palettes tried? Which, in turn, means that converted or re-done Doom maps should possibly stick to the PlayPal - meaning they cannot use the skin textures matching the Quake palette. In addition, a palette lump should accompany the mipmaps (in the BSP or elsewhere). It`s only 768 bytes, after all, and in perfect agreement with the thinking that puts the mipmaps in the BSP. b. ------------------------------ From: Joel Huenink Date: Thu, 06 Jun 1996 16:00:05 -0500 Subject: Re: Palette Matching Bernd Kreimeier wrote: > > Has anybody taken a look at the Doom PlayPal vs. the > Quake palette? I did some matching runs with various > metrics in RGB space, and there are very few exact > matches, and a larger number of severe mismatches. I > haven`t (yet) tried to convert an actual DOOM texture > to the Quake Palette, but prospects do not look good. > Dithering might help. Has anybody with some experience > in handling limited palettes tried? > > Which, in turn, means that converted or re-done Doom > maps should possibly stick to the PlayPal - meaning > they cannot use the skin textures matching the Quake > palette. In addition, a palette lump should accompany > the mipmaps (in the BSP or elsewhere). It`s only 768 > bytes, after all, and in perfect agreement with the > thinking that puts the mipmaps in the BSP. > > b.Wouldn't basing quake maps on doom maps, and using their textures be copyright infringement? Why not just play doom if you like the map and textures so much, unless you really like a particular map, but I am sure the guys at ID will make som e fun levels. - -- Joel Huenink jh32322@ltec.net Creator of All Hell Coming to a PC near you http://www.conline.com/~huenink/ ------------------------------ End of quake-dev-digest V1 #9 ***************************** From owner-quake-dev-digest@gamers.org Sat Jun 8 22:22 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 WAA18656 for ; Sat, 8 Jun 1996 22:22:05 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id QAA06967 for quake-dev-digest-outgoing; Sat, 8 Jun 1996 16:21:51 -0400 From: owner-quake-dev-digest@gamers.org Date: Sat, 8 Jun 1996 16:21:51 -0400 Message-Id: <199606082021.QAA06967@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #10 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: 28711 X-Lines: 748 Status: RO quake-dev-digest Saturday, 8 June 1996 Volume 01 : Number 010 ---------------------------------------------------------------------- From: jelson@conline.com (Jim Elson) Date: Thu, 06 Jun 1996 16:16:17 -0500 Subject: Re: Editor GUI design At 05:13 PM 6/6/96 +0200, Bernd Kreimeier wrote: > >Reminds me. The screenshots there and incompetently toying >around with QuakeEd raised a few issues I would like get some >opinions on - namely what an editor should/should not do. > >Just to get things started (gee, from the looks of it I am >the only one using this mailing list), here`s one. More to >come. Hahahahahahaha. Perhaps some are like me, still making that conceptual leap from Doom editing to Quake Editing. :) (Very much looking forward to DOS/Win95 editor to facilate this) >1) The Axial Bias > >Possible solutions: > >-DXF/3DS Import I am extremely in favor of this option. When I 1st thought about making Quake levels, my mind immediately though of 3D CAD since I've done a bit of that before. (I do admit I still haven't figured out why QuakeEd is taking a different approach to designing the structure of a level) I also suspect that a DXF import will be highly desired by anyone else with experience in 3D CAD. (heh, finally got some hardware that won't make 3D CAD so damn tedious) - --H2H ============================================================================ H2HMud NorthAmerican DeathMatch Tourney Promo/Marketing Coordinator for "The New Technology: Evilution" - ---------------------------------------------------------------------------- jelson@conline.com; WEB page ==> http://www.conline.com/~jelson/index.html ------------------------------ From: Uffe Friis Lichtenberg Date: Fri, 7 Jun 1996 00:17:29 +0200 (METDST) Subject: Re: Palette Matching On Thu, 6 Jun 1996, Bernd Kreimeier wrote: > Has anybody taken a look at the Doom PlayPal vs. the > Quake palette? I did some matching runs with various > metrics in RGB space, and there are very few exact > matches, and a larger number of severe mismatches. I > haven`t (yet) tried to convert an actual DOOM texture > to the Quake Palette, but prospects do not look good. This corresponds exactly to some of ... (John Carmack?)'s comments. The palette chosen for Quake is far from the palette used in Doom. But I remember reading somewhere (in the log?) that palette now could be level based. Thus the problem seems easy to solve -- simply use the Doom palette. > Dithering might help. Has anybody with some experience > in handling limited palettes tried? In my experience dithering texture maps (at such a low resolution as those of Quake) never gives satisfactorily results. It can only get worse with the mipmapping applied. > Which, in turn, means that converted or re-done Doom > maps should possibly stick to the PlayPal - meaning > they cannot use the skin textures matching the Quake > palette. Any Doom conversion has to include converted sprites. (Just a new skin texture for the player and enemies to start with -- later on new models perhaps). Although low-res, the original sprites could probably be used more or less directly for this. > In addition, a palette lump should accompany > the mipmaps (in the BSP or elsewhere). It`s only 768 > bytes, after all, and in perfect agreement with the > thinking that puts the mipmaps in the BSP. I think (but am unsure) that this is already the case. (I hope.) Think of it: it bloody well *has* to. Otherwise creating Quake levels with completely different settings/themes will be nigh on impossible. Zonk, Uffe. [uphfe] uffefl@diku.dk - -- "This .signature hasn't been left unintentionally void of blankness" ------------------------------ From: Rob Shields Date: Thu, 06 Jun 1996 18:48:13 -0400 Subject: Re: Palette Matching Bernd Kreimeier wrote: > > Has anybody taken a look at the Doom PlayPal vs. the > Quake palette? I did some matching runs with various > metrics in RGB space, and there are very few exact > matches, and a larger number of severe mismatches. I > haven`t (yet) tried to convert an actual DOOM texture > to the Quake Palette, but prospects do not look good. > Dithering might help. Has anybody with some experience > in handling limited palettes tried? > > Which, in turn, means that converted or re-done Doom > maps should possibly stick to the PlayPal - meaning > they cannot use the skin textures matching the Quake > palette. In addition, a palette lump should accompany > the mipmaps (in the BSP or elsewhere). It`s only 768 > bytes, after all, and in perfect agreement with the > thinking that puts the mipmaps in the BSP. > > b. My last project before QMapHack was a set of utilities for personal use that would take a set of images and orient them to use the same palette. With some modifications, I could attempt to convert some DOOM2 textures to QUAKE textures. However, I have not had much experience a far as DOOM2 file formats, so I need to know how to extract the textures and palette from DOOM2 to try this. Rob Shields ------------------------------ From: Uffe Friis Lichtenberg Date: Fri, 7 Jun 1996 01:13:46 +0200 (METDST) Subject: RE: Editor GUI design On Thu, 6 Jun 1996, Olivier Montanuy wrote: > Comment is simple: Quake levels are closed. just like Descent mines. > how the heck do you think one creates a mine? You walk inside and you > cut your way throught the walls, using a suitably shaped object. I don't think you're right. (Have you ever tried using Devil to create Descent levels? Tedious at best, undescribable at worst.) Construction of a level would probably be easier if you had only the `constructive' approach, not the `destructive'. There will of course always be situations where the destructive approach could be easier/more intuitive, but I think this is fewer times than the other way around. (Am I making any sense? Sorry, it's late.) Any editor worth it's salt will have both options of course. What we'll really need for Quake Editor Development is a set of CSG library functions. (Doing the union/intersection/negation calculations, converting to meshes for display, saving as .map primitives, and so on.) Once I get some time on my hands (yeah right) I'll probably start there and work my way up to the GUI later on. > The .MAP format made of filled convex blocks isn't suitable, in my not > possibly humble opinion. That's the way you build houses in the open, > not the way you dig mines. What do we care about the exterior of the level? > How come it's even calculated? It can even cause errors (leakage). Another facet of good editors -- scene validation. Leakage should be simple though. John Carmack even told us (somewhere) how he does. > And of course, you should be able to edit the level while walking > inside, not via some lame combination of 2D views or delayed camera view. I agree on you totally here. After trying out Build (although it is severely limited) I have become convinced that this is the only way really good levels can be built. (It makes it so easy to add that final touch, and placing the really cool details.) > That screams for a portal based scheme. ? The Way My Ideal Editor Would Work - ---------------------------------- (And no I am not implying that I will ever try to implement this. It could be fun, but I could never find the time for it.) * Basically there should be three modes for editing level layout: 1) Brush editing A library of `building blocks' will be necessary to create levels in a reasonable amount of time. Also this is handy to create a consistent look throughout the levels. (Placing similar looking columns, furniture and so on helps maintain a theme.) These brushes has to be creatable and editable. Also CSG must be present to combine brushes. Basically union, intersection and negation is necessary. In my experience CSG eases editing very much. It allows you to create simple to semi-complex stuff in no time and has a very nice learning curve for beginners (or non-techies). 2) Map editing Using the brushes to add to the scene (place stuff) or subtract from the scene (drill holes). Also some operations to translate or rotate large parts of (or perhaps the entire) scene must be present. Moving and deleting individual brushes after they are placed must also be possible. This is used to build architecture, place furniture and other such stuff. Also textures and lights can placed at appropriate places. Lights are of course only used in pre-processing. I am guessing dynamic lights will be entities. 3) Entity placement Placing monsters, health, dynamic lights, switches, doors, bridges and what not. All the rest, so to speak. All these three modes should ideally be accessable at the same time so you don't have to spend time switching screens or even programs. All modes must also be able to work on subsets of the level so the user can concentrate on the task at hand. All editing should be possible using the following views (now this is where I get out of hand): a) Isometric Generic isometric with a view-vector and view-window defined. Hot keys or menu items for `snapping' the view to +X, -X, +Y, -Y, +Z and -Z must be available. Also you must be able to snap to the nearest 45 degree vector so you can get that typical isometric top-down view. b) Perspective The well known view-point and view-direction scheme. As used in Quake. Also hot keys for `snapping' the view should be available. If possible a `Quake Simulation' would be ideal. It doesn't have to simulate AI or any such stuff. But trying the level out (even just in wire-frame) with scene-gravity, and other such server parameters set, could be very useful. (For instance: checking to see whether the player can reach a ledge by jumping or getting a feel for the size of the level.) Both views should be available in wire-frame and textured modes. Texture mapping does not have to be very accurate (ie. perspective correct in perspective mode is not necessary). Just enough to enable proper texture alignment. Both modes should be able to use colour to enhance depth perception and minize drawing overheads. Anyway, this is probably best doable in an environment where 3D API's are available that will allow hardware accelleration and so forth. Wire-frame (with hidden surface removal) should be possible anywhere though. ("Put away that Speccy, Kiddo" :) All editing must be done with an editing plane defined (moving vertices and so forth parallel to it). And for rotation, arbitrary axises (sp?) must be placable. Note: I think a properly done isometric view-scheme is more important than the perspective ``walking in the level'' view-scheme. Also texture mapping, z-buffering and even projection is a lot easier in this. * For the CSG routines it is of prime concern to: 1) Keep precision high, so brushes don't become more and more complicated because of repeated intersections and unions. 3D Studio has this problem to a high degree. Math should probably be integer were possible. (Isn't this why John Carmack chose to have plane definition vectors integer in the .map file?) 2) Fast. We do not wish to wait all day just because we tried to cut a cube out of a wall. Internal map representations should probably maintain a strong position coherence between brushes, so we don't have to check every brush against each other everytime we move something. 3) Perform closures correctly. (Is this the wrong term? I'm rephrasing from memory.) [Foley, et al, Principles and Practice...] has some nice comments on this. Don't know how implementation friendly all of the algorithms are though. * This is of course without considering .mdl editing, .qc editing (seems like a lot of the switch logic and similar stuff has to be placed here), texture-editing, sprite-editing, sound-editing, etc. Any comments? Bye, Uffe. [uphfe] uffefl@diku.dk - -- "Doom was fun, Quake was fun. Now for a *real* challenge... REAL LIFE!" - Anonymous moron "That sucks, let's burn it!" - Beavis (Non-Anonymous moron) ------------------------------ From: Mads Dydensborg Date: Fri, 7 Jun 1996 13:23:23 +0200 (METDST) Subject: Re: Editor GUI design On Thu, 6 Jun 1996, Bernd Kreimeier wrote: > > > Just to get things started (gee, from the looks of it I am > the only one using this mailing list), here`s one. More to > come. Since so few are using this at the moment, please don't flame a newbee for some (more or less) stupid comments. > > 1) The Axial Bias > > I haven`t had the opportunity to do serious work with QuakeEd, Well, only a few has. I'm not one of them either, but.. [..] > > -Brush (Group) rotation operations > -Brush Templates, > (sets of) polyhedra approximating curved, non-axial surfaces, > just a libary > -a separate Brush Editor (Mode) All of this, should of course be a minimum IMHO. > -DXF/3DS Import A DXF => brush converter would be sufficient IMO. [about views during editing] > > Possible solutions: > > -mlook mode > -4 Views, three of them axial, one free > > Comments anybody? What I would try, (But I don't know if it can be done), would be to have an 'instant' preview window, that is the equviliant of the view when playing Quake. When editing I belive frame rates in the order 1-3 ps would be much better than fixed views, and the view could be controlled in the same matter as the player in Quake. I hope that this can be possible using e.g. OpenGL or similar - the typical Quake editor will probably have some very decent hardware. I realise that the map format is not ideal for fast 3d rendering, but the OpenGL stuff I've seen has been quite fast, even for texturemapped stuff. Well, that is what I would try to aim for. >From a not-arrogant dane Mads +----------------------------------------------------------------------+ | Mads Bondo Dydensborg. Student at DIKU, Copenhagen - Denmark. | | Email: madsdyd@diku.dk www: http://www.diku.dk/students/madsdyd/ | +----------------------------------------------------------------------+ ------------------------------ From: Rick Clemmer Date: Fri, 07 Jun 1996 07:50:19 -0500 Subject: Re: Palette Matching At 06:48 PM 6/6/96 -0400, you wrote: >X-gamers.org: quake-dev@gamers.org > >Bernd Kreimeier wrote: >> >> Has anybody taken a look at the Doom PlayPal vs. the >> Quake palette? I did some matching runs with various >> metrics in RGB space, and there are very few exact >> matches, and a larger number of severe mismatches. I >> haven`t (yet) tried to convert an actual DOOM texture >> to the Quake Palette, but prospects do not look good. >> Dithering might help. Has anybody with some experience >> in handling limited palettes tried? >> >> Which, in turn, means that converted or re-done Doom >> maps should possibly stick to the PlayPal - meaning >> they cannot use the skin textures matching the Quake >> palette. In addition, a palette lump should accompany >> the mipmaps (in the BSP or elsewhere). It`s only 768 >> bytes, after all, and in perfect agreement with the >> thinking that puts the mipmaps in the BSP. >> >> b. > >My last project before QMapHack was a set of utilities for personal use that would take a set of images and >orient them to use the same palette. With some modifications, I could attempt to convert some DOOM2 textures >to QUAKE textures. However, I have not had much experience a far as DOOM2 file formats, so I need to know how >to extract the textures and palette from DOOM2 to try this. > Rob Shields Get WinTex 4.2 it can read the DOOM/DOOM2 pallettes and textures. After it reads them just save them to a file. Rick Clemmer ------------------------------ From: Olivier Montanuy Date: Fri, 7 Jun 1996 15:10:29 +0200 Subject: RE: Editor GUI design >Construction of a level would probably be easier if you had only the >`constructive' approach, not the `destructive'. The "mine" image wasn't correct in fact Building a Quake levels should be more like building a space station (well, if you already practiced this as a hobby...). You start from a room, and add more room elements. Convex, like the brushes, but instead of being filled, their are empty. The calculation cannot be more complex than with current brushes. Of course, we could also use normal filled brushes (for some internal furniture) but mainly it has to be done with empty ones. It's as constructive as your approach, but with different stuff. and at least you don't have to wonder about the "exterior", and possible leakage (which are going to be a bore). >Any editor worth it's salt will have both options of course. What we'll >really need for Quake Editor Development is a set of CSG library functions. Ok for the functions. But I think it's the current .MAP format that causes troubles. Whatever CSG you use, you'll have to convert the result into a set of filled brushes, which will make a lot of data. > Note: I think a properly done isometric view-scheme is more important > than the perspective ``walking in the level'' view-scheme. I agree with this... as long as the level is some kind of building with layers. With caves, it's useless. How about VR helmets, now. Olivier ------------------------------ From: "Dark Shadow" Date: Fri, 7 Jun 1996 10:19:25 -0400 Subject: RE: Palette Matching - ---------- > From: Bernd Kreimeier > To: quake-dev@gamers.org; bernd@marvin.nero.uni-bonn.de > Subject: Palette Matching > Date: Thursday, June 06, 1996 3:12 PM > > > Has anybody taken a look at the Doom PlayPal vs. the > Quake palette? I did some matching runs with various > metrics in RGB space, and there are very few exact > matches, and a larger number of severe mismatches. I > haven`t (yet) tried to convert an actual DOOM texture > to the Quake Palette, but prospects do not look good. > Dithering might help. Has anybody with some experience > in handling limited palettes tried? > > Which, in turn, means that converted or re-done Doom > maps should possibly stick to the PlayPal - meaning > they cannot use the skin textures matching the Quake > palette. In addition, a palette lump should accompany > the mipmaps (in the BSP or elsewhere). It`s only 768 > bytes, after all, and in perfect agreement with the > thinking that puts the mipmaps in the BSP. > > > b. Question: Can't you just completely replace the Quake palette with the DOOM palettes? This is a technique I used to totally convert DOOM to the Heretic palette on a project of mine (never released) that made all the nice textures of Heretic (and later HeXeN) fit in DOOM without all that crap that looks like you're on an LSD trip. Since the textures are included in each map file, from what I've read, you could totally replace the palette lump in the BSP and include all the "new" DOOM textures needed in there. Is this just being stupid, or what? - -j ------------------------------ From: Bernd Kreimeier Date: Fri, 7 Jun 1996 16:33:36 +0200 (MET DST) Subject: ADMIN reminder About each recent posting in the "Palette Matching thread" used full quotation. Please remove all obsolete lines and restrict to the necessary parts. Thank you. b. ------------------------------ From: Bernd Kreimeier Date: Fri, 7 Jun 1996 16:41:33 +0200 (MET DST) Subject: RE: Palette Matching > From: "Dark Shadow" > > From: Bernd Kreimeier > > Has anybody taken a look at the Doom PlayPal vs. the > > Quake palette? I did some matching runs with various > Question: Can't you just completely replace the Quake palette with the > DOOM palettes? Sure. You will not be able to combine Quake and DOOM textures. To be able to mix needs a good palette matching. > Since the textures are > included in each map file, from what I've read, Nope. The mipmaps are in the BSP file. > you could totally replace > the palette lump in the BSP I checked the worklog, and did not find the note the Uffe Friis mentioned. For all I know, it is still in the WAD2. b. ------------------------------ From: Mike Ruete Date: Fri, 07 Jun 1996 10:57:21 -0500 (EST) Subject: Re: Editor GUI design On Thu, 6 Jun 1996, Chris Carollo wrote: > > -4 Views, three of them axial, one free > > In Quest, I'm including four primary look directions (+X, +Y, -X, > -Y), and also the ability to look in the +Z and -Z directions (in > reference to primary look direction). All vertex/edge/brush editing > is done perpenticularly to the camera direction. This way, the > user cannot change the "depth" of any entity, which is fairly > intuative. Perhaps you should consider the ability to change the camera direction to be perpendicular to, or coplanar with any surface of the level. In most cad programs, this is a very useful ability. I'd also suggest adding the ability to "grab" a face of a brush and move it "in and out" along it's normal. This would be most useful for six-sided polyhedra, but could have it's uses elsewhere. I've done a reasonable amount of CAD work, and I find multiple views to be extremely helpful. When I edit, I usually have an isometric view, a left side view, a front view, and a top view. I edit in the left, front, and top, but I often use the isometric for getting a feel for what I'm building, and also for selecting edges and faces that would otherwise be overlapped and hard to select in axial views. If I were making an editor, I'd code my wire-frame renderer to work in its own separate window. This way spawning another view and switching the "primary" one would be a lot easier. > The downside is that designing very complex brushes (no faces > pependicular to any of the view directions) can be a real pain. > I'm thinking of adding a "edit-the-current-brush-only" mode where > the camera can be rotated freely around the brush. My guess is that > the vast majority of brushes will _not_ be complex, and this will > not be a major problem, and I won't have to bother coding this. ;) That's not really a valid assumption, though. Speaking as a member of TeamTNT (creators of TNT: Evilution and ICARUS: Alien Vangaurd), I can assure you that what people, especially talented level authors, look forward to most about Quake level editing is the ability to make wacky, non-orthogonal walls/cielings/whatever. If we wanted to do more mostly orthogonal stuff, we'd just keep editing DOOM. I think non-axial views and the ability to (relatively) easily create *very* complex brushes is vital. - -Mike Ruete ------------------------------ From: Bernd Kreimeier Date: Fri, 7 Jun 1996 17:37:29 +0200 (MET DST) Subject: Re: Editor GUI design >From: Mike Ruete > Perhaps you should consider the ability to change the camera >direction to be perpendicular to Second that. I think texture alignment should work like this: click on the facet in any view, one view shows the facet with textures, perpendicular, and the adjacent facets with perspective correct texture mapping. This is for manually fixing NAT screwups. >I'd also suggest adding the ability to "grab" a face of a brush >and move it "in and out" along it's normal. Agreed. Add to this: create facet from vertex (triangle on a cube, as many vertices as incoming edges in general), and collapse facet to vertex. In both cases, you might click on a facet (i.e. the new one), and again a view perpendicular is spawned. Moving the vertices in 2D will tilt the plane in 3D. >I'd code my wire-frame renderer to work in its own >separate window. This way spawning another view and switching the >"primary" one would be a lot easier. This should work within one window as well, with 1 and 4 overlayed Drawing Panes, or am I mistaken. Anyway, the basic idea is sound: each renderer is one object with one (part of) the window. I loathe the windowitis that drowns my desktop in a dozen separate ones, though. >I think non-axial views and the ability to (relatively) easily >create *very* complex brushes is vital. I agree. Think of (approximations) of pipes/spheres/tanks. It does not look like creating a six- or many-sided pillar is a on-stop-shop task in QuakeEd. b. ------------------------------ From: Mike Ruete Date: Sat, 08 Jun 1996 11:17:33 -0500 (EST) Subject: Re: Editor GUI design On Fri, 7 Jun 1996, Bernd Kreimeier wrote: > This should work within one window as well, with 1 and 4 overlayed > Drawing Panes, or am I mistaken. Anyway, the basic idea is sound: > each renderer is one object with one (part of) the window. I loathe > the windowitis that drowns my desktop in a dozen separate ones, > though. If you mean like what WinTex does, I hate that two. What I had in mind was something where you have a main view window, and that window is subdivided into smaller windows. Also, I'm not too familiar with XWindow, so I may have no clue what you're talking about. :) > I agree. Think of (approximations) of pipes/spheres/tanks. It > does not look like creating a six- or many-sided pillar is a > on-stop-shop task in QuakeEd. Speaking of which... Back to the idea of primitives. All primitives should have a "root" point/axis, and there should be plenty of options for aligning that within your level. A couple methods that spring to mind are setting the root point of the primitive on the endpoint/intersection of an edge, and aligning the axis parallel/perpendicular to an existing edge. Also, rotating a primitve about its root axis should probably be the final step in primitive insertion. - -Mike Ruete ------------------------------ From: Nick Rasmussen Date: Sat, 08 Jun 1996 12:08:18 -0500 Subject: Too tied to brushes? Are brushes really the way to go with a new editor? Obviously, if you want to use id's qbsp et al you have to have brushes in the .map file, but I think that the task of creating the brushes is one that could be handled by the editor as the map is saved. A much more intuiative interface (for me at least) is one where you control texture on a per-polygon (and perhaps a per-group of polygons) level. This, along with a perpendicular-to-polygon viewpoint would lend itself easily to alinging textures. Also, not having to bother with the brushes would probably allow faster level design. - -Nick Rasmussen ------------------------------ From: Bernd Kreimeier Date: Sat, 8 Jun 1996 22:21:40 +0200 (MET DST) Subject: Re: Editor GUI design From: Mike Ruete >All primitives should have a "root" point/axis, and >there should be plenty of options for aligning that >within your level. You've lost me. Could you explain? Is this selecting an edge, and/or a vertex, as a frame of reference for moving/rotating the brush? As for aligning two brushes, this reminds me of some related questions: a) is an editing mode with polyhedra-polyhedra 3D collision detection worth the hassle? b) here is a next interaction: pick two facets of two brushes. Now press "glue". One brush will be rotated and translated to stick to the other, selected facet on selected facet. Now there are only 3 degrees of freedom left: in the plane defined by the two parallel facets, move in x,y, or rotate by some angle. >>windowitis >If you mean like what WinTex does, I hate that too. I was actually thinking Sun Mailtool... dunno about WinTex, unfortunately it does not run with Linux :-(. b. ------------------------------ End of quake-dev-digest V1 #10 ****************************** From owner-quake-dev-digest@gamers.org Mon Jun 10 16:51 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 QAA26086 for ; Mon, 10 Jun 1996 16:46:45 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id KAA29716 for quake-dev-digest-outgoing; Mon, 10 Jun 1996 10:46:00 -0400 From: owner-quake-dev-digest@gamers.org Date: Mon, 10 Jun 1996 10:46:00 -0400 Message-Id: <199606101446.KAA29716@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #11 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: 27292 X-Lines: 754 Status: RO quake-dev-digest Monday, 10 June 1996 Volume 01 : Number 011 ---------------------------------------------------------------------- From: Bernd Kreimeier Date: Sat, 8 Jun 1996 22:32:50 +0200 (MET DST) Subject: Info from John Carmack (9) Here's another one. Btw., the flip/mirror question was indeed a stupid one - recognized this too late. And it must be s_ofs t_ofs rot_angle s_scale t_scale obviously, as most Plane lines read "...0 0 0 1 1" now. b. - ----- Begin Included Message ----- >From johnc@idnewt.idsoftware.com Fri Jun 7 20:29 MET 1996 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Transfer-Encoding: quoted-printable X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) From: John Carmack Date: Fri, 7 Jun 96 13:26:18 -0500 To: Bernd Kreimeier Subject: Re: q&a (6) Content-Type: text/plain; charset="us-ascii" Content-Length: 3559 You wrote: > > Q: gravity is fixed along Z. Would there be unreasonable overhead > assigning a gravity/current/force vector to a volume (like the > water/lava attribute is maintained)? We have "push triggers" that assign a velocity when you are inside them. We use them for flinging players through gerbil tubes. They aren't exactly what you want (you have no control when in them), but it is just qc code and could be changed easily. There are efficiency issues with using them all over the place, but they aren't too bad. > Q: besides lava-style texture animation, is there a simple s/t > scroll animation? Different speeds? Not for normal textures, because the light map samples are tied to a block structure. I could slide the turbulent textures, because they don't have lightmaps, but I haven't put any interface in for it. It will probably show up in Quake 2. > Q: wouldn`t it be better to include the palette (768 bytes) along > with the mipmap lumps in the BSP? Solely for using DOOM playpal, or > other full palette replacements. MDL skins etc. will be a problem, > but entities are external references anyway. The palette is included along with the misc graphics, like the console and status bar. If you want to use a different palette, you are going to have to create all new graphics for everything else. I really doubt it is worth it. > > Q: am I mistaken that, with "s/t_ofs s/t_scale rot", it is not > possible anymore to flip/mirror a texture, because of using NAT's? A negative scale is a flip. > > This is confusing :-(. Ceterum censeo: shouldn't NAT's be assigned > within QuakeEd/any editor, and the result be saved as (s,t). > Semi-auto texture alignment is an editor feature. The brushes > aren`t human readable anyway. Ah well, I will shut up on this one. > The .map file is the editor file format, so it has representations convenient for the editor. The .bsp file has representations convenient for rendering. I tried just putting in s/t vectors for the planes, but it makes many editor operations cumbersome. I know, I know. It doesn't feel right to me either. > Q: the MAP format does not allow for persistent hierarchy/grouping > (which is useless for qbsp, but useful for editing). Care to > comment on: > > --------------------------------- >{ > "classname" "worldspawn" > "message" "The House" > { > "_label" "The Bathroom" > { > ( .., .., .. ) WALLTILE .... > ( .., .., .. ) WALLTILE .... > ... > } > { > // more brushes > } > // end bathroom > } > { > "_label" "The Living Room" > { > ( .., .., .. ) CARPET .... > // more brushes > } > } > // more rooms >} > ------------------------------- This is changing with my NT editor. The entity grouping groups brushes very nicely allready. I am just going to add a little change to qbsp so that an entity with a classname of "submodel" or something will just be merged into the world entity for bsp generation. > The MAP files will have a life expectancy exceeding Quake's by far. > As far as 3D map editing is concerend, it is time to think > "progressive refinement" - or "kaizen". Btw., the more I think my > way through brush based editing, the more I like it - this has been > a damn good idea. Yes, I still think I made the right decision for solid based editing, and I think it will be adopted widely. I was charmed to see Epic using my "brush" terminology in describing their unreal editor :-). John Carmack - ----- End Included Message ----- ------------------------------ From: Bernd Kreimeier Date: Sat, 8 Jun 1996 22:41:27 +0200 (MET DST) Subject: Re: Info from John Carmack (4) John Carmack wrote: >> will the linux version be ... as modules (gcc-linkeable) >I have intentions to do so, but since Dave Talor left id This is a comment from Dave Taylor. - ----- Begin Included Message ----- >From ddt@crack.com Mon Jun 3 20:25 MET 1996 From: Dave Taylor To: Bernd.Kreimeier@NeRo.Uni-Bonn.DE Subject: Re: Linux Quake port > a) Thanks heaps welcome > b) If you get around to release a LinuxQuake, would it be possible > to release it as linkable modules like the intended DJGPP release > (see mail quoted below)? Should be. > c) ... > Would it be possible to run LinuxQuake with DDE/IPC > to control player position and LOS from the editor, i.e. to > use LinuxQuake as an interactive preview (including monster > animation)? It would of course be possible to write this. However, it won't be written. Sorry. =-ddt-> - ----- End Included Message ----- ------------------------------ From: jschuur@onlinemagic.com Date: Sun, 9 Jun 1996 00:39:40 +0000 (GMT) Subject: list your quake editing project i'd like to list all the quake editors currently under developement on aftershock, in it's diy section. have a look at http://www.nuqneH.org/aftershock/diy/editorsmake.html and drop me a line if you're working on an editor you'd like to have mentioned there. -- joost schuur, Online Magic Ltd. ----------- Tel: +44 171 820 7766 -- ----------------------------------------------------------------------- ---------------------------------------------------------------------- - --- http://www.nuqneH.org/~jschuur/ ---- jschuur@onlinemagic.co.uk --- ------------------------------ From: Andrew Gilpin Date: Sat, 08 Jun 1996 23:29:07 -0500 Subject: Re: list your quake editing project jschuur@onlinemagic.com wrote: > > i'd like to list all the quake editors currently under developement on > aftershock, in it's diy section. have a look at > > http://www.nuqneH.org/aftershock/diy/editorsmake.html > > and drop me a line if you're working on an editor you'd like to have > mentioned there. > > > > -- joost schuur, Online Magic Ltd. ----------- Tel: +44 171 820 7766 -- > ----------------------------------------------------------------------- > ---------------------------------------------------------------------- > --- http://www.nuqneH.org/~jschuur/ ---- jschuur@onlinemagic.co.uk --- I am one of the programmers working on QMapHack, but I think it is already listed on the DIY page. Anyways the homepage for QMapHack is http://www.eve.net/~rshields/ - -- Andrew Gilpin mailto:agilpin@eve.net http://www.eve.net/~agilpin/ ------------------------------ From: Uffe Friis Lichtenberg Date: Sun, 9 Jun 1996 20:58:34 +0200 (METDST) Subject: RE: Editor GUI design On Fri, 7 Jun 1996, Olivier Montanuy wrote: > Building a Quake levels should be more like building a space station > (well, if you already practiced this as a hobby...). ;) > You start from a > room, and add more room elements. Convex, like the brushes, but instead > of being filled, their are empty. > The calculation cannot be more complex than with current brushes. Well, that's OK if you want to build a space station/mine/and so on, but for other architectural ideas it might not be ideal. I agree the _calculations_ can't be more complex than the other way round, but converting them back to .map is surely gonna be more complex when you do subtractive CSG operations rather than additive. Still, a good editor should support both ways... > It's as constructive as your approach, but with different stuff. > and at least you don't have to wonder about the "exterior", and possible > leakage (which are going to be a bore). Well sure, leakage is gonna suck, but with proper .map validation routines it should be possible to detect automatically and perhaps even fix semi-automatically. > Ok for the functions. But I think it's the current .MAP format that causes > troubles. Whatever CSG you use, you'll have to convert the result into a set of > filled brushes, which will make a lot of data. Exactly. It the to .map function that will be the hard one to code. I have been thinking somewhat like this: BTW: This is C++ which makes me think: what would be of most interest to the rest of the Quake editing community, C or C++? (Mads: I'm not going to use Delphi, no I'm not! ;) class CSGtree { public: CSGtree(Brush b); // Instantiate leaf // + other constructors and the usual stuff CSGtree operator+(const CSGtree other) const; // return union of *this and other CSGtree operator*(const CSGtree other) const; // return intersection of *this and other CSGtree operator-(void) const; // (unary minus... is this the correct syntax? can't really remember) // return negation of *this PolygonMesh toPolygonMesh(void) const; // return polygon mesh representing CSGtree CSGtree normalize(void) const; // return `normalized' CSG representation (self-made terminology) // (ie. one using only unions; an any-order traversal of the // tree would produce output suitable for a .map file) Brush toBrush(void) const); // return a single brush representing *this (if possible) CSGtree transform(Matrix4x4 m) const; // transform node and leaves using the given matrix CSGtree translate(Vector3 v) const; // translate node and leaves using the given vector // (ie. setup matrix and use transform() for naive implementation CSGtree rotateX(float a) const; // rotate... // + all the other handy editing functions you could think of... } (Of course this interface is very `top-level' and should be optimized with references or pointers where appropriate. Also non-const (but state-changing) functions should be available to offer efficiency where you know you won't be needing the `old' instance. This should give the general idea... Otherwise tell me I'm rambling :) (I'm assuming proper classes for PolygonMesh and Brush, but this should be somewhat more trivial. PolygonMesh would probably just be a list of polygons, but rendering could possibly benefit from using BSP or other pre-sorting, as they shouldn't be recalculated constantly. A Brush would probably just be a list of planes. Here BSP might be useful too, who knows.) All operations should then be performed upon CSG representations with operators at the nodes and brushes at the leaves. The tricky functions will be toPolygonMesh(), normalize() and toBrush(). toPolygonMesh() should be managable. The trick will be to keep the polygon count relatively low (ideally as low as possible). If the given CSGtree is a leaf (ie. a brush) it should be (relatively) trivial to perform all intersections between the planes to get list of polygons. Otherwise you would just apply the funcion recursively and then unite/intersect/negate polygon meshes. `Dead' polygons (ie. polygons inside the object, never visible) should of course be culled. Real problem: speed and accuracy. Check out 3D Studios boolean operations on their triangle-meshes. Verry buggy/slow/inadequate. Speed will probably never reach real-time rates, so an editor will need to remember the PolygonMesh returned by toPolygonMesh() and only force a recalculation when necessary. normalize() should identify the smallest amount of brushes necessary for the conversion. Unions are easy: they convert one-to-one, but if the union can be represented as one brush (ie. it is still convex) it should be reduced to that (using toBrush()). Intersections are easy too: just collapsing the two brush representations (list of planes) produces correct output, but redundant planes (ie. planes that have no influence on the objects shape) should be removed. As goes for negation: well, I'll have to think on that (anybody?) as this might influence the rest of the process. Perhaps converting a negation of an n-planed brush to n-large-enough-brushes defining the outside as inside would be sufficient. But it must also be applicable to a CSG'ed child... Hmmm... toBrush() simply checks wether the CSG representation is convex and, if so, converts it to a plane-list (ie. brush). Redundant planes are stripped. (But how to identify these? Oh well, paper and pencil...) I have a feeling all this work has been done before, so I'll probably be doing some litterature searching soon. Anybody know any good texts on CSG? > I agree with this... as long as the level is some kind of building with layers. > With caves, it's useless. Of course. I forgot layers! A good editor _must_ be able to define part of the scene as a group (/layer) and enable the user to easily distinguish between the groups (/layers). Probably using colours. This of course has no relation to what you just said but the word `layer' triggered something :) For caves you are right. The only way to do this easily is to walk around inside the level. Perspective and all... > How about VR helmets, now. Heh... Even if I could afford one (which I can't) I wouldn't use one, let alone buy one. The quality of available/semi-affordable VR helmets I have tried is low.... (I take this was a jest anyway ;) Bye, Uffe. [uphfe] uffefl@diku.dk - -- "This .signature hasn't been left unintentionally void of blankness" ------------------------------ From: Uffe Friis Lichtenberg Date: Sun, 9 Jun 1996 21:01:36 +0200 (METDST) Subject: RE: Palette Matching On Fri, 7 Jun 1996, Bernd Kreimeier wrote: > > you could totally replace > > the palette lump in the BSP > > I checked the worklog, and did not find the note the Uffe Friis > mentioned. For all I know, it is still in the WAD2. I was probably wrong... (On the other hand... Oh well, better go searching ;) Zonk, Uffe. [uphfe] uffefl@diku.dk - -- "This .signature hasn't been left unintentionally void of blankness" ------------------------------ From: Uffe Friis Lichtenberg Date: Sun, 9 Jun 1996 21:19:53 +0200 (METDST) Subject: Re: Editor GUI design On Sat, 8 Jun 1996, Bernd Kreimeier wrote: > a) is an editing mode with polyhedra-polyhedra > 3D collision detection worth the hassle? Hm. Possibly. But it will be a bitch to code efficiently. Let's concentrate on functions that will allow us to align objects first, like (b). Then work from that. > b) here is a next interaction: pick two facets of > two brushes. Now press "glue". One brush will > be rotated and translated to stick to the > other, selected facet on selected facet. Now > there are only 3 degrees of freedom left: > in the plane defined by the two parallel facets, > move in x,y, or rotate by some angle. Ooh I like that. I hadn't really given much thought to alignment functions yet... What about (I assume a work-plane and work-line has been defined): c) `Snap to plane'. Translate selected object along work-plane normal so the center of the object (ie. (0,0,0) in object coordinates) lies on the work-plane. d) `Snap to line'. Translate selected object along a normal to the work-line, where the normal used goes through the center of the object. The center of the object ends up on the work-line. e) `Rotate about line'. Using the work-line as axis, rotate selected object any amount. f) `Move parallel to plane'. View switches so the view-plane is parallel to the work-plane. Objects can then be moved parallel (in screen XY) to the work plane. Moving the object along a work-plane normal (in screen Z) could possibly be achieved using another set of keys or a held mouse-button or something. g) `Drop object'. Place object in 3-space and let go. Object falls (along gravity vector) to the floor. (Option: if the floor is tilted the object migh slide until it comes to rest???) h) Work-plane must be translatable and rotatable (around work-line). Also it must be settable to any face in the scene or to a span of any three vertices. i) Work-line must be translateable and rotatable (around another work-line?). Also it must be settable to any edge in the scene or to a span of any two vertices. j) `Hang object'. Place object in 3-space and let go. An invisible wire is connected between the work-line (arbitrarily placed or closest point) and the center of the object. Then the object is transformed as if it was hanging in that wire from the work-line. k) I could go on... ;) Zonk, Uffe. [uphfe] uffefl@diku.dk - -- "This .signature hasn't been left unintentionally void of blankness" ------------------------------ From: Mike Ruete Date: Sun, 09 Jun 1996 17:10:11 -0500 (EST) Subject: Re: Editor GUI design On Sat, 8 Jun 1996, Bernd Kreimeier wrote: > >All primitives should have a "root" point/axis, and > >there should be plenty of options for aligning that > >within your level. > You've lost me. Could you explain? Is this selecting > an edge, and/or a vertex, as a frame of reference for > moving/rotating the brush? Yes, that's exactly what I meant. You'd have to select and edge (or a line selected from two points) that would be your axis, then you select another point (usually on the axis) which would be the origin of the brush's frame of reference. Then when you went to insert the brush, for example, you could select the mid-point of an existing edge to put the origin at, and then choose, for example, to align the axis with another existing edge. > a) is an editing mode with polyhedra-polyhedra > 3D collision detection worth the hassle? I doubt it. Doesn't on of id's utilities (qbsp, I think) do clipping of brushes before the final list of vertices and edges is determined (and before nodes are built)? Of course, if you're using home-grown node builders and other utils (which I'm sure we all eventually will be seeing as we can't all get access to a 4-processor alpha for nodes and lightmaps), then it's most definitely worth the hassle, because you probably wouldn't be able to make a proper map without it. - -Mike Ruete ------------------------------ From: Mike Ruete Date: Sun, 09 Jun 1996 17:21:19 -0500 (EST) Subject: Re: Info from John Carmack (4) > This is a comment from Dave Taylor. [snip] > > c) ... > > Would it be possible to run LinuxQuake with DDE/IPC > > to control player position and LOS from the editor, i.e. to > > use LinuxQuake as an interactive preview (including monster > > animation)? > > It would of course be possible to write this. However, it won't be > written. Sorry. This sounds like the Duke3D (build) editor. If you haven't seen it, you owe it to yourself to check it out and get an idea of its power. It actually uses the build engine inside the editor to show you *exactly* what your level will look like in the game (of course, your gamma settings won't be the same, and some of the sprites are scaled differently). It also allows a lot of editing in the 3d preview mode. Things like light levels, textures, floor/cieling height/slants can be changed. It's really an incredibly powerful editor, and if I ever try to develop a quake editor, i'd try and make it look alot like the Duke3d editor. Oh, and running the editor in 800x600, it displays the 3d preview faster than the actual game runs in 320x240. :) - -Mike Ruete ------------------------------ From: Rob Shields Date: Sun, 09 Jun 1996 22:45:47 -0400 Subject: Doom2 pics with Quake palette I have been able to convert the Doom2 images to use the Quake palette. I used DMView and just extracted all of the pics, then converted them all, mainly because I did not want to sort through 2288 images looking for textures. We now have the 2288 Doom2 images using the Quake palette. They take up 13.6 megabytes uncompressed, 5.5 megabytes zipped with the -ex parameter. They mostly look the same as the originals, if they are different they are slightly darker giving a "scarier" effect. Now that I have these images, how should I go about getting them to those in this mailing list who want them? Rob Shields ------------------------------ From: Bernd Kreimeier Date: Mon, 10 Jun 1996 11:13:08 +0200 (MET DST) Subject: Re: Editor GUI design >> a) is an editing mode with polyhedra-polyhedra >> 3D collision detection worth the hassle? > I doubt it. Doesn't on of id's utilities (qbsp, I think) do >clipping of brushes before the final list of vertices and edges is >determined (and before nodes are built)? > > -Mike Ruete Been misleading. I meant as a GUI option for editing - a paradigm :-). It does some kind of auto-alignment for brushes: set a gravity or a push direction, and drop the thing into the map. You only have to check all facets of the moving brush against all others, is O(N_brushes) or O(N_facets). This is not useful for CSG operations, obviously :-). b. ------------------------------ From: Bernd Kreimeier Date: Mon, 10 Jun 1996 11:35:50 +0200 (MET DST) Subject: Re: Doom2 pics with Quake palette > From: Rob Shields > I have been able to convert the Doom2 images to use the Quake palette. Great. Saves me some hassle. > They mostly look the same as the originals The match I made with a 2*delta_Red + 3*delta_Green + 1*delta_Blue gave less than 30 exact matches, and about the same with a perceived distance >= 20.0. Prospects did not look to good. Will be interesting to see your images (and the mipmapped versions, later). > how should I go about getting them to those in this mailing list > who want them? Legal issues: you should not distribute DOOM registered or commercial textures. It would be great if you could separate those from the DOOM shareware WAD. Next, the conversion is a "derivative work". We should ask id prior to any distribution. Finally, the Quake palette has changed (there are more than 16 whites in a sequence, and John Carmack mentioned additional explosion colors, see Info (7) mail) - thus the matches might change again. A few shareware textures as example, exported as GIF might be a good idea. Perhaps you could download the DOOM Palette GIF from my palette page at http://www.gamers.org/dEngine/quake/wad_conv and apply the same conversion, I will happily upload the result, and look at the index->index mapping. Does anybody know what kind of palette matching algorithm DMVIEW actually uses? Is the source available (the author around)? b. P.S.: the remark by John Carmack in Info (5) seemed to indicate that Adrian Carmack and Kevin Cloud did not like the results of a similar conversion. I wonder what kind of matching they tried, and when. ------------------------------ From: Olivier Montanuy Date: Mon, 10 Jun 1996 11:37:32 +0200 Subject: Re: Editor GUI design > If you mean like what WinTex does, I hate that two. What I had >in mind was something where you have a main view window, and that window >is subdivided into smaller windows. Also, I'm not too familiar with >XWindow, so I may have no clue what you're talking about. :) Just to let you know: the main reason why WinTex opens a dozen small windows that keep popping out everywhere ... is because of a limitation of Visual Basic. Of course I would prefer to have just ONE windows, and alter it's shape depending on context. It's the best solution. I hope everyone will do that for Quake editors! But it's just not possible with a lame tool like VB. If you look at the WinTex main window, it already has 4 overlapped frames (with only one visible) and that's enough to make Vb crawl like hell. Olivier (WinTex runs fast on a P200) ------------------------------ From: matt.tagliaferri@pcohio.com (Matt Tagliaferri) Date: Mon, 10 Jun 1996 09:23:00 -0500 Subject: Re: Editor GUI design q > Just to let you know: the main reason why WinTex opens a dozen small w q > that keep popping out everywhere ... is because of a limitation of Vis q >Basic. q > Of course I would prefer to have just ONE windows, and alter it's shap q > depending on context. It's the best solution. I hope everyone will do q > for Quake editors! q > But it's just not possible with a lame tool like VB. If you look at th q > WinTex main window, it already has 4 overlapped frames (with only one q >visible) q > and that's enough to make Vb crawl like hell. q > Olivier I do NOT want to start any "my tool is better than yours" war here, I would just like to let Olivier know that I too was a VB programmer, and converted to Delphi with the help of a fellow programmer I met in the Doom editing mailing list. If you have a basic knowledge of Pascal, you're more than 1/2 way there. IT's just as easy a tool to use as VB, once you know a few tricks. If you have any interest in learning this tool, Olivier, please contact me privately. I'd be happy to help in any way I can, including sharing source with my Delphi-converted DoomCAD to get you started. matt tagliaferri matt.tagliaferri@pcohio.com - --- * PW * _ _ ------------------------------------------------------------- |_|_| PC-OHIO PCBoard Online * pcohio.com * V34+ 33.6: 216-381-3320 |_|_| The Best BBS in America * Cleveland, OH * Go Tribe ------------------------------------------------------------- ------------------------------ From: Mike Ruete Date: Mon, 10 Jun 1996 10:49:19 -0500 (EST) Subject: Re: Editor GUI design On Mon, 10 Jun 1996, Olivier Montanuy wrote: > Just to let you know: the main reason why WinTex opens a dozen small windows > that keep popping out everywhere ... is because of a limitation of Visual Basic. That's why god (or at least someone at Bell Labs) gave us C. :) > Olivier > (WinTex runs fast on a P200) - -Mike Ruete (WinTex runs fast on a P100 w/ 32MB EDO ------------------------------ End of quake-dev-digest V1 #11 ****************************** From owner-quake-dev-digest@gamers.org Wed Jun 12 09:23 MET 1996 Received: from olymp.informatik.uni-bonn.de (root@olymp.informatik.uni-bonn.de [131.220.4.1]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id JAA00981 for ; Wed, 12 Jun 1996 09:23:11 +0200 (MET DST) Received: from gamers.org (majordomo@thegate.gamers.org [128.205.37.150]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with ESMTP id AAA18295; Wed, 12 Jun 1996 00:39:18 +0200 (MET DST) Received: (from majordomo@localhost) by gamers.org (thegate/gamers) id SAA11600 for quake-dev-digest-outgoing; Tue, 11 Jun 1996 18:20:40 -0400 From: owner-quake-dev-digest@gamers.org Date: Tue, 11 Jun 1996 18:20:40 -0400 Message-Id: <199606112220.SAA11600@gamers.org> To: quake-dev-digest@gamers.org Subject: quake-dev-digest V1 #12 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: 26147 X-Lines: 709 Status: RO quake-dev-digest Tuesday, 11 June 1996 Volume 01 : Number 012 ---------------------------------------------------------------------- From: Jim Lowell Date: Mon, 10 Jun 1996 10:44:34 -0500 Subject: Tools (was Re: Editor GUI design) At 10:49 AM 6/10/96 -0500, Mike Ruete wrote: > > >On Mon, 10 Jun 1996, Olivier Montanuy wrote: > >> Just to let you know: the main reason why WinTex opens a dozen small windows >> that keep popping out everywhere ... is because of a limitation of Visual Basic. > > That's why god (or at least someone at Bell Labs) gave us C. :) > ... and C is why Borland gave us Delphi. :) - -= Jim Lowell =- ------------------------------ From: Rob Shields Date: Mon, 10 Jun 1996 12:46:00 -0400 Subject: Re: Doom2 pics with Quake palette Bernd Kreimeier wrote: > Legal issues: you should not distribute DOOM registered or commercial > textures. It would be great if you could separate those from the > DOOM shareware WAD. Next, the conversion is a "derivative work". We > should ask id prior to any distribution. Finally, the Quake palette > has changed (there are more than 16 whites in a sequence, and > John Carmack mentioned additional explosion colors, see Info (7) > mail) - thus the matches might change again. > > A few shareware textures as example, exported as GIF might be a good > idea. Perhaps you could download the DOOM Palette GIF from my palette > page at http://www.gamers.org/dEngine/quake/wad_conv and apply the > same conversion, I will happily upload the result, and look at the > index->index mapping. > > Does anybody know what kind of palette matching algorithm DMVIEW > actually uses? Is the source available (the author around)? > > b. DMView did not do the palette matching, I did. My algorithm extracted the Quake palette from GFX.WAD, and the Doom2 palette from the first bitmap it scanned. I then made a look up table between the two palettes as to which entries in the Doom2 palette corresponded to which entries in the Quake palette. If there were no exact matches, I found the closest one by using an adapted version of the distance formula, (((r2-r1)^2)+((g2-g1)^2)+((b2-b1)^2))^(1/2). Then I just went through the bitmaps created by DMView, replaced the palette with the Quake palette, then went through the actual picture data and replaced the old bytes with the corresponding new values as defined in the look up table. So I now have 2288 .BMP files which use the Quake test palette. I wrote the program in QuickBASIC 4.5 for ease of debugging, and I can post the source code here if you want. Rob Shields ------------------------------ From: Bernd Kreimeier Date: Mon, 10 Jun 1996 19:03:22 +0200 (MET DST) Subject: Re: Doom2 pics with Quake palette From: Rob Shields [ ADMIN - please do not do full quotes - b. ] >Bernd Kreimeier wrote: >> Does anybody know what kind of palette matching algorithm DMVIEW >> actually uses? Is the source available (the author around)? >DMView did not do the palette matching, I did. > ... >If there were no exact matches, I found the closest one by using >an adapted version of the distance formula, > ((r2-r1)^2)+((g2-g1)^2)+((b2-b1)^2))^(1/2). > ... >I wrote the program in QuickBASIC 4.5 for ease of debugging, and I >can post the source code here if you want. Not necessary, but I would appreciate confirmation of the exact matching formulae. What does "adapted" mean? Remark: the distance formulae above does not take into account the human eye's differing sensibility for the base colors - usually, we are most sensitive for varying Green, and far less for Blue. This should change some of the matches (and results). Have you tried e.g. the 2/3/1 weighted formulae, or something else (some day I will try HSV just for curiosities sake), or the straight 1/1/1 weights only? b. Btw.: perhaps we should postpone further experimentation until the final Quake palette is available. ------------------------------ From: Mads Dydensborg Date: Mon, 10 Jun 1996 21:29:15 +0200 (METDST) Subject: Off topic : Delphi NOTE : This message concerns Delphi and is meant primarily for Quake developers (wannabe's), that would like to develop using Delphi. If you want to reply/comment, you should answer to me personally, unless b. gives a green light for discussion. (Hope this one starter is OK. Don't flame, please). There has been some people commenting about Delphi, and ease of use, etc. I too use Delphi (and prefer it to both C(++) and VB) I would like to hear if there is a general interest among Delphi- subscribers to this list, in establishing some Delphi-Quake forum? The forum should off course be regarded as an supplement to this list and other ressources (like the developer pages, etc), and should just help Delphi programmers with implementing Quake related stuff. I personally could envision that the forum could contain information as : - - interfacing with OpenGL. - - interfacing with DirectDraw - - BSP file handling routines - - PVS building routines - - MAP handling routines - - CSG handling routines - - MipMap handling routines (Well, I did write something here ;-) - - etc All of these will propably quickly be available with C(++) interfaces, but I, for one, would like to have some true Delphi code to work with. Would anyone else care to contribute to something like this? Please answer directly to madsdyd@diku.dk (unless you dare cross b.'s directions.) Mads (Once again : Please forgive me for beeing slightly off-topic). +----------------------------------------------------------------------+ | Mads Bondo Dydensborg. Student at DIKU, Copenhagen - Denmark. | | Email: madsdyd@diku.dk www: http://www.diku.dk/students/madsdyd/ | +----------------------------------------------------------------------+ ------------------------------ From: Rob Shields Date: Mon, 10 Jun 1996 15:42:17 -0400 Subject: Re: Doom2 pics with Quake palette Bernd Kreimeier wrote: > Not necessary, but I would appreciate confirmation of the exact > matching formulae. What does "adapted" mean? Remark: the distance > formulae above does not take into account the human eye's differing > sensibility for the base colors - usually, we are most sensitive for > varying Green,