From quake-editing-owner@nvg.unit.no Mon Mar 4 15:10 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id PAA14473 for ; Mon, 4 Mar 1996 15:10:28 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id OAA01131 for quake-editing-outgoing; Mon, 4 Mar 1996 14:31:26 +0100 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id OAA01026 for ; Mon, 4 Mar 1996 14:27:50 +0100 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id OAA14240 for ; Mon, 4 Mar 1996 14:27:49 +0100 (MET) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id OAA27651 for quake-editing@nvg.unit.no; Mon, 4 Mar 1996 14:27:45 +0100 (MET) From: Bernd Kreimeier Date: Mon, 4 Mar 1996 14:27:45 +0100 (MET) Message-Id: <199603041327.OAA27651@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: Welcome to Quake Developers! X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1587 X-Lines: 44 Status: RO Welcome to the Quake Developer's list! For once, I will use the privilege and talk while everbody listens. I hope that you will find this list worthwhile and useful, and that you will find it a professionally minded and enjoyable place. The purpose of this list is to get things organized. In particular, it will provide a channel of communication to keep us from inventing the wheel all over again, and to help us to spawn cooperative efforts. It is dedicated primarily to those of us writing free software, free in the sense that there is a free flow of information, meaning sources and algorithms, but not necessarily meaning free for commercial use, or free-for-all. It is not important wether or not you are a professional, however, a professional attitude is important. A final warning: despite the name of the list, do not restrict your thinking to Quake and nothing but Quake. It is a large world out there, and it is getting larger every day. This list will focus on Quake as a cutting edge sample of a whole genre of games - meaning configureable, extensible engines. We will see a lot more of this in upcoming years. Configuring and extending such games is a complicated task and cannot be done without sophisticated tools, which, in turn, cannot be created, improved and maintained on a day to day basis. There is only so much that can be done from scratch. Take the long view. The next three years will change the world even more than the last three years did. You might want to make a difference. Carpe Diem. b. From quake-editing-owner@nvg.unit.no Mon Mar 4 15:16 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id PAA14572 for ; Mon, 4 Mar 1996 15:16:42 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id OAA01272 for quake-editing-outgoing; Mon, 4 Mar 1996 14:36:38 +0100 Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id KAA28730 for ; Mon, 4 Mar 1996 10:55:49 +0100 Received: from ebcs08.ebc.ericsson.se (ebcs08.ebc.ericsson.se [130.100.114.67]) by mailgate.ericsson.se (8.6.11/1.0) with ESMTP id KAA21514 for ; Mon, 4 Mar 1996 10:55:39 +0100 Received: from ebcw405.ebc.ericsson.se (ebcw405 [130.100.167.197]) by ebcs08.ebc.ericsson.se (8.6.9/8.6.9) with ESMTP id KAA29378 for ; Mon, 4 Mar 1996 10:58:06 +0100 Received: by ebcw405.ebc.ericsson.se (SMI-8.6/client-1.5) id KAA17680; Mon, 4 Mar 1996 10:55:16 +0100 Date: Mon, 4 Mar 1996 10:55:16 +0100 Message-Id: <199603040955.KAA17680@ebcw405.ebc.ericsson.se> From: Raphael.Quinet@eed.ericsson.se To: quake-editing@nvg.unit.no Subject: Quake data structures Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 9003 X-Lines: 277 Status: RO Hello! As some of you already know, I have been working on the Quake data files, trying to decode all of them and understand their format. My intent is to provide a standard library for reading and writing Quake files, which can be used in any Quake editor. Included here is a list of functions which are provided by the current QEU library for reading and writing the various file formats. The main differences between QEU 0.2 and QEU 0.3 are a few bug fixes and improvements, and the files f_sprite.h and f_sprite.c which allow you to read and write the sprite files (*.spr). The format of the sprites was a bit more complex than I thought at first, but now I think I got most of it. The text below is taken from the file "FORMATS", as included in QEU 0.3. The detailled structure of all Quake files can be found in the corresponding header file (*.h). You should also take a look at the "README" file for more information about the QEU library. Quake data formats ================== Here is a list of the various data structures used by Quake, and a guide to the functions of the QEU library that can be used to work on these structures. PACK (magic: "PACK", extension: ".pak") --------------------------------------- This is a simple archive file, which includes other files. * Files: f_pack.h, f_pack.c * Status: Completely understood. * Reading PACK files: ReadPACKDirectory() Reads the directory of a PACK files and stores it in memory. The individual files in the archive can be read with the appropriate Read*() function, using the offset found in the directory. * Creating PACK files: WritePACKHeader() Writes the header of the PACK file and creates an empty directory in memory. AddPACKEntry() Adds a new entry to the PACK directory, after the data has been written to the file using the appropriate Save*() or Write*() function. WritePACKDirectory() Updates the PACK header and writes the directory to the file. Like the other Save*() and Write*() routines, it returns the total number of bytes taken by the whole PACK data (header + all entries + directory). * Other functions: FindPACKEntry() Returns the index in the PACK directory of the first entry matching a given name. DumpPACKDirectory() Prints the contents of the PACK directory in a human-readable form. Useful for debugging. UnPACKFile() Creates individual files from a PACK archive. WAD2 (magic: "WAD2", extension: ".wad") -------------------------------------- The WAD2 format is also an archive format, which includes several chunks. Each chunk has a type (raw data, bitmap with header, raw bitmap) and an optional compression method, although none of the chunks are compressed in the test version of Quake. * Files: f_wad2.h, f_wad2.c (+ f_bitmap.h, f_bitmap.c) * Status: Completely understood. * Reading WAD2 files: ReadWAD2Directory() Reads the directory of a WAD2 files and stores it in memory. The individual chunks in the archive can be read with the appropriate Read*() function, using the offset found in the directory. Most of the chunks are bitmaps that can be read with ReadBitmap(). Two chunks (CONBACK, CONCHARS) are raw bitmaps that can be read with ReadRawBitmap(), using the appropriate width and height. The palette (PALETTE) is stored as raw data and can be read with ReadBytes() or copied to a file with CopyBytes(). * Creating WAD2 files: WriteWAD2Header() Writes the header of the WAD2 file and creates an empty directory in memory. AddWAD2Entry() Adds a new entry to the WAD2 directory, after the data has been written to the file using the appropriate Save*() or Write*() function. WriteWAD2Directory() Updates the WAD2 header and writes the directory to the file. Like the other Save*() and Write*() routines, it returns the total number of bytes taken by the whole WAD2 data (header + all entries + directory). If the WAD2 file is included in a PACK file, this number can be given to AddPACKEntry(). * Other functions: FindWAD2Entry() Returns the index in the WAD2 directory of the first entry matching a given name. DumpWAD2Directory() Prints the contents of the WAD2 directory in a human-readable form. Useful for debugging. UnWAD2File() Creates individual files from a WAD2 archive. BSP (extension: ".bsp") ----------------------- The BSP files contain the information about the maps (level data) and the static objects that can be included in the maps. Each BSP file contains 14 unnamed chunks of data which define a level and its contents. More information about the contents of the BSP files can be found in the "Unofficial Quake Specs" by Olivier Montanuy. Obviously, the hard part is not to work on the structure of the BSP file, but on its contents. This will be done by other routines (not written yet). * Files: f_bsp.h, f_bsp.c * Status: Structure of the file completely understood, but the format of the 14 entries is still unknown to me. Some of them are easy to understand (the first entry is plain text), but the other ones are more complex. I have a rough idea of what each one does, but I haven't had the time to investigate this in detail. * Reading BSP files: ReadBSPDirectory() Reads the directory of the BSP file and stores it in memory. It seems that all BSP files in Quake contain 14 entries, but this could change in future versions of the game (the first 4 bytes of the BSP files contain a version number). This function only reads the offsets to the individual data chunks, which have to be read with an approriate Read*() function (not done yet). * Creating BSP files: (not done yet, although it's rather simple). * Other functions: DumpBSPDirectory() Prints the contents of the BSP directory in a human-readable form. Useful for debugging. UnBSPFile() Creates individual files from a BSP file. Useful for debugging. Models (magic: "IDPO", extension: ".mdl") ----------------------------------------- These 3D models define the animated objects (players, monsters and moving objects). They contain the skin texture of the object (flat picture), a set of triangles defining the object and a sequence of frames for the animation. * Status: I'm still working on that. I have understood most of it, but I didn't include the source code because there are still some bugs in it. Sprites (magic: "IDSP", extension: ".spr") ------------------------------------------ The sprite files are simplified models (flat 2D pictures). They contain multiple frames, which can contain several pictures. I understand the format of the sprites, but not the purpose of the multiple pictures. * Files: f_sprite.h, f_sprite.c (+ f_bitmap.h, f_bitmap.c) * Status: Almost completely understood. * Reading sprite files: ReadSprite() Reads all the frames for a sprite and stores them in memory. * Creating sprite files: SaveSprite() Saves a sprite to a file (all frames). * Other functions: NewSprite() Creates a new, empty sprite. FreeSprite() Discards a sprite and frees memory. AddSpriteImage() Adds an image (bitmap) to a sprite. Sounds (magic: "RIFF", extension: ".wav") ----------------------------------------- These are standard WAV files, which can be read and saved by most sound editors. I do not intend to re-invent the wheel and include a sound editor in QEU. Bitmaps ------- These are "flat" bitmaps, consisting of an array of 8-bit pixels (using a palette of 256 colors). The bitmaps are included in the WAD2 file (gfx.wad) and are part of some other structures, such as the frames for a sprite or an alias model. In all these bitmaps, the reference to the Quake palette is implicit. This is probably the simplest data structure in Quake. * Files: f_bitmap.h, f_bitmap.c * Status: Completely understood (that was simple enough!). * Reading bitmap files: ReadBitMap() Reads a bitmap, including its width and height. ReadRawBitMap() Reads a raw bitmap (without header). The width and height of the bitmap must be supplied to this function, since they are not included in the file. * Creating bitmap files: SaveBitMap() Saves a bitmap to a file, including its width and height. The number of bytes written is returned, so that it can be given to AddWAD2Entry() if the bitmap is included in a WAD2 file. SaveRawBitMap() Saves a bitmap to a file as raw data, without its width and height. * Other functions: NewBitMap() Creates a new, empty bitmap. FreeBitMap() Discards a bitmap and frees memory. DumpBitMap() Prints the contents of the bitmap in a human-readable form. Useful for debugging, although not practical for large bitmaps. SavePPM() Saves a bitmap as a PPM file (uses the Quake palette). SaveBMP() Saves a bitmap as a BMP file (uses the Quake palette). Other formats ------------- To be added later... -Raphael From quake-editing-owner@nvg.unit.no Mon Mar 4 18:07 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id SAA17336 for ; Mon, 4 Mar 1996 18:07:28 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id RAA06153 for quake-editing-outgoing; Mon, 4 Mar 1996 17:28:41 +0100 Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id RAA06147 for ; Mon, 4 Mar 1996 17:28:33 +0100 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.132.130]) by mailgate.ericsson.se (8.6.11/1.0) with ESMTP id RAA00681 for ; Mon, 4 Mar 1996 17:28:19 +0100 Received: (from eedraq@localhost) by chapelle.eed.ericsson.se (8.7.1/8.7.1) id RAA19799 for quake-editing@nvg.unit.no; Mon, 4 Mar 1996 17:28:16 +0100 (MET) Date: Mon, 4 Mar 1996 17:28:15 +0100 (MET) Message-Id: <199603041628.RAA19799@chapelle.eed.ericsson.se> To: quake-editing@nvg.unit.no Subject: Re: Quake data structures From: Raphael.Quinet@eed.ericsson.se Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1579 X-Lines: 32 Status: RO Hello again! In my previous message to this list, I forgot to mention that you can get the source code for the QEU library and sample programs at the following addresses: http://ftp.cdrom.com/pub/idgames2/newstuff/ ftp://ftp.cdrom.com/pub/idgames2/newstuff/ http://www.stud.montefiore.ulg.ac.be/ftp-mirror/quake/qeu/ ftp://ftp.stud.montefiore.ulg.ac.be/pub/quake/qeu/ And now a request: in order to keep the noise level on this list as low as possible, please do not discuss the data formats for the moment. Actually, maybe I shouldn't have posted my message about the data formats because some information is still missing. A new version of the soon-to-be-world-famous Unofficial Quake Specs will be out soon and it will be better to discuss the data structures after the (unofficial) specs are released. Otherwise, we would get a lot of questions here, that are probably already answered in the specs. So please wait... We should share useful information on this list, but unnecessary questions should be avoided, IMHO. In the meantime, we can discuss Quake editing techniques in rec.games.computer.quake.editing. Fortunately, the noise level is still rather low in that group, so it is actually usable. This is also where general map editing problems will be discussed once we have solved the technical problems on this list. And while I am at it, I should thank Bernd for setting up and maintaining this list, which will certainly become very valuable for all people who want to create a Quake editor or help the people who are building theirs. -Raphael From quake-editing-owner@nvg.unit.no Mon Mar 4 18:08 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id SAA17341 for ; Mon, 4 Mar 1996 18:08:13 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id RAA06214 for quake-editing-outgoing; Mon, 4 Mar 1996 17:30:39 +0100 Received: from pelican.lannion.cnet.fr (pelican.lannion.cnet.fr [192.44.58.25]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id RAA06207 for ; Mon, 4 Mar 1996 17:30:27 +0100 Relayed; 04 Mar 96 17:30:14+0100 X400-Received: by /PRMD=cnet/ADMD=atlas/C=fr/; Relayed; 04 Mar 96 17:30:14+0100 Date: 04 Mar 96 17:30:14+0100 From: Olivier To: quake-editing@nvg.unit.no Subject: Upcoming: Quake Unofficial Specs 3.0 Message-ID: <9603041629.124708@lat1192.lannion.cnet.fr> X-Mailer: E-Mail 1.6 Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1535 X-Lines: 41 Status: RO The Unofficial Quake Specs version 3.0 (by Raphael Quinet and me) are currently being finalised. It was distributed to a small number of people, so that comments do not generate too much bandwidth. Sorry for the inconvenience. Please be patient, there are a lot of things to check and I don't want to release a document containing mainly unverified intuitions. I also need to build a tool to check in 3D. This document covers the complete description of the level .BSP models and entity .MDL models, and maybe the .SPR files. The .MDL files are not too complicated, most of you probably hacked them out. They don't differ much from the previous version, except in the frame table. The .BSP files are rather complicated. If my specs are ok, there not one but many BSP trees, in two major flavors. That's because Quake apparently uses local BSP trees. That idea of local BSP is new, but each of the local BSP have a structure are remotely similar to the one described in the Unofficial Quake Specs 2.2, and that's why I could hack it out. yet it took me 2 days. Last: I would like to list in those specs everyone who has done a major contribution to Quake hacking, so that it be fair to everyone. Also I would like a list of all the WWW pages dedicated to Quake Hacking. PLEASE DO NOT MAIL ME HERE. ONLY ON COMPPUSERVE. With regards, -------------------------------------------------------------- Olivier Montanuy. 100625.2622@compuserve.com These are my views, not those of my company. From quake-editing-owner@nvg.unit.no Mon Mar 4 20:01 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id UAA17657 for ; Mon, 4 Mar 1996 20:01:32 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id TAA09074 for quake-editing-outgoing; Mon, 4 Mar 1996 19:23:16 +0100 Received: from tulpi.interconnect.com.au (root@tulpi.interconnect.com.au [192.189.54.18]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id TAA09065 for ; Mon, 4 Mar 1996 19:23:01 +0100 Received: from Chris ([206.153.170.6]) by tulpi.interconnect.com.au with SMTP id FAA12946 (8.6.11/IDA-1.6 for ); Tue, 5 Mar 1996 05:25:37 +1100 Message-ID: <199603041825.FAA12946@tulpi.interconnect.com.au> Comments: Authenticated sender is From: "Chris Cason" Organization: Hallam Oaks Pty. Ltd. To: quake-editing@nvg.unit.no Date: Mon, 4 Mar 1996 10:22:44 -0800 Subject: Re: Quake data structures Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1096 X-Lines: 25 Status: RO > In the meantime, we can discuss Quake editing techniques in > rec.games.computer.quake.editing. Fortunately, the noise level is > still rather low in that group, so it is actually usable. This is > also where general map editing problems will be discussed once we have > solved the technical problems on this list. And while I am at it, I > should thank Bernd for setting up and maintaining this list, which > will certainly become very valuable for all people who want to create > a Quake editor or help the people who are building theirs. I was under the impression this time that id would be releasing some specs for the data structures. Can anyone confirm/deny this ? We (SciTech) have been working with id a little on a technical level (regarding video) but haven't really had a opportunity to raise this (and probably won't, either, since they're flat out.) regards, -- Chris Cason SciTech Software POV-Team PS If we need a FTP/Web site, I can set up either a public or private area on my web/ftp server, www.povray.org/ftp.povray.org. It's on a T1 so connectivity is good. From quake-editing-owner@nvg.unit.no Mon Mar 4 21:56 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id VAA18004 for ; Mon, 4 Mar 1996 21:56:17 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id UAA11326 for quake-editing-outgoing; Mon, 4 Mar 1996 20:59:46 +0100 Received: from minerva.phyast.pitt.edu (minerva.phyast.pitt.edu [136.142.111.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id UAA11299 for ; Mon, 4 Mar 1996 20:56:47 +0100 Received: (brian@localhost) by minerva.phyast.pitt.edu (8.6.10/8.6.5) id OAA07337 for quake-editing@nvg.unit.no; Mon, 4 Mar 1996 14:56:26 -0500 From: "Brian K. Martin" Message-Id: <199603041956.OAA07337@minerva.phyast.pitt.edu> Subject: Re: Quake data structures To: quake-editing@nvg.unit.no Date: Mon, 4 Mar 1996 14:56:23 -0500 (EST) In-Reply-To: <199603041628.RAA19799@chapelle.eed.ericsson.se> from "Raphael.Quinet@eed.ericsson.se" at Mar 4, 96 05:28:15 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 21 Status: RO Content-Type: text/plain; charset="US-ASCII" Content-Length: 932 > > > And now a request: in order to keep the noise level on this list as > low as possible, please do not discuss the data formats for the > moment. Actually, maybe I shouldn't have posted my message about the > data formats because some information is still missing. A new version > of the soon-to-be-world-famous Unofficial Quake Specs will be out soon > and it will be better to discuss the data structures after the > (unofficial) specs are released. Otherwise, we would get a lot of > questions here, that are probably already answered in the specs. So > please wait... We should share useful information on this list, but > unnecessary questions should be avoided, IMHO. > Sorry, but I was under the impression that this list was formed to discuss file formats and to help get editors made. If there are some uncertainties in the quake specs, why not ask this list for help? brian From quake-editing-owner@nvg.unit.no Tue Mar 5 03:45 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id DAA18509 for ; Tue, 5 Mar 1996 03:45:29 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id DAA19810 for quake-editing-outgoing; Tue, 5 Mar 1996 03:07:18 +0100 Received: from ftoomsh.progsoc.uts.EDU.AU (chris@ftoomsh.progsoc.uts.EDU.AU [138.25.6.1]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id DAA19799 for ; Tue, 5 Mar 1996 03:06:59 +0100 Received: (from chris@localhost) by ftoomsh.progsoc.uts.EDU.AU (8.7.2/8.7.2) id MAA17688 for quake-editing@nvg.unit.no; Tue, 5 Mar 1996 12:06:50 +1000 (EST) From: Christopher Michael Holland Message-Id: <199603050206.MAA17688@ftoomsh.progsoc.uts.EDU.AU> Subject: Textures. To: quake-editing@nvg.unit.no Date: Tue, 5 Mar 1996 12:06:49 +1000 (EST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 15 Status: RO Content-Type: text/plain; charset="US-ASCII" Content-Length: 489 I have noticed that the textures seem to have 3 states, depending on how far you are from the texture. At a certain distance the texture is anti-aliased, which reduces graphical artifacts resulting from spotty textures seen from a distance. Does anyone know if the engine itself does the anti-aliasing, or if there are actually three versions of each texture in the pak? Just curious if this is known yet.... Thanks, and keep up the hacking! Chris. chris@ftoomsh.progsoc.uts.edu.au From quake-editing-owner@nvg.unit.no Tue Mar 5 10:02 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id KAA19259 for ; Tue, 5 Mar 1996 10:02:46 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id JAA28070 for quake-editing-outgoing; Tue, 5 Mar 1996 09:42:23 +0100 Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id JAA28051 for ; Tue, 5 Mar 1996 09:42:00 +0100 Received: from chapelle (chapelle.eed.ericsson.se [164.48.132.130]) by mailgate.ericsson.se (8.6.11/1.0) with ESMTP id JAA18817 for ; Tue, 5 Mar 1996 09:41:39 +0100 Received: (from eedraq@localhost) by chapelle (8.7.1/8.7.1) id JAA24477 for quake-editing@nvg.unit.no; Tue, 5 Mar 1996 09:41:31 +0100 (MET) Date: Tue, 5 Mar 1996 09:41:28 +0100 (MET) Message-Id: <199603050841.JAA24477@chapelle> To: quake-editing@nvg.unit.no Subject: Various things... From: Raphael.Quinet@eed.ericsson.se Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 3824 X-Lines: 76 Status: RO OK, I think I have to clarify a few things, and I will try to reply to all questions in this message... Please bear with me, this message is going to be a bit long. Chris Cason wrote: > I was under the impression this time that id would be releasing some specs for > the data structures. Can anyone confirm/deny this ? We (SciTech) have been > working with id a little on a technical level (regarding video) but haven't > really had a opportunity to raise this (and probably won't, either, since > they're flat out.) Apparently, even the guys at id Software don't know if they will release their specs or not. :-) Dave Taylor wrote that they would probably release some information, but he wasn't sure. Anyway, it doesn't really matter, because most of the internal structures are known by now. I'm sure that the Unofficial Quake Specs will be as good as any official document distributed by id. Also (warning: personal ramblings ahaead), I'm afraid that id Software could try to do the same thing as they (unsuccessfully) did for Doom: releasing a simple editor, BSP compiler or QuakeC compiler, but with a license that forbids certain things and prevents people from distributing their levels as they wish. Those who were around when John Romero released the source code for IDBSP at the same time as Jay Wilbur sent the Data Utility License to all authors of Doom editors probably know what I am talking about. I think they did that in good faith and were simply trying to protect themselves, but the legal restrictions for the Doom editors were a bit too strong, IMHO. The information in the unofficial specs will be free for everyone. Brian K. Martin wrote: > Sorry, but I was under the impression that this list was formed > to discuss file formats and to help get editors made. If there are > some uncertainties in the quake specs, why not ask this list for > help? Most of the uncertainties are not in the data formats, but in the text that explains them. I understand Olivier who doesn't want to release the specs with poor explanations, because this list would quickly be flooded with questions. You are right about the purpose of this list, and all the information that was gathered in the unofficial specs will soon be released so that we can all benefit from it and concentrate on writing our editors or understanding the last unknown bits in the structures. But the document is not ready yet and the bits and pieces have to be put together in order to have a coherent structure. A document which contains all the information but not the explanations that go along with the data formats is likely to generate a lot of noise. Please be patient, the specs will be released sooner than you think (well, I hope so). Christopher Michael Holland wrote: > Does anyone know if the engine itself does the anti-aliasing, or if there > are actually three versions of each texture in the pak? This technique is called mip-mapping and was described in a paper by Michael Abrash. Now, don't you wonder why he was hired by id Software? The images of each tecture at various scaling factors are stored in the BSP files (which are in turn included in the PAK files), and the anti-aliasing was pre-computed by a separate program. And now a personal disclaimer... I wrote: > [...] A new version > of the soon-to-be-world-famous Unofficial Quake Specs will be out soon > [...] ... and Olivier wrote: > > The Unofficial Quake Specs version 3.0 (by Raphael Quinet and me) > are currently being finalised. [...] Despite what Olivier wrote, he did 99% of the job and I only helped him for some details. The comment about the "soon-to-be-world-famous" specs applies Olivier's work. :-) -Raphael From quake-editing-owner@nvg.unit.no Mon Mar 4 19:43 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id TAA17572 for ; Mon, 4 Mar 1996 19:43:34 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id TAA08668 for quake-editing-outgoing; Mon, 4 Mar 1996 19:05:21 +0100 Received: from rendsburg.netsurf.de (root@rendsburg.netsurf.de [194.64.167.161]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id TAA08660 for ; Mon, 4 Mar 1996 19:05:05 +0100 Received: from ppp1.rendsburg.netsurf.de (panza@ppp1.rendsburg.netsurf.de [194.64.167.162]) by rendsburg.netsurf.de (8.6.9/8.6.9) with SMTP id TAA15046 for ; Mon, 4 Mar 1996 19:04:59 +0100 Date: Mon, 4 Mar 1996 19:04:59 +0100 Message-Id: <199603041804.TAA15046@rendsburg.netsurf.de> X-Sender: d.moeller@rendsburg.netsurf.de X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 To: quake-editing@nvg.unit.no From: Denis Subject: Re: Quake data structures Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 28 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 1054 Hi! Well, quake-hacking is coming along very quickly, everyone wants to program editors and stuff. I like the idea from Raphael to make a library with the basic functions to work with all sort of Quake-files. Like many people out there, I started hacking right from the beginning and released the first version of quip - a NWT like tool for Quake. The ZIP contains my personal specs, all I found out while working on quip - I guess it might be obsolete, but check it out if you like... It would be quite interesting to know, what we will need for Quake at the end - id 'said' that they will release their map-editor, for Win95 and Linux - so, there's actually no need for others. Are they going to release File-Tools and stuff too? Well, whatever happens, I'll go on with quip - hope to see many creative and helpful people here... :-) P.S. quip v0.1 is on cdrom.com, quip01.zip cya Denis --- Denis Moeller, author of NWT v1.3 and TiC's WAD Reviews. e-mail: d.moeller@rendsburg.netsurf.de, #irc: panza http://www.geocities.com/Hollywood/2299/ From quake-editing-owner@nvg.unit.no Tue Mar 5 12:13 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id MAA20328 for ; Tue, 5 Mar 1996 12:13:29 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id LAA30834 for quake-editing-outgoing; Tue, 5 Mar 1996 11:35:17 +0100 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id LAA30827 for ; Tue, 5 Mar 1996 11:35:03 +0100 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id LAA19955 for ; Tue, 5 Mar 1996 11:35:03 +0100 (MET) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id LAA29419 for quake-editing@nvg.unit.no; Tue, 5 Mar 1996 11:34:57 +0100 (MET) From: Bernd Kreimeier Date: Tue, 5 Mar 1996 11:34:57 +0100 (MET) Message-Id: <199603051034.LAA29419@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: ADMIN: Various things... X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1082 X-Lines: 37 Status: RO Announcement: there's an experimental version of the Quake Developers Hypermail Archive available at http://www.nero.uni-bonn.de/~dn/qd/archive/ It will be updated on a daily or weekly basis, depending on bandwidth (daily for now, due to digest problems). Secondly: I borrowed a copy of the UQS 2.2 (the outdated specs) from Reid Ellis' SGI page which is available at the Quake Developers support pages at http://www.nero.uni-bonn.de/~dn/q-sup/ Finally: yes, this list is for discussions. It might be a good idea to wait for the UQS 3.0, to make sure we have some common ground to start with, though. Nonetheless: Feel free to post any info. I created another plain style web page (anybody remember the UDS Errata) as a reference, again on said support pages. If you've got exhaustive info (i.e. large ASCII dumps), please send them to me and post an announcement on the list, I'll put them on the Addendum page ASAP. b. From quake-editing-owner@nvg.unit.no Tue Mar 5 13:53 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id NAA20854 for ; Tue, 5 Mar 1996 13:53:15 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id NAA01467 for quake-editing-outgoing; Tue, 5 Mar 1996 13:40:18 +0100 Received: from netcom17.netcom.com (mrs@netcom17.netcom.com [192.100.81.130]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id NAA01456 for ; Tue, 5 Mar 1996 13:40:05 +0100 Received: by netcom17.netcom.com (8.6.13/Netcom) id EAA22948; Tue, 5 Mar 1996 04:39:59 -0800 Message-Id: <199603051239.EAA22948@netcom17.netcom.com> From: mrs@netcom.com (Morgan Schweers) Date: Tue, 5 Mar 1996 04:39:58 PST In-Reply-To: Raphael.Quinet@eed.ericsson.se "Quake data structures" (Mar 4, 10:55am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: quake-editing@nvg.unit.no Subject: Re: Quake data structures Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 2340 X-Lines: 48 Status: RO Greetings, I understand that you're trying to keep discussion of the structures to a minimum, but... On Mar 4, 10:55am, Raphael.Quinet@eed.ericsson.se wrote: } Subject: Quake data structures } Models (magic: "IDPO", extension: ".mdl") } ----------------------------------------- } } These 3D models define the animated objects (players, monsters and moving } objects). They contain the skin texture of the object (flat picture), a } set of triangles defining the object and a sequence of frames for the } animation. } } * Status: I'm still working on that. I have understood most of it, but I } didn't include the source code because there are still some bugs } in it. I'd like to be CC'ed on this even if it's not finalized, as I'm currently working on multiple 3D formats for other platforms and have a *VERY* strong (and yet simple) conversion library which allows near-instantaneous development of mesh conversion programs. Both myself and my project lead at work are VERY interested in taking a day off and building a proper set of mesh conversion programs into and out of the Quake MDL format. The (unfortunately EXTREMELY skimpy) documentation I've read so far is interesting, as it evidently suggests that normals aren't stored with the model. The texture coordinates sound straightforward enough though. Anyhow, any information leading to the arrest and capture of vertex, face, and UV information will be rewarded hopefully with a conversion program in short order... *grin* -- Morgan Schweers p.s. I think the speed at which the poor ID1.PAK file (and its contents) got stripped, reverse engineered, and reconstructed must set a new world record someplace. It wasn't even an hour after it was released that monsters were enabled. You *KNOW* id Software left the monsters in on purpose so that people would add them in on their own accord... p.p.s. February 8, 1997, 8:30pm, id Software releases 'Hello World', their new non-interactive text display emulation display system test program. February 8, 1997, 9:30pm, the associated 5 Meg .ARK file is reverse engineered and the first hack (making it print, 'Hello Internet' instead of its usual output) is completed. From quake-editing-owner@nvg.unit.no Tue Mar 5 17:26 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id RAA23994 for ; Tue, 5 Mar 1996 17:26:53 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id QAA06691 for quake-editing-outgoing; Tue, 5 Mar 1996 16:46:51 +0100 Received: from minerva.phyast.pitt.edu (minerva.phyast.pitt.edu [136.142.111.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id QAA06502 for ; Tue, 5 Mar 1996 16:41:12 +0100 Received: (brian@localhost) by minerva.phyast.pitt.edu (8.6.10/8.6.5) id KAA10681 for quake-editing@nvg.unit.no; Tue, 5 Mar 1996 10:41:06 -0500 From: "Brian K. Martin" Message-Id: <199603051541.KAA10681@minerva.phyast.pitt.edu> Subject: mdl file formats To: quake-editing@nvg.unit.no (quake) Date: Tue, 5 Mar 1996 10:41:05 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 147 Status: RO Content-Type: text/plain; charset="US-ASCII" Content-Length: 3414 Hello, I have gotten tons of mail on the mdl format. So, against some suggestions, I'm posting some stuff to help yunz out. Note some info differs from the beta quake specs 3.0. enjoy. --------------------------------------------------------- MDL file format (this is what I know so far) These are the structs I use to read in file info: // frame full of verticies struct vframe{ unsigned char head[12]; unsigned char *v; }; // file storage structure struct MDL_FILE{ char filetype[4]; int version; float xscale,yscale,zscale; float xoffset,yoffset,zoffset; float radius; float f1,f2,f3; unsigned num_items; unsigned bitmapw; unsigned bitmaph; unsigned num_vertices; unsigned num_triangles; unsigned num_frames; unsigned blank; unsigned char *bitmap; unsigned int *vertex; unsigned int *triangle; struct vframe *frame; }; // how to read mdl file void read_mdl(FILE *in) { int i,j,k; fread(&mdl.filetype,4,1,in); fread(&mdl.version,4,1,in); fread(&mdl.xscale,4,1,in); fread(&mdl.yscale,4,1,in); fread(&mdl.zscale,4,1,in); fread(&mdl.xoffset,4,1,in); fread(&mdl.yoffset,4,1,in); fread(&mdl.zoffset,4,1,in); fread(&mdl.radius,4,1,in); fread(&mdl.f1,4,1,in); fread(&mdl.f2,4,1,in); fread(&mdl.f3,4,1,in); fread(&mdl.num_items,4,1,in); fread(&mdl.bitmapw,4,1,in); fread(&mdl.bitmaph,4,1,in); fread(&mdl.num_vertices,4,1,in); fread(&mdl.num_triangles,4,1,in); fread(&mdl.num_frames,1,4,in); fread(&mdl.blank,1,4,in); mdl.bitmap = new (unsigned char)[mdl.bitmapw*mdl.bitmaph*mdl.num_items]; for(k=0;k; Tue, 5 Mar 1996 20:00:23 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id TAA10808 for quake-editing-outgoing; Tue, 5 Mar 1996 19:21:55 +0100 Received: from df.lth.se (root@oberon.df.lth.se [194.47.252.39]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id TAA10712 for ; Tue, 5 Mar 1996 19:18:38 +0100 Received: from magnus by df.lth.se with smtp (Smail3.1.28.1 #4) id m0tu2Fo-0002fyC; Tue, 5 Mar 96 20:18 MET Message-ID: <313C8529.A09@df.lth.se> Date: Tue, 05 Mar 1996 19:17:13 +0100 From: Magnus Landqvist X-Mailer: Mozilla 2.0GoldB1 (Win95; I) MIME-Version: 1.0 To: quake-editing@nvg.unit.no Subject: Re: mdl file formats References: <199603051541.KAA10681@minerva.phyast.pitt.edu> Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 18 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 556 Brian K. Martin wrote: > > Hello, I have gotten tons of mail on the mdl format. So, > against some suggestions, I'm posting some stuff to help yunz > out. Note some info differs from the beta quake specs 3.0. > Just a small warning: When Dave Taylor was asked why they didn't want to release any specifications whatsoever on their .mdl and .bsp-formats he answered that it was because the formats changed constantly. Already they were different from the test1 release. So make your editors and utils easy to change when test2 is released. /Magnus From quake-editing-owner@nvg.unit.no Tue Mar 5 20:06 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id UAA24872 for ; Tue, 5 Mar 1996 20:06:13 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id TAA10952 for quake-editing-outgoing; Tue, 5 Mar 1996 19:28:15 +0100 Received: from portal.atak (root@lpsg.demon.co.uk [158.152.141.232]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id TAA10937 for ; Tue, 5 Mar 1996 19:27:48 +0100 Received: (from tom@localhost) by portal.atak (8.6.12/8.6.12) id VAA00301; Mon, 4 Mar 1996 21:13:12 GMT Date: Mon, 4 Mar 1996 21:13:12 +0000 (GMT) From: Tom Lees X-Sender: tom@portal.atak To: quake-editing@nvg.unit.no Subject: Re: Quake data structures In-Reply-To: <199603041804.TAA15046@rendsburg.netsurf.de> Message-ID: MIME-Version: 1.0 Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 16 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 700 On Mon, 4 Mar 1996, Denis wrote: > It would be quite interesting to know, what we will need for Quake > at the end - id 'said' that they will release their map-editor, for > Win95 and Linux - so, there's actually no need for others. Are they > going to release File-Tools and stuff too? I would be interested to know if they are planning to release the source for their editor too: I think they also 'said' that they would release the source code for the quake server, but with the current implementation of it (part of quake itself), this does not look possible unless the quake server is re-written to be external to quake itself (as well as internal). -- Tom Lees (tom@lpsg.demon.co.uk) From quake-editing-owner@nvg.unit.no Tue Mar 5 21:32 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id VAA25144 for ; Tue, 5 Mar 1996 21:32:56 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id UAA12925 for quake-editing-outgoing; Tue, 5 Mar 1996 20:51:11 +0100 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id UAA12918 for ; Tue, 5 Mar 1996 20:51:01 +0100 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id UAA25015; Tue, 5 Mar 1996 20:50:49 +0100 (MET) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id UAA00605; Tue, 5 Mar 1996 20:50:43 +0100 (MET) From: Bernd Kreimeier Date: Tue, 5 Mar 1996 20:50:43 +0100 (MET) Message-Id: <199603051950.UAA00605@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: Re: DIGEST FORMAT? Cc: mpearson@pop3.pcix.com X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 729 X-Lines: 23 Status: RO ADMIN note: RTFM. You'll find out the following a) the digest does not work at the moment, and I don't know when it will be fixed (has to be done at nvg.unit.no). b) the "info" files of both the list and the digest mention this under "current news" right on top. c) the "info" files you got on subscription also mentions an URL pointing to exhaustive descriptions on how to subscribe, unsubscribe etc. If there is any misleading or missing information in the material mentioned above. contact me at owner-quake-editing@nvg.unit.no owner-quake-editing-digest@nvg.unit.no not, repeat: NOT the list. Thank you. b. From quake-editing-owner@nvg.unit.no Tue Mar 5 21:39 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id VAA25167 for ; Tue, 5 Mar 1996 21:39:56 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id UAA13078 for quake-editing-outgoing; Tue, 5 Mar 1996 20:58:57 +0100 Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id UAA13072 for ; Tue, 5 Mar 1996 20:58:48 +0100 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.132.130]) by mailgate.ericsson.se (8.6.11/1.0) with ESMTP id UAA09724 for ; Tue, 5 Mar 1996 20:58:45 +0100 Received: (from eedraq@localhost) by chapelle.eed.ericsson.se (8.7.1/8.7.1) id UAA00358 for quake-editing@nvg.unit.no; Tue, 5 Mar 1996 20:58:45 +0100 (MET) Date: Tue, 5 Mar 1996 20:58:45 +0100 (MET) Message-Id: <199603051958.UAA00358@chapelle.eed.ericsson.se> To: quake-editing@nvg.unit.no Subject: Re: mdl file formats From: Raphael.Quinet@eed.ericsson.se Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1573 X-Lines: 33 Status: RO Magnus Landqvist wrote: > Just a small warning: > When Dave Taylor was asked why they didn't want to release any > specifications whatsoever on their .mdl and .bsp-formats he > answered that it was because the formats changed constantly. > Already they were different from the test1 release. > So make your editors and utils easy to change when > test2 is released. This is the reason why I write QEU as a library of generic routines for loading and saving files. If anyone uses this library for a program, it will be easy to upgrade to any new format, because only a few things will have to be changed in the library and most of the program will still be correct. Also, I try to make my code as portable and clean as possible, so that it can be used on almost any platform for which a C compiler exists. This way, when Quake is ported to the Cray, it will be possible for Cray users to edit their levels on their favourite computer. :-) It takes twice as much time to write a clean code with lots of comments than writing a quick hack. But it pays in the end. Also, it helps other people to understand the data structures that are involved. Note that I will have to delay the release of QEU 0.4 a bit, because I'm trying to help Olivier and get his Unofficial Quake Specs ready as soon as possible, since many of you are waiting for them. By the way, I feel really frustrated: I am hacking Quake files and helping Olivier with his specs, but I cannot play Quake (or even test my code) because I don't have a PC. Life is hard! ;-) -Raphael From quake-editing-owner@nvg.unit.no Wed Mar 6 08:18 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id IAA26296 for ; Wed, 6 Mar 1996 08:18:27 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id IAA27988 for quake-editing-outgoing; Wed, 6 Mar 1996 08:10:09 +0100 Received: from minerva.phyast.pitt.edu (minerva.phyast.pitt.edu [136.142.111.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id IAA27974 for ; Wed, 6 Mar 1996 08:09:57 +0100 Received: (brian@localhost) by minerva.phyast.pitt.edu (8.6.10/8.6.5) id CAA16507 for quake-editing@nvg.unit.no; Wed, 6 Mar 1996 02:09:55 -0500 From: "Brian K. Martin" Message-Id: <199603060709.CAA16507@minerva.phyast.pitt.edu> Subject: Re: Quake data structures To: quake-editing@nvg.unit.no Date: Wed, 6 Mar 1996 02:09:55 -0500 (EST) In-Reply-To: <199603051239.EAA22948@netcom17.netcom.com> from "Morgan Schweers" at Mar 5, 96 04:39:58 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 146 Status: RO Content-Type: text/plain; charset="US-ASCII" Content-Length: 3348 I forgot if I sent these to you. Some things are wrong. The 4'th byte in the vframe.v is the index to the precalculated vertex normals. So you can convert from mdl to whatever, but not back yet because I didn't figure out the normal data structure. Later. MDL file format (this is what I know so far) These are the structs I use to read in file info: struct vframe{ unsigned char head[12]; unsigned char *v; }; struct MDL_FILE{ char filetype[4]; int version; float xscale,yscale,zscale; float xoffset,yoffset,zoffset; float radius; float f1,f2,f3; unsigned num_items; unsigned bitmapw; unsigned bitmaph; unsigned num_vertices; unsigned num_triangles; unsigned num_frames; unsigned blank; unsigned char *bitmap; unsigned int *vertex; unsigned int *triangle; struct vframe *frame; }; void read_mdl(FILE *in) { int i,j,k; fread(&mdl.filetype,4,1,in); fread(&mdl.version,4,1,in); fread(&mdl.xscale,4,1,in); fread(&mdl.yscale,4,1,in); fread(&mdl.zscale,4,1,in); fread(&mdl.xoffset,4,1,in); fread(&mdl.yoffset,4,1,in); fread(&mdl.zoffset,4,1,in); fread(&mdl.radius,4,1,in); fread(&mdl.f1,4,1,in); fread(&mdl.f2,4,1,in); fread(&mdl.f3,4,1,in); fread(&mdl.num_items,4,1,in); fread(&mdl.bitmapw,4,1,in); fread(&mdl.bitmaph,4,1,in); fread(&mdl.num_vertices,4,1,in); fread(&mdl.num_triangles,4,1,in); fread(&mdl.num_frames,1,4,in); fread(&mdl.blank,1,4,in); mdl.bitmap = new (unsigned char)[mdl.bitmapw*mdl.bitmaph*mdl.num_items]; for(k=0;k; Wed, 6 Mar 1996 12:48:04 +0100 (MET) Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with SMTP id MAA04971 for ; Wed, 6 Mar 1996 12:48:57 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id MAA01598 for quake-editing-outgoing; Wed, 6 Mar 1996 12:46:19 +0100 Received: from relay.bt.net (relay.bt.net [194.72.6.52]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id MAA01590 for ; Wed, 6 Mar 1996 12:46:07 +0100 Received: from flash.globalnews.com by relay.bt.net with SMTP (PP); Wed, 6 Mar 1996 11:45:48 +0000 Received: by flash.globalnews.com (SMI-8.6/SMI-SVR4) id LAA28928; Wed, 6 Mar 1996 11:43:22 GMT From: jschuur@flash.globalnews.com Date: Wed, 6 Mar 1996 11:43:22 +0000 (GMT) To: quake-editing@nvg.unit.no Subject: Re: Quake data structures In-Reply-To: Message-ID: MIME-Version: 1.0 Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 17 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 743 On Mon, 4 Mar 1996, Tom Lees wrote: > > It would be quite interesting to know, what we will need for Quake > > at the end - id 'said' that they will release their map-editor, for > > Win95 and Linux - so, there's actually no need for others. Are they > > going to release File-Tools and stuff too? > > I would be interested to know if they are planning to release the source > for their editor too: I think they also 'said' that they would release i seem to recall dave taylor or someone else from id saying they wouldn't release their editor after all since they didn't want to get tech support mails for it. they might change their opinion again, but things don't seem to be as certain as they were (or were they ever? ;) From quake-editing-owner@nvg.unit.no Wed Mar 6 14:34 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 OAA00244 for ; Wed, 6 Mar 1996 14:34:19 +0100 (MET) Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with SMTP id OAA05908 for ; Wed, 6 Mar 1996 14:35:12 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id OAA03609 for quake-editing-outgoing; Wed, 6 Mar 1996 14:06:37 +0100 Received: from melb.werple.net.au (melb.werple.net.au [203.9.190.18]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id OAA03595 for ; Wed, 6 Mar 1996 14:06:19 +0100 Received: from werple.mira.net.au (dp-m-a10.werple.net.au [203.17.40.110]) by melb.werple.net.au (8.7.4/8.7.3) with SMTP id AAA16198 for ; Thu, 7 Mar 1996 00:06:07 +1100 (EST) Message-Id: <199603061306.AAA16198@melb.werple.net.au> X-Sender: antony@werple.mira.net.au X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Date: Thu, 07 Mar 1996 00:01:44 +1000 To: quake-editing@nvg.unit.no From: Antony Suter Subject: Re: Textures. Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 15 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 699 At 12:06 PM 5/3/1996 +1000, you wrote: >I have noticed that the textures seem to have 3 states, depending on how >far you are from the texture. At a certain distance the texture is >anti-aliased, which reduces graphical artifacts resulting from spotty >textures seen from a distance. > >Does anyone know if the engine itself does the anti-aliasing, or if there >are actually three versions of each texture in the pak? I would say that you are looking at the MIP maps. Are they like this:- First full size, next is a quarter the area, last is 1/16th the area? -- - Antony Suter (Rohan, of Middle Earth) - "Pick a signature, any signature. As long as it's this one". From quake-editing-owner@nvg.unit.no Wed Mar 6 14:35 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 OAA00253 for ; Wed, 6 Mar 1996 14:35:06 +0100 (MET) Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with SMTP id OAA05922 for ; Wed, 6 Mar 1996 14:35:58 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id OAA03610 for quake-editing-outgoing; Wed, 6 Mar 1996 14:06:39 +0100 Received: from melb.werple.net.au (melb.werple.net.au [203.9.190.18]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id OAA03596 for ; Wed, 6 Mar 1996 14:06:20 +0100 Received: from werple.mira.net.au (dp-m-a10.werple.net.au [203.17.40.110]) by melb.werple.net.au (8.7.4/8.7.3) with SMTP id AAA16200 for ; Thu, 7 Mar 1996 00:06:08 +1100 (EST) Message-Id: <199603061306.AAA16200@melb.werple.net.au> X-Sender: antony@werple.mira.net.au X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Date: Thu, 07 Mar 1996 00:01:45 +1000 To: quake-editing@nvg.unit.no From: Antony Suter Subject: Quake BSP info from Carmack Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 35 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 1538 The all algorithmical Carmack has been kind enough to grace me with some correspondance. The points are below. note: as Magnus and Raphael have pointed out, expect the Quake file formats to change! - not going to release BSP code till game is final. - changes are still happening. - will need optimization to run well on most machines:- - they run it on a 4 CPU alpha box with 128 MB RAM. (my other car is a Mercedes!) - The full map processing is actually three seperate programs: qbsp: which builds minimized drawing and clipping hulls from a solid geometry description of the world. This is the memory pig that can chew up 50+ resident megs on big levels. Single threaded, but most levels only take a minute or so to run. light: builds the surface lighting maps. Fully parallelel, generally taking a few minutes to make a high quality run, or less for a non-filtered version. vis: builds the potentially visible set. Fully parallel. This is the CPU pig. It is wildly content dependant (combinatorially sensitve), so some levels may only take a minute or so, but there is one level we have that takes nearly an hour even on 4 cpus. During development, subsets of the suite are run, and only for full testing is the vis program run. And to go with your lemon scented paper napkins, he said:- "I suspect a lot of university computers are going to find new tasks at night :-)" -- - Antony Suter (Rohan, of Middle Earth) - "Pick a signature, any signature. As long as it's this one". From quake-editing-owner@nvg.unit.no Wed Mar 6 17:41 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id RAA02189 for ; Wed, 6 Mar 1996 17:41:57 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id RAA09176 for quake-editing-outgoing; Wed, 6 Mar 1996 17:38:28 +0100 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id RAA09168 for ; Wed, 6 Mar 1996 17:38:18 +0100 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id NAA29838 for ; Wed, 6 Mar 1996 13:55:45 +0100 (MET) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id NAA02181 for quake-editing@nvg.unit.no; Wed, 6 Mar 1996 13:55:32 +0100 (MET) From: Bernd Kreimeier Date: Wed, 6 Mar 1996 13:55:32 +0100 (MET) Message-Id: <199603061255.NAA02181@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: Re: reference library design/mdl file formats X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1822 X-Lines: 40 Status: RO >> warning on still changing file formats > This is the reason why I write QEU as a library of generic routines > for loading and saving files. If anyone uses this library for a > program, it will be easy to upgrade to any new format, because only a > few things will have to be changed in the library and most of the There are two important aspects to remember in designing a portable reference library for QUE and other tools: a) keep in mind the interactive editing specific needs for Constructive Solid Geometry-compliant data structures. This too will be worth the additional work in the end. I recommend looking at the references given on the "recommended readings" page (see below): the books by Martti Mantyla and Ian Ashdown, in particular, featuring half edge representations. b) keep in mind the specific needs involved with near-realtime rendering. We might or might not succeed in writing some (even non-texturing) 3D preview this time, but you definitely won't be able to integrate any such beast with a modeller/editor as long as your data structures are focused on being dynamically only (adding/removing vertices etc.), without taking efficiency into account. Two additional remarks: for radiosity-style calculation of lighting/shadow maps, I definitely recommend taking a close look at the HELIOS sources that are now publically available, written by Ian Ashdown. As for slow but doable 3D preview, I recommend looking at the Mesa library. Both referenced on the "overview of resources" page, which, like "recommended readings", is cross-referenced now at http://www.nero.uni-bonn.de/~dn/q-sup/ the Quake Developers Support pages. b. From quake-editing-owner@nvg.unit.no Wed Mar 6 17:42 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id RAA02201 for ; Wed, 6 Mar 1996 17:42:40 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id RAA09194 for quake-editing-outgoing; Wed, 6 Mar 1996 17:38:50 +0100 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id RAA09178 for ; Wed, 6 Mar 1996 17:38:35 +0100 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id NAA29796; Wed, 6 Mar 1996 13:39:24 +0100 (MET) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id NAA02143; Wed, 6 Mar 1996 13:39:17 +0100 (MET) From: Bernd Kreimeier Date: Wed, 6 Mar 1996 13:39:17 +0100 (MET) Message-Id: <199603061239.NAA02143@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: Re: release of id tools/was: Quake data structures X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1903 X-Lines: 45 Status: RO > On Mon, 4 Mar 1996, Tom Lees wrote: > > > > id 'said' that they will release their map-editor, for > > I would be interested to know if they are planning to release the source > > for their editor too: I think they also 'said' that they would release > From: jschuur@flash.globalnews.com > > i seem to recall dave taylor or someone else from id saying they > wouldn't release their editor after all since they didn't want to get > tech support mails for it. they might change their opinion again, but > things don't seem to be as certain as they were (or were they ever? ;) That about sums it up :-). Let me try to end this discussion: id will do as they choose. They might or might not promise, write, release "Official Specs", they might or might not release editor sources, they might put them under one License or another, might even sell them to other companies, might put them under NDA. If you want to know for sure, ask id or wait. Period. I remember very well the same questions on "Official DOOM Specs". There is no reliable flow of information, and no consistent support, and we cannot not depend on either. Just as id cannot depend on us. If you are going to write an editor or utility, that is *your* choice. You are not working for id. Do not expect any favors, nor offer them. Do what you want to do, for your own reasons. Protect your property or don't, and let id protect theirs. Take your own risks, waste your own time. You could either do business or have fun, but not both. You want a deal? Sign a contract. This discussion is idle speculation, and will *not* make a difference. b. ------------------------------------------------------------------------- "Being paranoid does not mean They aren't out to get you." ------------------------------------------------------------------------- From quake-editing-owner@nvg.unit.no Wed Mar 6 18:18 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id SAA02327 for ; Wed, 6 Mar 1996 18:18:51 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id SAA10321 for quake-editing-outgoing; Wed, 6 Mar 1996 18:17:18 +0100 Received: from relay-2.mail.demon.net (disperse.demon.co.uk [158.152.1.77]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id SAA10315 for ; Wed, 6 Mar 1996 18:17:07 +0100 Received: from post.demon.co.uk ([158.152.1.72]) by relay-2.mail.demon.net id ad07374; 6 Mar 96 16:55 GMT Received: from tsys.demon.co.uk ([158.152.159.87]) by relay-3.mail.demon.net id aa17850; 6 Mar 96 16:50 GMT Date: Wed, 06 Mar 96 01:02:37 GMT Message-ID: <10985@tsys.demon.co.uk> From: Tom Wheeley Organization: City Zen FM To: quake-editing@nvg.unit.no Subject: Quake data structures X-Mailer: Demon Internet Simple News v1.30 Lines: 25 X-Sig-By: Tomsystems Quote v1.2. (c)1996 Tom Wheeley, tomw@tsys.demon.co.uk Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1405 X-Lines: 29 Status: RO In article you write: > On Mon, 4 Mar 1996, Denis wrote: > > > It would be quite interesting to know, what we will need for Quake > > at the end - id 'said' that they will release their map-editor, for > > Win95 and Linux - so, there's actually no need for others. Are they > > going to release File-Tools and stuff too? > > I would be interested to know if they are planning to release the source > for their editor too: I think they also 'said' that they would release > the source code for the quake server, but with the current implementation > of it (part of quake itself), this does not look possible unless the > quake server is re-written to be external to quake itself (as well as > internal). Are id still thinking of releasing Quake as .o files as mentioned by in comp..djgpp in quaketalk? I think the idea was that you would thyen get 'server.c' (gross simplification, I'm sure) and manufacturers could then easily write their own 'device drivers', and then release them to be linked in when Quake is played. Even if id do release an editor, it will be a while before they do, and it may even be limited (even if not intentially). -- * TQ 1.0 * The 'Just So Quotes'. "They're filming Rocky V now. This one's being billed as `Rocky's Greatest Challenge', so I guess there's an IQ test involved." -- Jay Leno From quake-editing-owner@nvg.unit.no Wed Mar 6 19:36 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id TAA02803 for ; Wed, 6 Mar 1996 19:36:57 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id TAA12059 for quake-editing-outgoing; Wed, 6 Mar 1996 19:08:19 +0100 Received: from minerva.phyast.pitt.edu (minerva.phyast.pitt.edu [136.142.111.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id TAA12049 for ; Wed, 6 Mar 1996 19:08:10 +0100 Received: (brian@localhost) by minerva.phyast.pitt.edu (8.6.10/8.6.5) id NAA20680 for quake-editing@nvg.unit.no; Wed, 6 Mar 1996 13:08:07 -0500 From: "Brian K. Martin" Message-Id: <199603061808.NAA20680@minerva.phyast.pitt.edu> Subject: Re: reference library design/mdl file formats To: quake-editing@nvg.unit.no Date: Wed, 6 Mar 1996 13:08:07 -0500 (EST) In-Reply-To: <199603061255.NAA02181@colossus.nero.uni-bonn.de> from "Bernd Kreimeier" at Mar 6, 96 01:55:32 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 18 Status: RO Content-Type: text/plain; charset="US-ASCII" Content-Length: 612 > > > Two additional remarks: for radiosity-style calculation of lighting/shadow > maps, I definitely recommend taking a close look at the HELIOS sources that > are now publically available, written by Ian Ashdown. As for slow but > doable 3D preview, I recommend looking at the Mesa library. Both referenced > on the "overview of resources" page, which, like "recommended readings", is > cross-referenced now at > If anyone want's to learn 3d texture mapping techinques, I strongly recommend 3DGPL.ZIP at x2ftp.oulu.fi You will learn enough there to make a portable and solid 3d rendering engine. brian From quake-editing-owner@nvg.unit.no Thu Mar 7 11:11 MET 1996 From: Bernd Kreimeier Date: Thu, 7 Mar 1996 11:00:39 +0100 (MET) To: quake-editing@nvg.unit.no Subject: ADMIN: digest operational X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 548 X-Lines: 14 Status: RO It looks like the digest has been fixed, and even the volumes do have the right number now :-). Please feel free to change your subscription if you prefer the digest mode. Those who have missed earlier postings might want to look at the Hypermail archive at http://www.nero.uni-bonn.de/~dn/q-sup/, the page that hosts the Quake Developers support pages. My apologies for any inconvenience. b. From quake-editing-owner@nvg.unit.no Thu Mar 7 14:41 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id OAA07352 for ; Thu, 7 Mar 1996 14:41:32 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id OAA22303 for quake-editing-outgoing; Thu, 7 Mar 1996 14:39:02 +0100 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id OAA22289 for ; Thu, 7 Mar 1996 14:38:58 +0100 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id OAA07307 for ; Thu, 7 Mar 1996 14:38:56 +0100 (MET) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id OAA04687 for quake-editing@nvg.unit.no; Thu, 7 Mar 1996 14:38:47 +0100 (MET) From: Bernd Kreimeier Date: Thu, 7 Mar 1996 14:38:47 +0100 (MET) Message-Id: <199603071338.OAA04687@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: Re: reference library design/mdl file formats X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 861 X-Lines: 23 Status: RO >From: "Brian K. Martin" >If anyone want's to learn 3d texture mapping techinques, I strongly >recommend 3DGPL.ZIP at x2ftp.oulu.fi >You will learn enough there to make a portable and solid 3d rendering >engine. I second that. It includes tutorials and source. The "x2ftp" site is a very good repository anyway, as well as the 3D engines page at http://www.cs.tu-berlin.de/~ki/engines.html Also, do not underestimate Mesa. A decent library with a fast separate data path e.g. for span blitting is a good ground to stand on. See the wadtoiv home page on how DOOM levels might look once they are converted for Quake :-). For now, it is just OpenInventor. b. From quake-editing-owner@nvg.unit.no Thu Mar 7 17:14 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id RAA08771 for ; Thu, 7 Mar 1996 17:14:25 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id RAA26631 for quake-editing-outgoing; Thu, 7 Mar 1996 17:12:33 +0100 Received: from pelican.lannion.cnet.fr (pelican.lannion.cnet.fr [192.44.58.25]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id RAA26625 for ; Thu, 7 Mar 1996 17:12:27 +0100 Relayed; 07 Mar 96 17:12:17+0100 X400-Received: by /PRMD=cnet/ADMD=atlas/C=fr/; Relayed; 07 Mar 96 17:12:17+0100 Date: 07 Mar 96 17:12:17+0100 From: Olivier To: quake-editing@nvg.unit.no Subject: Question Message-ID: <9603071611.185760@lat1192.lannion.cnet.fr> X-Mailer: E-Mail 1.6 Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 482 X-Lines: 14 Status: RO Hello Bernd, Well, the stuff is finished, Ralph has it. Whatever he intends to do with it. Now, a Question: any idea whereI could get a decent free/shareware modeler? I used POV and MORAY, but maybe you know of something better? for windoze? I need to display everything in 3D, to check, and don't want to add my own 3D bugs to the stuff already there. Well, if there isn't anything suitable I'll have to hack in my own stuff. whatever. Will take me days... Olivier From quake-editing-owner@nvg.unit.no Thu Mar 7 17:55 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id RAA09529 for ; Thu, 7 Mar 1996 17:55:33 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id RAA27811 for quake-editing-outgoing; Thu, 7 Mar 1996 17:46:06 +0100 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id RAA27804 for ; Thu, 7 Mar 1996 17:46:01 +0100 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id RAA09370 for ; Thu, 7 Mar 1996 17:46:01 +0100 (MET) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id RAA05073 for quake-editing@nvg.unit.no; Thu, 7 Mar 1996 17:45:46 +0100 (MET) From: Bernd Kreimeier Date: Thu, 7 Mar 1996 17:45:46 +0100 (MET) Message-Id: <199603071645.RAA05073@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: Re: Question X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 2299 X-Lines: 53 Status: RO > Now, a Question: any idea where I could get a decent free/shareware modeler? > I used POV and MORAY, but maybe you know of something better? for windoze? I know that there's Midnight modeler for linux, but nothing else. Chris? > I need to display everything in 3D, to check, and don't want to add my own > 3D bugs to the stuff already there. Well, if there isn't anything suitable > I'll have to hack in my own stuff. whatever. Will take me days... Considering conversion issues, I think it will be worse. Of course, this will be a problem for all of us planning on tools for 3D. I see not too many alternatives. My suggestion for now: - use Mesa (OpenGL API) to display. This will work on all UNIX, and is supposed to work with Windows, too (haven't tried). It will render slow texture mapping, but will be written fast and portable. And it works really fast on my linux box. Depending on your experience with OpenGL, you will get preliminary results within hours - but the rendering will be slow. In the long run, especially with complicated (and still changing data structures) I'd suggest the following: - get VRweb, the source of the VRML browser based on Mesa, written by the Hyper-G team. Out of the box, it is for UNIX, dunno if there is a windows version already. - get the qvlib parser and I/O libraries at the VRML software repository, and do conversion from your own PAK/BSP/WAD utilities to VRML, using those C++ libraries. This seems a very good idea in the long run anyway. Will guarantee lots of publicity, too. Anybody to suggest a decent solution that will work tomorrow? b. P.S.: VRweb, the VRML repository, and Mesa referenced on the "overview of resources", on the QuakeDev support pages at http://www.nero.uni-bonn.de/~dn/q-sup ----------------------------------------------------------------------------- "Between you and us, conformity of purpose will be achieved through the mutual satisfaction of requirements." ----------------------------------------------------------------------------- From quake-editing-owner@nvg.unit.no Thu Mar 7 18:10 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id SAA09728 for ; Thu, 7 Mar 1996 18:10:27 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id SAA28365 for quake-editing-outgoing; Thu, 7 Mar 1996 18:02:11 +0100 Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id RAA27980 for ; Thu, 7 Mar 1996 17:51:13 +0100 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.132.130]) by mailgate.ericsson.se (8.6.11/1.0) with ESMTP id RAA02291 for ; Thu, 7 Mar 1996 17:51:09 +0100 Received: (from eedraq@localhost) by chapelle.eed.ericsson.se (8.7.1/8.7.1) id RAA16031 for quake-editing@nvg.unit.no; Thu, 7 Mar 1996 17:51:03 +0100 (MET) Date: Thu, 7 Mar 1996 17:51:03 +0100 (MET) Message-Id: <199603071651.RAA16031@chapelle.eed.ericsson.se> To: quake-editing@nvg.unit.no Subject: Unofficial Quake Specs 3.0 released! From: Raphael.Quinet@eed.ericsson.se Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 2343 X-Lines: 63 Status: RO Greetings, fellow Quake hackers! I am pleased to announce the release of the "Unofficial Quake Specs", version 3.0. This document, written by Olivier Montanuy with the help of Brian Martin and yours truly, contains all the technical information that has been discovered so far about the test release of Quake (QTEST1). This document can be distributed freely and is intended to be a reference for all authors of Quake editors and utilities, as well as a source of information for the curious. It is the result of several days (and nights) of hacking and is certainly not complete, but it will be updated as new information is discovered. Here is the table of contents: 0. Introduction 1. The PACK files 1.1 The PACK file format 1.2 The Resources files 1.3 The Sound files 1.4 The Code lump 2. The Level Map Models 2.1 General description of levels Maps 2.2 The Contents of .BSP files 2.3 The Format of .BSP files 2.4 The Format of the level entries 2.5 Additional informations 3. The Entity Alias Models 3.1 Explanations of Alias Models 3.2 Animating Alias Models 3.3 The Alias Model .MDL file format 4. The sprite models 4.1 General description of Sprites 4.2 The Format of the .SPR files 5. New WAD file 5.1 WAD2 File format 5.2 Format of status bar pictures 5.3 Format of console lumps 5.4 Format of palettes 6. Final word The Unofficial Quake Specs are available at the following WWW sites: http://www.nero.uni-bonn.de/~dn/q-sup/spec/qspec-current.html http://www.stud.montefiore.ulg.ac.be/ftp-mirror/quake/docs/ http://ftp.cdrom.com/pub/idgames2/docs/ (in ZIP format only) Discussion of these specs should take place in the newsgroup rec.games.computer.quake.editing or on the quake-editing mailing list (please use these fora for technical discussion only - gameplay issues should be discussed in rec.games.computer.quake.misc only). Exchanges in a public forum are better than private e-mail, so that others can be informed before a new edition of the specs is released. Also, the authors don't want hundreds of messages in their mailboxes. Hmmm... someone told me to add this: DO NOT BOTHER THE AUTHORS BY E-MAIL OR THEY WILL MAKE .MDL VOODOO PUMPKINS OUT OF YOU AND WILL FILL YOU FULL OF NINE INCH NAILS. So there! :-) Enjoy! -Raphael From quake-editing-owner@nvg.unit.no Fri Mar 8 10:26 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 KAA12340 for ; Fri, 8 Mar 1996 10:25:49 +0100 (MET) Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with SMTP id KAA17371 for ; Fri, 8 Mar 1996 10:26:42 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id KAA01442 for quake-editing-outgoing; Fri, 8 Mar 1996 10:16:44 +0100 Received: from runix.runit.sintef.no (runix.runit.sintef.no [129.241.1.5]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id KAA01431 for ; Fri, 8 Mar 1996 10:16:42 +0100 Received: from kuoi.asui.uidaho.edu by runix.runit.sintef.no with SMTP (PP); Fri, 8 Mar 1996 02:09:37 +0100 Received: (from kamikaze@localhost) by kuoi.asui.uidaho.edu (8.6.12/8.6.9) id QAA13192 for quake-editing@nvg.unit.no; Thu, 7 Mar 1996 16:55:43 -0800 Date: Thu, 7 Mar 1996 16:55:43 -0800 From: Mark Hughes Message-Id: <199603080055.QAA13192@kuoi.asui.uidaho.edu> To: quake-editing@nvg.unit.no Subject: Re: Question Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 617 X-Lines: 13 Status: RO Bernd Kreimeier spake: >Anybody to suggest a decent solution that will work tomorrow? Rayshade is a great raytracer, and there's an X-based 3-D semi-interactive modeler called "raypaint" based on it (rayshade is as much a software library for raytracing as it is a standalone program). I highly recommend it. While it's not a 3-D motion engine, it works well for producing snapshots of a scene. Rayshade Netshade - the latest version of Rayshade. -Mark Hughes From quake-editing-owner@nvg.unit.no Fri Mar 8 13:19 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id NAA13478 for ; Fri, 8 Mar 1996 13:19:21 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id NAA06713 for quake-editing-outgoing; Fri, 8 Mar 1996 13:11:49 +0100 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id NAA06708 for ; Fri, 8 Mar 1996 13:11:47 +0100 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id NAA13440; Fri, 8 Mar 1996 13:10:04 +0100 (MET) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id NAA06520; Fri, 8 Mar 1996 13:09:56 +0100 (MET) From: Bernd Kreimeier Date: Fri, 8 Mar 1996 13:09:56 +0100 (MET) Message-Id: <199603081209.NAA06520@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: Re: Question X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 897 X-Lines: 32 Status: RO > misc. stuff on Mesa, VRML etc. deleted Bogus. Looks like I haven't really been awake yesterday. The main advantage of using VRML is that there are already VRML browser/viewer. Convert whatever you want to see to VRML scene descriptions, and load the file with one of them. Dead slow on a PC for now, but workable and portable. I digged up the mail on GLView at home: forwarded with next posting. For all you Windrowsers out there :-). There is an overview at http://www.sdsc.edu/SDSC/Partners/vrml/software/browsers.html Modelers are available there at ../modelers.html. VRweb (recommended for linux) is at http://www.iicm.tu-graz.ac.at/Cvrweb (possibly slow connection). Now what you need is to get a version of qvlib running with your program, and dump your data to a VRML file. Depending on your browser's caps, you're done. b. From quake-editing-owner@nvg.unit.no Fri Mar 8 13:19 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id NAA13483 for ; Fri, 8 Mar 1996 13:19:39 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id NAA06688 for quake-editing-outgoing; Fri, 8 Mar 1996 13:10:50 +0100 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id NAA06681 for ; Fri, 8 Mar 1996 13:10:48 +0100 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id NAA13444 for ; Fri, 8 Mar 1996 13:10:48 +0100 (MET) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id NAA06555 for quake-editing@nvg.unit.no; Fri, 8 Mar 1996 13:10:40 +0100 (MET) From: Bernd Kreimeier Date: Fri, 8 Mar 1996 13:10:40 +0100 (MET) Message-Id: <199603081210.NAA06555@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: Re: Question X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 2870 X-Lines: 72 Status: RO Forwarded: a shareware OpenGL based Windows VRML browser. b. >From www-vrml-owner@wired.com Fri Nov 24 23:22 MET 1995 From: "Holger Grahn" To: www-vrml@wired.com Subject: ANNOUNCE: GLView 2.02 a new WIN VRML OpenGL Browser Announcing GLView 2.0, the worlds first Shareware VRML Browser for Windows 95 and Windows NT. GLView uses Microsoft OpenGL for rendering, meaning support for *all* display modes from 16 and 256 to True-Color and support for 3D engine boards (e.g. Glint or others). Available at: http://www.snafu.de/~hg GLView provides more features than any other VRML browser (at least currently): - import of RAW, GEO, Wavefront OBJ (f) and AutoCad DXF files. - export of RAW, GEO, STL, VRML (single object) files - support for SFImage, SGI RGB, DIB/BMP, Targa, Jpeg and GIF texture image formats. - simple VRML object/material/texture animations using experimental VRML extensions nodes Rotor, Shuttle, Blinker, TextureRotor - supports 3D extruded VRML text - 3D morphing of arbitrary VRML indexFaceSets (e.g. a cow becomes a sphere). - detailed camera control including near and far clipping planes and view angle - many viewstyles from shaded, bounding-boxes to lighted/textured/antialiased wireframe - for portability from Inventor, most Inventor Geometry nodes are supported. - support for all special things like multiple emissive indexed face/vertex materials, LOD, WWWAnchor and camera switching, viewpoints, texture transforms ... automatic triangulation of indexed faces sets .... For VRML Authors there are other features of interest like - collapsing an entire VRML Scene-Tree to a single (triangulated) IndexedFaceSet - Material-Editor - special TextureCoordinate generation functions (e.g. sphere/cylinder projection) - creation of 3D Text logos from arbitrary True-Type fonts - 3D-file conversion For a GL techie GLView allows access to low-level OpenGL options like - Texture filtering rules (e.g. mip-mapping, bilinear) - Fog - OpenGL pixelformats, triangle strip construction - OpenGL extension functions - frame rate display .... The next versions will probably bring : a Python script language VRML extension, 3D Particle Systems, some VRML scene editing, a VRML NodeInterpolator for camera animations and texture/material blending. e.g. to animate Material over time using some keyframes: NodeInterpolator { # interpolate all child nodes and traverses the resulting in-between node speed 5.0 # once cyle in 5 seconds Material{} Material{} Material{} ... } I hope you will have fun with GLView, thanks for the help with Netscape DDE to the VRML mailing list. HG ################################################### Holger Grahn hg@berlin.snafu.de http://www.snafu.de/~hg From quake-editing-owner@nvg.unit.no Sat Mar 9 02:01 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 CAA15206 for ; Sat, 9 Mar 1996 02:01:54 +0100 (MET) Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with SMTP id CAA22623 for ; Sat, 9 Mar 1996 02:02:45 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id BAA04654 for quake-editing-outgoing; Sat, 9 Mar 1996 01:53:17 +0100 Received: from system ([204.120.250.14]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id BAA04649 for ; Sat, 9 Mar 1996 01:53:13 +0100 Received: by localhost from system (router,SLmail95 V1.1); Fri, 08 Mar 96 18:55:48 Received: from jim by system (204.120.250.19::mail daemon,SLmail95 V1.1); Fri, 08 Mar 96 18:54:47 Message-ID: <3140D588.51EA@gcchem.com> Date: Fri, 08 Mar 1996 18:49:12 -0600 From: Jim Bucher X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: quake-editing@nvg.unit.no Subject: Quake Palette Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 7 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 336 I am working on a .mdl viewer and I need to know the internal format of the quake palette. I imagine it uses a look up table, but I don't know the format of the table. BTW, does anyone else think it is strange that the .mdl textures are variable width? This makes the inner loop a lot slower than using a 256 or power of 2 width. From quake-editing-owner@nvg.unit.no Sat Mar 9 16:24 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id QAA15831 for ; Sat, 9 Mar 1996 16:24:05 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id QAA18233 for quake-editing-outgoing; Sat, 9 Mar 1996 16:20:26 +0100 Received: from europe.std.com (europe.std.com [192.74.137.10]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id QAA18223 for ; Sat, 9 Mar 1996 16:20:20 +0100 Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id KAA29723; Sat, 9 Mar 1996 10:20:18 -0500 Received: from ssimpson.world.std.com (world.std.com) by world.std.com (5.65c/Spike-2.0) id AA08197; Sat, 9 Mar 1996 10:19:13 -0500 Message-Id: <3141A263.363F@world.std.com> Date: Sat, 09 Mar 1996 10:23:15 -0500 From: Steve Simpson X-Mailer: Mozilla 2.0 (Win95; I) Mime-Version: 1.0 To: Quake editing mailing list Subject: Quake tools in C++ Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 4 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 250 I'm interested in writing some Quake tools in C++, preferably using the C++ Standard Template Library (STL). I'll be developing using Win95 with memory mapped files. Are there others out there with similar interests (i.e. using C++ rather than C)? From quake-editing-owner@nvg.unit.no Sat Mar 9 16:37 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id QAA15852 for ; Sat, 9 Mar 1996 16:37:42 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id QAA18463 for quake-editing-outgoing; Sat, 9 Mar 1996 16:36:40 +0100 Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id QAA18456 for ; Sat, 9 Mar 1996 16:36:35 +0100 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.132.130]) by mailgate.ericsson.se (8.6.11/1.0) with ESMTP id QAA00483 for ; Sat, 9 Mar 1996 16:36:32 +0100 Received: (from eedraq@localhost) by chapelle.eed.ericsson.se (8.7.1/8.7.1) id QAA25659 for quake-editing@nvg.unit.no; Sat, 9 Mar 1996 16:36:33 +0100 (MET) Date: Sat, 9 Mar 1996 16:36:33 +0100 (MET) Message-Id: <199603091536.QAA25659@chapelle.eed.ericsson.se> To: quake-editing@nvg.unit.no Subject: Re: Quake Palette From: Raphael.Quinet@eed.ericsson.se Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 691 X-Lines: 14 Status: RO On Fri, 08 Mar 1996, Jim Bucher wrote: > I am working on a .mdl viewer and I need to know the internal format of > the quake palette. I imagine it uses a look up table, but I don't know > the format of the table. BTW, does anyone else think it is strange that > the .mdl textures are variable width? This makes the inner loop a lot > slower than using a 256 or power of 2 width. The Quake palette is a simple array of 256 * 3 bytes (RGB). The palette is stored in gfx.wad. Take a look at "LoadPalette()" in QEU 0.3 (in the file f_bitmap.c). This should show you how to use it. You can also compile "unwad2" and see how it saves the palette in BMP files. -Raphael From quake-editing-owner@nvg.unit.no Sat Mar 9 20:31 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id UAA16043 for ; Sat, 9 Mar 1996 20:31:41 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id UAA21041 for quake-editing-outgoing; Sat, 9 Mar 1996 20:30:15 +0100 Received: from system ([204.120.250.14]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id UAA21036 for ; Sat, 9 Mar 1996 20:30:10 +0100 Received: by localhost from system (router,SLmail95 V1.1); Sat, 09 Mar 96 13:32:31 Received: from jim by system (204.120.250.19::mail daemon,SLmail95 V1.1); Sat, 09 Mar 96 13:31:49 Message-ID: <3141DB5D.CB9@gcchem.com> Date: Sat, 09 Mar 1996 13:26:21 -0600 From: Jim Bucher X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: quake-editing@nvg.unit.no Subject: Re: Quake Palette References: <199603091536.QAA25659@chapelle.eed.ericsson.se> Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 17 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 717 Raphael.Quinet@eed.ericsson.se wrote: > > The Quake palette is a simple array of 256 * 3 bytes (RGB). The palette > is stored in gfx.wad. Take a look at "LoadPalette()" in QEU 0.3 (in the > file f_bitmap.c). This should show you how to use it. You can also > compile "unwad2" and see how it saves the palette in BMP files. > > -Raphael I know how the palette is set up, but when I use the palette from the gfx.wad the textures do not look right. This leads me to believe that they are using a color look up table for the texture. So, do you know if the textures reference the palette directly, or is there is an intermediate color quantization table? It could be that I have just set the palette wrong. From quake-editing-owner@nvg.unit.no Sat Mar 9 21:16 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id VAA16089 for ; Sat, 9 Mar 1996 21:16:45 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id VAA21571 for quake-editing-outgoing; Sat, 9 Mar 1996 21:09:25 +0100 Received: from system ([204.120.250.14]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id VAA21566 for ; Sat, 9 Mar 1996 21:09:21 +0100 Received: by localhost from system (router,SLmail95 V1.1); Sat, 09 Mar 96 14:11:35 Received: from jim by system (204.120.250.19::mail daemon,SLmail95 V1.1); Sat, 09 Mar 96 14:10:50 Message-ID: <3141E483.4865@gcchem.com> Date: Sat, 09 Mar 1996 14:05:23 -0600 From: Jim Bucher X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: quake-editing@nvg.unit.no Subject: Re: Quake Palette References: <199603091536.QAA25659@chapelle.eed.ericsson.se> <3141DB5D.CB9@gcchem.com> Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 14 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 618 Jim Bucher wrote: > > I know how the palette is set up, but when I use the palette from the > gfx.wad the textures do not look right. This leads me to believe that they > are using a color look up table for the texture. So, do you know if the > textures reference the palette directly, or is there is an intermediate > color quantization table? It could be that I have just set the palette > wrong. I just fixed the problem. I was setting the palette wrong. The palette entries are in the range of 0-255. The VGA DAC only accepts 6-bit entries so I had to right shift all values by 2 before setting the palette. From quake-editing-owner@nvg.unit.no Sun Mar 10 03:41 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id DAA16433 for ; Sun, 10 Mar 1996 03:41:56 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id DAA25696 for quake-editing-outgoing; Sun, 10 Mar 1996 03:34:28 +0100 Received: from relay-2.mail.demon.net (disperse.demon.co.uk [158.152.1.77]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id DAA25691 for ; Sun, 10 Mar 1996 03:34:16 +0100 Received: from post.demon.co.uk ([158.152.1.72]) by relay-2.mail.demon.net id ac22581; 10 Mar 96 2:34 GMT Received: from tsys.demon.co.uk ([158.152.159.87]) by relay-3.mail.demon.net id ab23405; 10 Mar 96 2:29 GMT Date: Sun, 10 Mar 96 01:40:28 GMT Message-ID: <11215@tsys.demon.co.uk> From: Tom Wheeley Organization: City Zen FM To: quake-editing@nvg.unit.no Subject: Distributing Quake maps (long-ish, wordy and rambling :) X-Mailer: Demon Internet Simple News v1.30 Lines: 87 X-Sig-By: Tomsystems Quote v1.2. (c)1996 Tom Wheeley, tomw@tsys.demon.co.uk Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 4287 X-Lines: 90 Status: RO Reading both Raphael's recent article in rgcqe and the Quake specs, it seems to me like we do not want hundreds of textures cluttering peoples maps. Now, I don't know: a) How close people are to anything resembling level editors. (Not close, I should think, seeing how many `lookups' there are to be calculated in the maps/*.bsp files. b) How much Quakes handling of textures (`surfaces') will change between this test version (qkspec30) and the wondrous mythical `Final Version'. However, my thoughts on these are: a) If we agree on something now, perhaps with a bit of source, then a standard for distributing levels can be set before we get rogue levels making the rounds of the ftp/www sites... b) I am assuming that having the textures in each map will not change to references. There is also the issue of including id's textures in distributed levels. At the minimum I am proposing is a tool not dis-similar to DeuSF or DeuTex which is run locally by the end user. This will process a list of textures which the program `statically links' into a final BSP file. This control file could be designed in 3 ways. . structure based, and thus virtually unmaintainable by humans, but easy for programs to fiddle with. . text file, for the most part using the `texture numbers' (for more info on how the textures are referenced, see Quake Specs). This would be created by the map editor, which would interface with the user with the texture names . text file, but uses the texture names when specifying sources. This would be the slowest (but not that slow) to process. It would be easily maintainable by humans though :) Using the 3rd format, it would look something like this: (The names are complete fabrications!). # Quake `MakeTex.cfg' file. #StoredName Source file Entry name RedBrickWall maps/test1.bsp IDREDWALL # Search a BSP file Stuccoish maps/test1.dir/entry02.lmp IDSTUCCOISH # Search multi MIP lump SecretSrc maps/test3.bsp =12 # Entry 12 in a BSP # End sample MakeTex.cfg file Unfortunately, the only magic which can be tested for is for the BSP files and so no-way could be established for checking that a miptex lump _is_ a miptex lump (without checking the size difference of the offsets, possibly). Thus raw .MIP (or whatever) files would have to be outlawed, they would have to start with the very simple multiple MIP header (as per the beginning of the miptex lump) of size 1. This idea of processing at the users locale could possibly be extended to the creation of the various abstract stuctures which comprise most of the rest of the .BSP file. Finally, I think the _easiest_ way to distribute the rest of the data would be within a PAK file, possibly renamed LEV or QL (or .TOM ;-)). Then each BSP lump would have an entry in the .PAK file, along with new mip textures (referenced in the MakeTex file as ``NewName PAKentryname'' -- 2 tokens). The reason each mip texture would have its own PAK entry, rather than a simgle MultiMIP entry is that it would make processing simpler (extracting and searching one archive rather than 2) The MakeTex itself would be in the PAK as Entry 'MakeTex'. Other (possibly standardized) entries could be made such as `Author', 'Description', 'Licence' etc. These could be displayed by the MakeTex program. There is then the small dilemma of whether to have MakeTex work on the distribution file directly (save disk space) or create a new file completely. If there is sufficient reason for the first option, then perhaps the distributable file would need to be structured almost exactly like a BSP file, and the new textures simply appended. This, imho, is not as neat. I would like to thank both of you for reading this far ;-) I would like other's opinions on this. (I can tell I've missed something obvious... :) I have done a bit of preliminary coding for MakeTex, but there's no point going to far with it if the idea is flawed. I am using, abusing and extending the QEU files to do this. (mainly q_*, f_bsp, f_pack and my own skeletal f_miptex) -- * TQ 1.0 * The 'Just So Quotes'. I know you're supposed to take life one day at a time -- but lately several days have attacked me at once. From quake-editing-owner@nvg.unit.no Sun Mar 10 09:15 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id JAA16657 for ; Sun, 10 Mar 1996 09:15:51 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id JAA28815 for quake-editing-outgoing; Sun, 10 Mar 1996 09:08:27 +0100 Received: from portal.atak (lpsg.demon.co.uk [158.152.141.232]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id JAA28810 for ; Sun, 10 Mar 1996 09:08:15 +0100 Received: (from tom@localhost) by portal.atak (8.6.12/8.6.12) id IAA01069; Sun, 10 Mar 1996 08:06:27 GMT Date: Sun, 10 Mar 1996 08:06:26 +0000 (GMT) From: Tom Lees X-Sender: tom@portal.atak To: quake-editing@nvg.unit.no Subject: Re: Distributing Quake maps (long-ish, wordy and rambling :) In-Reply-To: <11215@tsys.demon.co.uk> Message-ID: MIME-Version: 1.0 Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 73 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 3460 On Sun, 10 Mar 1996, Tom Wheeley wrote: > At the minimum I am proposing is a tool not dis-similar to DeuSF or DeuTex > which is run locally by the end user. This will process a list of textures > which the program `statically links' into a final BSP file. This is a good idea, but it shouldn't be too slow, otherwise we will get 'binaries' distributed versions of levels as well as 'source' versions. > > This control file could be designed in 3 ways. > > . structure based, and thus virtually unmaintainable by humans, but easy > for programs to fiddle with. > . text file, for the most part using the `texture numbers' (for more info > on how the textures are referenced, see Quake Specs). This would be > created by the map editor, which would interface with the user with > the texture names > . text file, but uses the texture names when specifying sources. This > would be the slowest (but not that slow) to process. It would be easily > maintainable by humans though :) > Or, it could be structure based, but created from a file using the 3rd format, for the best of both worlds. > Unfortunately, the only magic which can be tested for is for the BSP files and > so no-way could be established for checking that a miptex lump _is_ a miptex > lump (without checking the size difference of the offsets, possibly). Thus > raw .MIP (or whatever) files would have to be outlawed, they would have to > start with the very simple multiple MIP header (as per the beginning of the > miptex lump) of size 1. Why not use a different format completely (like BMP or GIF or something)? This would probably result in minimal work for level designers and level editor programmers, and make the distributed level format more portable in the case of the Quake structures changing format. > This idea of processing at the users locale could possibly be extended to the > creation of the various abstract stuctures which comprise most of the rest of > the .BSP file. However, I think that this would slow down the local processing time too much, leading to separate binary and source distributions. > The MakeTex itself would be in the PAK as Entry 'MakeTex'. Other (possibly > standardized) entries could be made such as `Author', 'Description', 'Licence' > etc. These could be displayed by the MakeTex program. I'm not sure if this is completely necessary. If the format of the levels within the distributed PAK file is going to be different than in standard Quake BSP files, why not simply put the data as part of the new distribution level format? > There is then the small dilemma of whether to have MakeTex work on the > distribution file directly (save disk space) or create a new file completely. > If there is sufficient reason for the first option, then perhaps the > distributable file would need to be structured almost exactly like a BSP file, > and the new textures simply appended. This, imho, is not as neat. If the full version of Quake supports more than a single PAK file, a nice option would be for the user to be all his or her favourite levels in one PAK file, which could then be loaded every time Quake starts, then access to all the user-created levels would be simple. However, I don't think there is any call to directly modify the distribution files, other than that it keeps the directory structure and files in the Quake directory cleaner. -- Tom Lees (tom@lpsg.demon.co.uk) From quake-editing-owner@nvg.unit.no Sun Mar 10 10:39 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id KAA16741 for ; Sun, 10 Mar 1996 10:39:41 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id KAA29702 for quake-editing-outgoing; Sun, 10 Mar 1996 10:32:43 +0100 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id KAA29697 for ; Sun, 10 Mar 1996 10:32:40 +0100 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id KAA16730 for ; Sun, 10 Mar 1996 10:32:43 +0100 (MET) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id KAA08721 for quake-editing@nvg.unit.no; Sun, 10 Mar 1996 10:32:33 +0100 (MET) From quake-editing-owner@nvg.unit.no Sun Mar 10 10:23 MET 1996 From: Bernd Kreimeier Date: Sun, 10 Mar 1996 10:15:51 +0100 (MET) To: quake-editing@nvg.unit.no Subject: Re: Quake tools in C++ X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 741 X-Lines: 19 Status: RO > From: Steve Simpson > I'm interested in writing some Quake tools in C++, preferably using > the C++ Standard Template Library (STL). I'll be developing using > Win95 with memory mapped files. Are there others out there with > similar interests (i.e. using C++ rather than C)? All my tools (which are not primarily intended for Quake) are/will be written in C++. I do not think, however, that I will use the STL. From what I have seen, gcc-2.7.2 still has problems with STL, and I consider UNIX (read: linux) and GCC (hopefully including DJGPP) my base plattform. Is there any particular reason for your suggesting STL? Haven't looked too closely, yet. b. From quake-editing-owner@nvg.unit.no Sun Mar 10 10:39 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id KAA16741 for ; Sun, 10 Mar 1996 10:39:41 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id KAA29702 for quake-editing-outgoing; Sun, 10 Mar 1996 10:32:43 +0100 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id KAA29697 for ; Sun, 10 Mar 1996 10:32:40 +0100 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id KAA16730 for ; Sun, 10 Mar 1996 10:32:43 +0100 (MET) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id KAA08721 for quake-editing@nvg.unit.no; Sun, 10 Mar 1996 10:32:33 +0100 (MET) From: Bernd Kreimeier Date: Sun, 10 Mar 1996 10:32:33 +0100 (MET) Message-Id: <199603100932.KAA08721@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: Re: Distributing Quake maps (long-ish, wordy and rambling :) X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 2189 X-Lines: 48 Status: RO > misc. discussion and proposals about distribution files deleted One remark: as long as we do not know the final PAK/WAD2/whatever format, it makes no sense to invent another file format with a huge bias towards Quake. In 1995, I wrote a proposal for a generalized WAD file structure. I remember a WAD API proposal by somebody from the DEU team. In addition, there are descriptions of Dark Forces and Descent files. Now take therse and PAK and WAD2, and look for what all these have in common. Here is how I handled WAD files: I wrote a separate conversion function that, reading the raw data lump of the directory, assigned lump Type information based on some heuristics. In addition, I treated the magic "IWAD" or "PWAD" as a Type indicator, too. This means that my own DWAD files could as well include PWAD or IWAD files as lumps, because I had no difference between File header and Directory entry: both had type, offset, length, and name (and checksum...), the data was just interpreted differently. The main advantage is that this is a) recursive, b) allows for including differently written files as lumps, and therefore c) allowed for using GIF, WAV etc. raw data lumps as well. If you want me to elaborate, I will dig up the specs. A good idea used by the PAK is combining tar-like structures with direct/seek access capability: the subdirectory handling. But this simply means changing the way "/" is treated in the names of generalized WAD files. Finally: think in terms of checksums, copyright information, identifiers, and resource (textures, sounds) repositories. It might be a good idea to use PNG for pictures (see Quake Developers support pages, overview of resources). GIF is not a good idea. In principle, each lump that might be used and re-distributed in different ways should provide all info about how it should be named in the directory, the checksum to verify the data is not corrupted, and the copyright/version/revision information, and the Type of lump. b. From quake-editing-owner@nvg.unit.no Sun Mar 10 15:01 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id PAA16925 for ; Sun, 10 Mar 1996 15:01:49 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id OAA31914 for quake-editing-outgoing; Sun, 10 Mar 1996 14:54:22 +0100 Received: from relay-2.mail.demon.net (disperse.demon.co.uk [158.152.1.77]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id OAA31909 for ; Sun, 10 Mar 1996 14:54:16 +0100 Received: from post.demon.co.uk ([158.152.1.72]) by relay-2.mail.demon.net id ai19683; 10 Mar 96 13:53 GMT Received: from tsys.demon.co.uk ([158.152.159.87]) by relay-3.mail.demon.net id aa07030; 10 Mar 96 13:42 GMT Date: Sun, 10 Mar 96 13:16:25 GMT Message-ID: <11239@tsys.demon.co.uk> From: Tom Wheeley Organization: City Zen FM To: quake-editing@nvg.unit.no Subject: Distributing Quake maps (long-ish, wordy and rambling :) X-Mailer: Demon Internet Simple News v1.30 Lines: 97 X-Sig-By: Tomsystems Quote v1.2. (c)1996 Tom Wheeley, tomw@tsys.demon.co.uk Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 5233 X-Lines: 99 Status: RO In article you write: > On Sun, 10 Mar 1996, Tom Wheeley wrote: > > > At the minimum I am proposing is a tool not dis-similar to DeuSF or DeuTex > > which is run locally by the end user. This will process a list of textures > > which the program `statically links' into a final BSP file. > > This is a good idea, but it shouldn't be too slow, otherwise we will get > 'binaries' distributed versions of levels as well as 'source' versions. The test maps are only a meg, so my guess is a max of about 10s on my 386sx (I'm in a similar position to Raphael -- can't play the damn game ! :) This time would be larger for more textures. There is (currently) a max of 256 textures now. I don't think it is a significant step, timewise. Slower than PKUNZIPping the file, probably, but not meaningfully so. > > > > > This control file could be designed in 3 ways. > > > > . structure based, and thus virtually unmaintainable by humans, but easy > > for programs to fiddle with. > > . text file, for the most part using the `texture numbers' (for more info > > on how the textures are referenced, see Quake Specs). This would be > > created by the map editor, which would interface with the user with > > the texture names > > . text file, but uses the texture names when specifying sources. This > > would be the slowest (but not that slow) to process. It would be easily > > maintainable by humans though :) > > > Or, it could be structure based, but created from a file using the 3rd > format, for the best of both worlds. > > > Unfortunately, the only magic which can be tested for is for the BSP files and> > so no-way could be established for checking that a miptex lump _is_ a miptex > > lump (without checking the size difference of the offsets, possibly). Thus > > raw .MIP (or whatever) files would have to be outlawed, they would have to > > start with the very simple multiple MIP header (as per the beginning of the > > miptex lump) of size 1. > > Why not use a different format completely (like BMP or GIF or something)? > This would probably result in minimal work for level designers and level > editor programmers, and make the distributed level format more portable > in the case of the Quake structures changing format. Well, the texture designers have to create the MIP textures, which are scaled by 1/2/4/8 respectively. It is up to the texture editors to convert from BMP or GIF. I don't want to have to use multi-image GIFs here. > > This idea of processing at the users locale could possibly be extended to the > > creation of the various abstract stuctures which comprise most of the rest of > > the .BSP file. > > However, I think that this would slow down the local processing time too > much, leading to separate binary and source distributions. It depends on the how fast it is to create some of them. f.e. if a particularly large lump was quick to process, it would be prefereable to process this at the end, rather than distribute a large lump. Remember that `binary' distributions are illegal, and are currently blocked from ftp.cdrom.com This is just a _possible_ extension, anyway. > > The MakeTex itself would be in the PAK as Entry 'MakeTex'. Other (possibly > > standardized) entries could be made such as `Author', 'Description', 'Licence'> > etc. These could be displayed by the MakeTex program. > > I'm not sure if this is completely necessary. If the format of the levels > within the distributed PAK file is going to be different than in standard > Quake BSP files, why not simply put the data as part of the new > distribution level format? Umm, I'm not entirely sure what you mean. The MakeTex will build a `standard' BSP file from the more general information in the PAK file. There is no good place to put `unneccesary' information in the BSP file, as there is in the PAK files, which have a more complicated directory. You can only put things in gaps, (like QEU does with version info) > > > There is then the small dilemma of whether to have MakeTex work on the > > distribution file directly (save disk space) or create a new file completely. > > If there is sufficient reason for the first option, then perhaps the > > distributable file would need to be structured almost exactly like a BSP file,> > and the new textures simply appended. This, imho, is not as neat. > > If the full version of Quake supports more than a single PAK file, a nice > option would be for the user to be all his or her favourite levels in one > PAK file, which could then be loaded every time Quake starts, then access > to all the user-created levels would be simple. However, I don't think > there is any call to directly modify the distribution files, other than > that it keeps the directory structure and files in the Quake directory > cleaner. Yes, I think I would prefer the separate file method. I must say, being able to specify PPACKs ;) would be very nice. At the moment, you can just put things in the directory tree, although it doesn't quite have the desired `priority'. .splitbung -- * TQ 1.0 * 101 Slogans for Quake 57. alt.sex.Quake: Please hit me again.... From quake-editing-owner@nvg.unit.no Sun Mar 10 15:05 MET 1996 Date: Sun, 10 Mar 96 13:31:01 GMT From: Tom Wheeley Organization: City Zen FM To: quake-editing@nvg.unit.no Subject: Re: Distributing Quake maps (long-ish, wordy and rambling :) X-Mailer: Demon Internet Simple News v1.30 Lines: 29 X-Sig-By: Tomsystems Quote v1.2. (c)1996 Tom Wheeley, tomw@tsys.demon.co.uk Sender: owner-quake-editing@nvg.unit.no Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1293 X-Lines: 31 Status: RO In article <199603100932.KAA08721@colossus.nero.uni-bonn.de> you write: > > > misc. discussion and proposals about distribution files deleted > > One remark: as long as we do not know the final PAK/WAD2/whatever > format, it makes no sense to invent another file format with a > huge bias towards Quake. > > In 1995, I wrote a proposal for a generalized WAD file structure. > I remember a WAD API proposal by somebody from the DEU team. In > addition, there are descriptions of Dark Forces and Descent > files. Now take therse and PAK and WAD2, and look for what all > these have in common. > > Here is how I handled WAD files: I wrote a separate conversion > function that, reading the raw data lump of the directory, > assigned lump Type information based on some heuristics. In addition, This is very interesting. I definitely think that this format would be more appropriate for the distribution file than the PAK. I was not really proposing a new format, other than the `MakeTex.cfg' file. Could you send to me (or post to the list if appropriate) the format of this DWAD? Also, where are the quake-development pages? Apologies if they were in the info file on the list, but I must have missed it. .splitbung -- * TQ 1.0 * The 'Just So Quotes'. Recursive, adj.; see Recursive From quake-editing-owner@nvg.unit.no Sun Mar 10 19:14 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id TAA17919 for ; Sun, 10 Mar 1996 19:14:48 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id TAA01976 for quake-editing-outgoing; Sun, 10 Mar 1996 19:07:22 +0100 Received: from odin.mdn.com (root@odin.mdn.com [199.89.235.91]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id TAA01971 for ; Sun, 10 Mar 1996 19:07:13 +0100 Received: by odin.mdn.com id (Debian /\oo/\ Smail3.1.29.1 #29.33); Sun, 10 Mar 96 13:07 EST Message-Id: From: amoon@odin.mdn.com (Alex R. Moon) Subject: Re: Distributing Quake maps To: quake-editing@nvg.unit.no Date: Sun, 10 Mar 1996 13:07:44 -0500 (EST) In-Reply-To: <11239@tsys.demon.co.uk> from "Tom Wheeley" at Mar 10, 96 01:16:25 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 7965 X-Lines: 159 Status: RO Tom Wheeley wrote: > > In article you write: > > > On Sun, 10 Mar 1996, Tom Wheeley wrote: > > > > > At the minimum I am proposing is a tool not dis-similar to DeuSF or DeuTex > > > which is run locally by the end user. This will process a list of textures > > > which the program `statically links' into a final BSP file. > > > > This is a good idea, but it shouldn't be too slow, otherwise we will get > > 'binaries' distributed versions of levels as well as 'source' versions. > > The test maps are only a meg, so my guess is a max of about 10s on my 386sx > (I'm in a similar position to Raphael -- can't play the damn game ! :) > This time would be larger for more textures. There is (currently) a max of > 256 textures now. I don't think it is a significant step, timewise. Slower > than PKUNZIPping the file, probably, but not meaningfully so. This depends on how compiled you expect this format to be. Do you expect it to contain only geometry data, or do you expect it to contain all the bsp trees and visilists as well? If the former, be aware that id has said that visilist calculation can take over an hour on a 4 processor 200MHz Alpha machine. If the latter, why not just use a .BSP format with the textures replaced with placeholders (null textures with just a texture name). Then some tool could go through and rifle the id .BSP files (or any other .BSP files) looking for the appropriate textures and chuck them in. Personally I'd like to see both, a textureless .BSP file AND a human-friendly, BSPless and visilistless geometry format. > > > This idea of processing at the users locale could possibly be extended to the > > > creation of the various abstract stuctures which comprise most of the rest of > > > the .BSP file. > > > > However, I think that this would slow down the local processing time too > > much, leading to separate binary and source distributions. > > It depends on the how fast it is to create some of them. f.e. if a > particularly large lump was quick to process, it would be prefereable to > process this at the end, rather than distribute a large lump. Remember that > `binary' distributions are illegal, and are currently blocked from ftp.cdrom.com > This is just a _possible_ extension, anyway. Compiling the BSP trees, light maps, and visilists sounds like it'll take forever. Definitely not something an end user is going to want to mess with. On the other hand, Doom showed us that dedicated BSP builders can get better results than many editors' built-in BSP builders. I hate to think how much more that will be true with visilist builders. So, how about a generic text format which all editors and compilers can use which simply gives the geometry for the level which can then be compiled into a .BSP file (with or without actual textures, see above)? > > > The MakeTex itself would be in the PAK as Entry 'MakeTex'. Other (possibly > > > standardized) entries could be made such as `Author', 'Description', 'Licence'> > etc. These could be displayed by the MakeTex program. > > > > I'm not sure if this is completely necessary. If the format of the levels > > within the distributed PAK file is going to be different than in standard > > Quake BSP files, why not simply put the data as part of the new > > distribution level format? > > Umm, I'm not entirely sure what you mean. The MakeTex will build a `standard' > BSP file from the more general information in the PAK file. There is no > good place to put `unneccesary' information in the BSP file, as there is in > the PAK files, which have a more complicated directory. You can only put > things in gaps, (like QEU does with version info) If this is all you want it to do, just use a .BSP format with a wierd version and placeholders for the texture data. Searching other .BSP files or .TEX files for the appropriate textures should be simple. Here are my thoughts on how an uncompiled level format should be constructed. There are essentially three elements which make up a quake map: 1) It's geometry (the surfaces), 2) It's inhabitants (the entities), and 3) It's textures. Everything else can be calculated given those three. Therefore, the obvious solution (to me) is to have three file types, one for each element of a level. Each level would have three files (optionally PACKed) which could be compiled into one .BSP file. The only question is what format each file should adhere to. The entities are stored in the .BSP file in a nice simple text format, so why not use that for the .ENT file? We could make it conform to DOS CR-LF format instead of its UNIX-style LFs and just strip the CRs when it's compiled into a BSP file. The textures also have their own format in the .BSP file which we can use for the .TEX (or .MIP, or whatever) files, perhaps with an additional header giving a magic and any other info we want to add. The only question then is what format we should use for storing the geometry data. In my opinion, there's no question that we should use as human-readable a text format as possible. The files probably won't be huge in the first place and compression will seriously shrink the text files such that file size shouldn't be a deciding factor in favoring a binary format. Other than size, text files have all the advantages; they're easy to read, they're easy to manipulate, they're easy to understand, etc, etc. Some time ago, iD was using a format like the following format for this purpose (snarfed from an old ddt irc log, everything has, no doubt, changed): : 4 WALL14_5 0 0 0 0 0 0 (0,912,176,144) (0,928,176,144) (16,928,176,144) (16,912,176,144) 4 WALL14_5 0 0 0 0 0 0 (192,928,144,0) (192,1040,144,0) (208,1040,144,0) (208,928,144,0) : In the generic case (using the variables from qkspec30), this format is: numedge texname sofs(?) tofs(?) flips(?) light(?) unknown0(?) unknown1(?) (v1_x,v1_y,v1_z1,v1_z2) (v2_x,v2_y,v2_z1,v2_z2) ... (vn_x,vn_y,vn_z1,vn_z2) Note that they're using a simple solid geometry approach instead of giving a separate entry for each surface. Each entry instead represents a sort of extruded polygon which includes numedge+2 surfaces. This has advantages for editors in that they can use the solid geometry information in their user interface and for CSM instead of forcing the user to deal with each surface separately. And for editors or files which have no solid information, you can simply set vn_z1 = vn_z2 for every vertex. Basically, if we want a text and human-readable geometry format, we need to decide whether that format should contain only surface information, or if it should contain some sort of additional solid geometry information. If the former, a format such as: numedge texname sofs tofs flips light unknow0 unknown1 (v1_x,v1_y,v1_z) (v2_x,v2_y,v2_z) ... (vn_x,vn_y,vn_z) should be sufficient. In the latter case we need something more complex, either id's format above (which is awfully limited), or perhaps something like this: # Surfaces # -------- numsurfaces : numedge texname sofs tofs flips light unknow0 unknown1 (v1_x,v1_y,v1_z) (v2_x,v2_y,v2_z) ... (vn_x,vn_y,vn_z) : # Solid Objects # ------------- numobjects : numsurfaces surface1 surface2 ... surfacen : This format is just the surfaces format from above plus a number of surface lists (similar to the surface lists used for BSP leaves) which represent solid objects, for use by editors in CSM and user-level manipulation. In summary, we've got an entities format. We've got a texture format (though we may wish to add a header). The only decision we've left to make is for a geometry format, and deciding on that should be relatively simple. -- Alex R. Moon | "A university is what a college become when the amoon@odin.mdn.com | faculty loses interest in students." 71513.1453@compuserve.com | -- John Cardi From quake-editing-owner@nvg.unit.no Mon Mar 11 23:25 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id XAA06557 for ; Mon, 11 Mar 1996 23:25:07 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id XAA28448 for quake-editing-outgoing; Mon, 11 Mar 1996 23:15:15 +0100 Received: from system ([204.120.250.14]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id XAA28443 for ; Mon, 11 Mar 1996 23:15:10 +0100 Received: by localhost from system (router,SLmail95 V1.1); Mon, 11 Mar 96 16:17:10 Received: from jim by system (204.120.250.19::mail daemon,SLmail95 V1.1); Mon, 11 Mar 96 16:16:25 Message-ID: <3144A4D8.7CFC@gcchem.com> Date: Mon, 11 Mar 1996 16:10:32 -0600 From: Jim Bucher X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: quake-editing@nvg.unit.no Subject: .MDL animations Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 8 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 426 There can be several 'animations' in each model. I am wondering if there is any information in the model file that tell which frame an animation starts and stops on. I looked at the data in the frame header, but it does not look like it contains any info on how the frames form an animated sequence. Does anyone know where the data for the animation sequences is stored? It has to be somewhere unless it is hard coded. From quake-editing-owner@nvg.unit.no Tue Mar 12 04:14 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id EAA06975 for ; Tue, 12 Mar 1996 04:14:01 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id EAA31733 for quake-editing-outgoing; Tue, 12 Mar 1996 04:05:58 +0100 Received: from r05n01.cac.psu.edu (r04n12-fddi.cac.psu.edu [146.186.157.10]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id EAA31728 for ; Tue, 12 Mar 1996 04:05:53 +0100 Received: from STW113.rh.psu.edu (STW113.rh.psu.edu [128.118.201.63]) by r05n01.cac.psu.edu (8.7.5/8.6.12) with SMTP id WAA130800 for ; Mon, 11 Mar 1996 22:05:49 -0500 Message-Id: <199603120305.WAA130800@r05n01.cac.psu.edu> X-Sender: stw113@email.psu.edu X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Date: Mon, 11 Mar 1996 22:05:32 -0500 To: quake-editing@nvg.unit.no From: stw113@psu.edu (Sean Werkema) Subject: Re: .MDL animations Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 17 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 1069 >There can be several 'animations' in each model. I am wondering if there >is any information in the model file that tell which frame an animation >starts and stops on. I looked at the data in the frame header, but it >does not look like it contains any info on how the frames form an >animated sequence. Does anyone know where the data for the animation >sequences is stored? It has to be somewhere unless it is hard coded. According to id, the selection of the appropriate frame is done by the QuakeC code. So in a way, yes, it's hard coded, and in a way, no, it's not. But it's not suprising that there is no animation information in the .MDL files. +-----------------------------------------------------------------+ | "There is no partial credit. If we cannot put a man on the | | moon we do not get any credit for putting him up into a tree." | | Email: stw113@psu.edu (Sean Werkema) | | Web: http://www.crayola.cse.psu.edu/~werkema BCNU :) | +-----------------------------------------------------------------+ From quake-editing-owner@nvg.unit.no Tue Mar 12 14:23 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id OAA12338 for ; Tue, 12 Mar 1996 14:23:19 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id OAA11745 for quake-editing-outgoing; Tue, 12 Mar 1996 14:11:14 +0100 Received: from minerva.phyast.pitt.edu (minerva.phyast.pitt.edu [136.142.111.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id OAA11740 for ; Tue, 12 Mar 1996 14:11:08 +0100 Received: (brian@localhost) by minerva.phyast.pitt.edu (8.6.10/8.6.5) id IAA18319 for quake-editing@nvg.unit.no; Tue, 12 Mar 1996 08:11:06 -0500 From: "Brian K. Martin" Message-Id: <199603121311.IAA18319@minerva.phyast.pitt.edu> Subject: Re: .MDL animations To: quake-editing@nvg.unit.no Date: Tue, 12 Mar 1996 08:11:05 -0500 (EST) In-Reply-To: <3144A4D8.7CFC@gcchem.com> from "Jim Bucher" at Mar 11, 96 04:10:32 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 20 Status: RO Content-Type: text/plain; charset="US-ASCII" Content-Length: 760 > > > > There can be several 'animations' in each model. I am wondering if there > is any information in the model file that tell which frame an animation > starts and stops on. I looked at the data in the frame header, but it > does not look like it contains any info on how the frames form an > animated sequence. Does anyone know where the data for the animation > sequences is stored? It has to be somewhere unless it is hard coded. > The data in the frame header defines the bounding block around the object. My guess is that the animation frame sequence is stored in the progs.dat file somewhere. brian p.s. MDL (MedDLe) is up to version 1.0 and now has 3d texture mapped graphics and stuff.. http://www.phyast.pitt.edu/~brian/mdlv10.zip From quake-editing-owner@nvg.unit.no Wed Mar 13 14:25 MET 1996 Date: Wed, 13 Mar 1996 08:18:35 -0500 From: Steve Simpson X-Mailer: Mozilla 2.0 (Win95; I) Mime-Version: 1.0 To: quake-editing@nvg.unit.no Subject: Re: Quake tools in C++ Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Reply-To: quake-editing@nvg.unit.no X-Lines: 36 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 1060 Bernd Kreimeier wrote: > > > From: Steve Simpson > > > I'm interested in writing some Quake tools in C++, preferably using > > the C++ Standard Template Library (STL). I'll be developing using > > Win95 with memory mapped files. Are there others out there with > > similar interests (i.e. using C++ rather than C)? > > All my tools (which are not primarily intended for Quake) are/will be > written in C++. I do not think, however, that I will use the STL. > >From what I have seen, gcc-2.7.2 still has problems with STL, and > I consider UNIX (read: linux) and GCC (hopefully including DJGPP) my > base plattform. Is there any particular reason for your suggesting > STL? Haven > > b. I'm learning STL and looking for a project to try to put it to practical use. It certainly doesn't have to be used on this project. I'd simply be looking for ways where it could be used. The important thing is doing it in C++. STL is secondary but may be useful. Steve Simpson From quake-editing-owner@nvg.unit.no Wed Mar 13 18:13 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id SAA20676 for ; Wed, 13 Mar 1996 18:13:29 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id SAA07172 for quake-editing-outgoing; Wed, 13 Mar 1996 18:11:20 +0100 Received: from smtp2.interramp.com (smtp2.interramp.com [38.8.200.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id SAA07164 for ; Wed, 13 Mar 1996 18:11:15 +0100 Received: from g-men by smtp2.interramp.com (8.6.12/SMI-4.1.3-PSI-irsmtp) id MAA09814; Wed, 13 Mar 1996 12:11:11 -0500 Message-ID: <3146F347.1CD5@interramp.com> Date: Wed, 13 Mar 1996 11:09:43 -0500 From: "John B. Williston" Organization: Williston Consulting X-Mailer: Mozilla 2.0 (WinNT; I) MIME-Version: 1.0 To: quake-editing@nvg.unit.no Subject: Re: .MDL animations References: <199603121311.IAA18319@minerva.phyast.pitt.edu> Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 21 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 780 Brian K. Martin wrote: > p.s. MDL (MedDLe) is up to version 1.0 and now has 3d texture mapped > graphics and stuff.. http://www.phyast.pitt.edu/~brian/mdlv10.zip I really like the job you've done on MedDLe. I'm trying to learn 3D graphics right now myself -- are you still willing to share the code? I suspect it would be helpful as a learning excercise. Thanks in advance! John -- http://ourworld.compuserve.com:80/homepages/williston_consulting/ ___ ___ \ \ ____ / / Williston Consulting \ \/ \/ / _____________ "Software worth buying" \ /\ / / _________/ \_/ \_/ / / 70541.1335@compuserve.com / /_________ us018032@interramp.com /_____________/ From quake-editing-owner@nvg.unit.no Wed Mar 13 19:09 MET 1996 From: Scott Coleman To: "'quake-editing@nvg.unit.no'" Subject: Map Conversion Utility, Anyone? Date: Wed, 13 Mar 1996 10:11:09 -0800 Encoding: 38 TEXT, 61 UUENCODE X-Ms-Attachment: WINMAIL.DAT 0 00-00-1980 00:00 Sender: owner-quake-editing@nvg.unit.no Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 2150 X-Lines: 40 Status: RO In perusing the postings here, I've seen some discussions of homebrew Quake editors. If it hasn't been already, I'd like to suggest that a map conversion utility, which would convert existing DOOM maps to work with the Quake Deathmatch Test engine, might be a good first project rather than a full blown editor. My reasoning is as follows: We all know that the Quake data file formats are in a state of flux, so a full-blown editor would likely represent at least a not insignificant amount of wasted effort because the end result would not work with the next release of Quake. True, much of the investment in coding will be reusable with little or no changes in the "Quake Final" editors. However, the same is true for the routines developed for the conversion utility. Among the advantages of making this map converter "detour" on the route to a editor is that it would require less development time: a script driven command line interface would suffice for the converter, as opposed to the full blown 3D rendering and point-and-click interface which the editor would require. With the thousands of existing DOOM levels as source material, we'd have plenty to tide us over until the real Quake game and levels arrive. Quake Ledges, anyone? How about Quake Danzig15? ;-) At the rate you guys are hacking out the details, it shouldn't take more than 2-3 weeks for a workable converter to come out - IF someone could be persuaded to start working on one. Anyone up for it? BTW, once the converter was finished, the code would of course serve as an excellent foundation for the eventual editor. One other wild idea: make the level compilers parallelizable over the Internet. With a few cooperating net.folks, a group of hosts could be organized to donate their spare CPU cycles to make the conversion process move along more quickly. I confess I'm not an expert in the theory behind the parallelization of algorithms such as BSP tree generation, so I don't know how practical this is - either from a technical standpoint or from a "political" standpoint - so feel free to slice it to ribbons. ;-) Reaction? Comments? From quake-editing-owner@nvg.unit.no Wed Mar 13 19:41 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id TAA20962 for ; Wed, 13 Mar 1996 19:41:01 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id TAA08780 for quake-editing-outgoing; Wed, 13 Mar 1996 19:39:08 +0100 Received: from minerva.phyast.pitt.edu (minerva.phyast.pitt.edu [136.142.111.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id TAA08775 for ; Wed, 13 Mar 1996 19:39:04 +0100 Received: (brian@localhost) by minerva.phyast.pitt.edu (8.6.10/8.6.5) id NAA27377 for quake-editing@nvg.unit.no; Wed, 13 Mar 1996 13:39:00 -0500 From: "Brian K. Martin" Message-Id: <199603131839.NAA27377@minerva.phyast.pitt.edu> Subject: Re: Map Conversion Utility, Anyone? To: quake-editing@nvg.unit.no Date: Wed, 13 Mar 1996 13:38:57 -0500 (EST) In-Reply-To: <01BB10C5.66E97C00@descent.interplay.com> from "Scott Coleman" at Mar 13, 96 10:11:09 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 7 Status: RO Content-Type: text/plain; charset="US-ASCII" Content-Length: 175 I think a doom map converter will be out as soon as some one releases a utility which calculates the BSP tree for quake. Isn't that what most of you are waiting for? brian From quake-editing-owner@nvg.unit.no Wed Mar 13 19:45 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id TAA20975 for ; Wed, 13 Mar 1996 19:45:28 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id TAA08862 for quake-editing-outgoing; Wed, 13 Mar 1996 19:43:57 +0100 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id TAA08857 for ; Wed, 13 Mar 1996 19:43:53 +0100 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id TAA20967 for ; Wed, 13 Mar 1996 19:43:49 +0100 (MET) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id TAA00668 for quake-editing@nvg.unit.no; Wed, 13 Mar 1996 19:43:40 +0100 (MET) From: Bernd Kreimeier Date: Wed, 13 Mar 1996 19:43:40 +0100 (MET) Message-Id: <199603131843.TAA00668@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: Re: Map Conversion Utility, Anyone? X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 2876 X-Lines: 64 Status: RO >I confess I'm not an expert in the theory behind >the parallelization of algorithms such as BSP tree generation, so I don't >know how practical this is Creation of a BSP is a problem of making decisions (read: selecting the right toplevel splits). This allows for brute force parallelization. Heuristics or branch'n'bound are still exploring search trees - you might try out alternatives in parallel. I do not know about any BSP specific parallelization. Anybody? Remebering the quoted John Carmack explanations, "qbsp" will not be the problem anyway, nor will the radiosity-style "light". According to this posting, the "vis"ibility list calculation is CPU intensive despite being fully parallel. Without looking into the details my guess is that parallelization of this is not difficult (more or less optimal distribution of source nodes on target processors), as long as each CPU gets a full copy of the map data - any other node might be a possible destination for LineOfSight and visibility checks. On the other suggestions: - to my experience, a decent editor is 90% GUI in terms of development effort. The WAD/PACK details do not matter in this regard. Come to think of it, it is simply the same problem any decent 3D modeler faces. Start thinking "plug-ins" instead of node builder etc. :-). - conversion of DOOM levels requires tools that depend on WAD/PACK details - as those, in turn, depend on the algorithms used. Read: id stating the files will change means the algorithms will change. Thus the "qbsp"/"light"/"vis" tools will change. While conversion is surely a step to go, I doubt it is a good intermediate. You will probably neither see those in 2-3 weeks, nor is the code likely be more reusable than any editor's. Of course, simplified conversion (no lighting, dummy visibility lists) are entirely possible. - a much more valuable intermediate might be working on VRML, DXF or 3DS conversion, which would allow for both display (utilizing VRML browsers, POVRAY) and map editing (commercial modeling software). - note that we do NOT have any map representation in the PACK/WAD/BSP. It includes pre-processed lookups, but not the Constructive Solid Geometry scene description. DOOM-speak: SSEGS, but no LINEDEFS. We have to make up this up (e.g. by taking the Geometric Workbench from Mantyla). Of course, converting DOOM files has the advantage that there is a generally accepted (albeit restricted) map representation, and working editors. Thus you have a point. >From: "Brian K. Martin" >I think a doom map converter will be out as soon as some one >releases a utility which calculates the BSP tree for quake. >Isn't that what most of you are waiting for? Indeed :-). b. From quake-editing-owner@nvg.unit.no Wed Mar 13 20:27 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id UAA21093 for ; Wed, 13 Mar 1996 20:27:29 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id UAA09616 for quake-editing-outgoing; Wed, 13 Mar 1996 20:21:50 +0100 Received: from system ([204.120.250.14]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id UAA09611 for ; Wed, 13 Mar 1996 20:21:46 +0100 Received: by localhost from system (router,SLmail95 V1.1); Wed, 13 Mar 96 13:23:41 Received: from jim by system (204.120.250.19::mail daemon,SLmail95 V1.1); Wed, 13 Mar 96 13:22:59 Message-ID: <31471F45.7F43@gcchem.com> Date: Wed, 13 Mar 1996 13:17:25 -0600 From: Jim Bucher X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: quake-editing@nvg.unit.no Subject: Re: .MDL animations References: <199603121311.IAA18319@minerva.phyast.pitt.edu> Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 15 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 633 Brian K. Martin wrote: > The data in the frame header defines the bounding block around > the object. My guess is that the animation frame sequence is stored > in the progs.dat file somewhere. Could you post the format of the header? > p.s. MDL (MedDLe) is up to version 1.0 and now has 3d texture mapped > graphics and stuff.. http://www.phyast.pitt.edu/~brian/mdlv10.zip I just checked it out. Pretty cool. My viewer also does 3D texture mapping, and can cycle through the frames. I'll probably upload it to ftp.cdrom.com in a couple of days. It will be called QMV05.ZIP. First I am going to have some friends test it out. From quake-editing-owner@nvg.unit.no Wed Mar 13 22:40 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id WAA21255 for ; Wed, 13 Mar 1996 22:40:15 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id WAA11584 for quake-editing-outgoing; Wed, 13 Mar 1996 22:32:20 +0100 Received: from minerva.phyast.pitt.edu (minerva.phyast.pitt.edu [136.142.111.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id WAA11579 for ; Wed, 13 Mar 1996 22:32:17 +0100 Received: (brian@localhost) by minerva.phyast.pitt.edu (8.6.10/8.6.5) id QAA28818 for quake-editing@nvg.unit.no; Wed, 13 Mar 1996 16:32:14 -0500 From: "Brian K. Martin" Message-Id: <199603132132.QAA28818@minerva.phyast.pitt.edu> Subject: Re: .MDL animations To: quake-editing@nvg.unit.no Date: Wed, 13 Mar 1996 16:32:13 -0500 (EST) In-Reply-To: <31471F45.7F43@gcchem.com> from "Jim Bucher" at Mar 13, 96 01:17:25 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 20 Status: RO Content-Type: text/plain; charset="US-ASCII" Content-Length: 601 > > > > Brian K. Martin wrote: > > > The data in the frame header defines the bounding block around > > the object. My guess is that the animation frame sequence is stored > > in the progs.dat file somewhere. > Could you post the format of the header? > first 4 bytes are 0. The next three are the lower limits, then a mystery byte, the next three are the upper limits, then a mystery byte. The x, y, z floats for each limit is found in the same way you find the vertices (see quake specs). In MedDLe, in 3d mode, hit 'h' and you will see the bounding box, then cycle through the frames. From quake-editing-owner@nvg.unit.no Wed Mar 13 23:09 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id XAA21326 for ; Wed, 13 Mar 1996 23:09:55 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id XAA11940 for quake-editing-outgoing; Wed, 13 Mar 1996 23:02:04 +0100 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id XAA11935 for ; Wed, 13 Mar 1996 23:02:02 +0100 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id XAA21283 for ; Wed, 13 Mar 1996 23:02:01 +0100 (MET) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id XAA00792 for quake-editing@nvg.unit.no; Wed, 13 Mar 1996 23:01:50 +0100 (MET) From: Bernd Kreimeier Date: Wed, 13 Mar 1996 23:01:50 +0100 (MET) Message-Id: <199603132201.XAA00792@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: Forward: Intermediate file format X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1402 X-Lines: 36 Status: RO Forwarded to this mailing list..... From: madsdyd@jarnsaxa.diku.dk (Mads Dydensborg) Newsgroups: rec.games.computer.quake.editing Subject: Intermidiate File format nessecary?? Date: 11 Mar 1996 17:49:16 GMT HI all. After reading the Unofficial Quake Specs, (Thanks to Olivier Montanuy and cowriters), I'm left with the impression, that a BSP file, may not be the best format to work with, during the *design* of a new level : When creating the BSP file, surfaces may be split, new vertices and edges created, etc. Oppisite to DOOM, where the SSEGS etc, where additional information. Is this a correct understanding? If yes, would it serve all purposes to agree on a format for exchanging files under development? In this way, (if possible), a format for editing could include ways to name mip-textures, etc. etc., and thereby maybe even reduce the size of Quake add on levels : Collections of textures could be distributed, and semicompiled levels could be distributed and compiled by each user into BSP maps, from a tool designed for this. Am I completly off track here? Probably.. :-) Mads -- +---------------------------------------------------------------------+ | Mads Bondo Dydensborg. Student at DIKU, Copenhagen - Denmark. | | Email: madsdyd@diku.dk www: http://www.diku.dk/students/madsdyd | +---------------------------------------------------------------------+ From quake-editing-owner@nvg.unit.no Wed Mar 13 23:19 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id XAA21348 for ; Wed, 13 Mar 1996 23:19:51 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id XAA12059 for quake-editing-outgoing; Wed, 13 Mar 1996 23:11:54 +0100 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id XAA12054 for ; Wed, 13 Mar 1996 23:11:51 +0100 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id XAA21337 for ; Wed, 13 Mar 1996 23:11:50 +0100 (MET) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id XAA00806 for quake-editing@nvg.unit.no; Wed, 13 Mar 1996 23:11:43 +0100 (MET) From: Bernd Kreimeier Date: Wed, 13 Mar 1996 23:11:43 +0100 (MET) Message-Id: <199603132211.XAA00806@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: Re: Forward: Intermediate file format X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 2857 X-Lines: 62 Status: RO Forward of my reply.... From: bernd@NeRo.Uni-Bonn.DE (Bernd Kreimeier) Newsgroups: rec.games.computer.quake.editing Subject: Re: Intermidiate File format nessecary?? Date: 13 Mar 1996 12:45:14 GMT In article madsdyd@jarnsaxa.diku.dk (Mads Dydensborg) writes: > From: madsdyd@jarnsaxa.diku.dk (Mads Dydensborg) > > After reading the Unofficial Quake Specs, (Thanks to Olivier Montanuy and > cowriters), I'm left with the impression, that a BSP file, may not be the > best format to work with, during the *design* of a new level : When > creating the BSP file, surfaces may be split, new vertices and edges created, > etc. Oppisite to DOOM, where the SSEGS etc, where additional information. > > Is this a correct understanding? Yep. While the details of the BSP lookups will probably change significantly until the final release of the shareware version, this particular detail might not. It comes to my mind that distributing the preprocessed lookup information (equivalent to SSEGS) while not using an level editing information (equivalent to LINEDEFS) will make creating derivative works and modification of both proprietary and free maps more difficult. Which might or might not be done intentionally. > If yes, would it serve all purposes to agree on a format for exchanging > files under development? In this way, (if possible), a format for > editing could include ways to name mip-textures, etc. etc., and thereby maybe > even reduce the size of Quake add on levels : Collections of textures > could be distributed, and semicompiled levels could be distributed and > compiled by each user into BSP maps, from a tool designed for this. Indeed. There are a lot of related issues (reference resource databases and management of contribution repositories, the need of a CSG description of a level for editing purposes, conversion issues of old resource files aka WADs), and the fact that it will be futile to develop anything sophisticated with only qtest1 in mind. Still any good proposal is virtually worthless without a portable and commonly accepted reference library supporting I/O based on any such non-id file format. It will take some time. And most people will ignore even a decently supported solution, solely because it is not used by id. > Am I completly off track here? Probably.. :-) I don't think so. Good point indeed. You might find some further discussion of this on the Quake Developers mailing list (majordomo@nvg.unit.no, send mail w/o Subject:, body: info quake-editing) soon. b. --------------------------------------------------------------------------- "Problem solving is hunting. It is savage pleasure, and we are born to it." --------------------------------------------------------------------------- From quake-editing-owner@nvg.unit.no Thu Mar 14 11:21 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id LAA23091 for ; Thu, 14 Mar 1996 11:21:56 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id KAA20352 for quake-editing-outgoing; Thu, 14 Mar 1996 10:54:27 +0100 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id KAA20347 for ; Thu, 14 Mar 1996 10:54:21 +0100 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id KAA22977 for ; Thu, 14 Mar 1996 10:54:20 +0100 (MET) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id KAA02976 for quake-editing@nvg.unit.no; Thu, 14 Mar 1996 10:54:14 +0100 (MET) From: Bernd Kreimeier Date: Thu, 14 Mar 1996 10:54:14 +0100 (MET) Message-Id: <199603140954.KAA02976@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: The Gimp! X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1116 X-Lines: 36 Status: RO In a flash of shallow inspiration, I wrote > Start thinking "plug-ins" instead of node builder etc. :-). Now here's your daily pointer: http://www.xcf.berkeley.edu/~gimp/gimp.html or use the image-intensive index page of this image conversion, manipulation, and paint tool. I recommend this to anybody who is thinking of some kinf of Quake Construction/Developers Kit for Linux, be it for free distribution or private use. >From a programmer's point of view, I am particularly interested in the external module (plug-in) interface. If you think of creating an editor or a frontend for tools, you should take a close look at this. I will! b. P.S.: Peter Mattis, one of the authors, wrote one of the DOOM-style rendering engines out there. See http://www.csua.berkeley.edu/~petm/final.html ------------------------------------------------------------------- "Bring out the Gimp." "The Gimp's sleepin'!" "Guess you just have to go wake 'im up now won't you?" ------------------------------------------------------------------- From quake-editing-owner@nvg.unit.no Thu Mar 14 12:55 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 MAA23437 for ; Thu, 14 Mar 1996 12:55:36 +0100 (MET) Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with SMTP id MAA17044 for ; Thu, 14 Mar 1996 12:56:32 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id MAA22826 for quake-editing-outgoing; Thu, 14 Mar 1996 12:38:45 +0100 Received: from relay-4.mail.demon.net (relay-4.mail.demon.net [158.152.1.108]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id MAA22821 for ; Thu, 14 Mar 1996 12:38:40 +0100 Received: from post.demon.co.uk ([158.152.1.72]) by relay-4.mail.demon.net id aq28211; 14 Mar 96 8:07 GMT Received: from tsys.demon.co.uk ([158.152.159.87]) by relay-3.mail.demon.net id aa28004; 14 Mar 96 2:15 GMT Date: Wed, 13 Mar 96 19:14:16 GMT Message-ID: <11422@tsys.demon.co.uk> From: Tom Wheeley Organization: City Zen FM To: quake-editing@nvg.unit.no Subject: Map Conversion Utility, Anyone? X-Mailer: Demon Internet Simple News v1.30 Lines: 36 X-Sig-By: Tomsystems Quote v1.2. (c)1996 Tom Wheeley, tomw@tsys.demon.co.uk Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1723 X-Lines: 38 Status: RO In article <01BB10C5.66E97C00@descent.interplay.com> you write: > In perusing the postings here, I've seen some discussions of homebrew Quake > editors. If it hasn't been already, I'd like to suggest that a map > conversion utility, which would convert existing DOOM maps to work with the > Quake Deathmatch Test engine, might be a good first project rather than a > full blown editor. My reasoning is as follows: > > We all know that the Quake data file formats are in a state of flux, so a > full-blown editor would likely represent at least a not insignificant > amount of wasted effort because the end result would not work with the > next release of Quake. True, much of the investment in coding will be > reusable with little or no changes in the "Quake Final" editors. However, > the same is true for the routines developed for the conversion utility. Not really. The only bits which are likely to change are 90% of the conv. utility -- as it is the file formats and BSP generation which are most likely to change. Quake will still be a 3D game, needing a 3D editor. BTW, from the Quake specs it seems that the nodes etc of the BSP file are reasonably well understood (well, documented, anyway..) So, how far has anyone got with writing a `node builder'? > Reaction? Comments? I think that such a tool, although encouraging levels which do not make use of the Quake engine, would be very popular and useful. (You could do a template in a Doom editor, then change it later in a beta Quake editor) > begin 600 WINMAIL.DAT > M>)\^(@H2`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$-@ 0` wtf?! .splitbung -- * TQ 1.0 * 101 Slogans for Quake 61. Quake: To Boldly Go Where No Hammer Has Gone Before From quake-editing-owner@nvg.unit.no Thu Mar 14 16:33 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id QAA26797 for ; Thu, 14 Mar 1996 16:33:42 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id QAA27476 for quake-editing-outgoing; Thu, 14 Mar 1996 16:23:27 +0100 Received: from kantti.helsinki.fi (root@kantti-fddi.Helsinki.FI [193.166.130.5]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id QAA27471 for ; Thu, 14 Mar 1996 16:23:14 +0100 Received: from myntti (mivars@myntti [128.214.4.25]) by kantti.helsinki.fi (8.6.12+Emil1.1/8.6.5) with SMTP id RAA08191 for ; Thu, 14 Mar 1996 17:23:09 +0200 Date: Thu, 14 Mar 1996 17:23:03 +0200 (EET) From: Lauri Alanko X-Sender: mivars@myntti To: quake-editing@nvg.unit.no Subject: One more file format suggestion Message-ID: MIME-Version: 1.0 Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 93 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 4265 Hello! As there has been talk about a file format suitable for distributing levels etc., here are some of my thoughts about this. The general problem seems to be that there are many different pieces of data that can be modified, but there are only a few forms in which Quake will read this data. Therefore a system is needed which converts editable and distributable pieces of data into Quake-readable pieces of data. It is my thought that there is no reason to limit this system merely to maps and textures. Couldn't there be a general resource location system which allows the "statical linking" of almost anything that people are likely to modify? So, basically, when someone distributes an add-on, be it a level, a model texture or whatever, it should contain information about: 1. What should be created from these add-ons (eg. a .bsp level file) 2. What else is required to create them (eg. textures, entities) In addition, the end-user should supply information about: 3. Where the required "libraries" are located (eg. a .pak file) 4. How all the things are joined to create the final product (eg. qube 2.0) The end-user should have a reference table where the "linker" can find the locations of the pieces of data needed to create the final product. This would be a text file, easily editable. Something along these lines... texture water { //Grab the texture straight from the .pak file pak id1.pak bspfile maps/test2.bsp //This is looked up in the packfile now. bspentry 02 //This would probably be the default anyway... mipname *04mwat2 } texture water { //The mipmap is composed from bitmaps mip1 maps/textures/_04mwat2.bmp //in the linking process. Slow but mip2 maps/textures/_04mwat2.bm2 //handy if one is editing the texture mip4 maps/textures/_04mwat2.bm4 //all the time. mip8 maps/textures/_04mwat2.bm8 } texture water { //This would maybe be the most common way bspfile maps/test2.bsp //to do it, grab the texture from a level. mipname *04mwat2 } Then when the new level is distributed (probably in some format that includes all the visilist calculations), there is a header or something which tells to use the symbolic texture name "water" in certain areas. When the final map is "linked", the end result will be a level where water looks like whatever the _end user_ has customized it to look like. This kind of "resource locating" could be used for anything else. A level could contain a symbolic entity "ogre", which defaults to progs/ogre.mdl, but could be redefined by the end user to contrib/progs/bgates.mdl. Or someone might just distribute an entity list and tell in the header which map it is for. A system this flexible would have advantages. Given proper configuration, it should be possible to create a new 2 meg level from a 50k distribution file with a single command. Also, the end user could (but wouldn't have to) change the outlook of the distributed level by simply changing some definitions and relinking. No need for Qeutex. Okay, there are disadvantages, too. The linking process could take a lot of time. If all the end user's textures are in .bmp files it may take a while to create proper .bsp entries from them. But the end user _could_ have everything neatly "precompiled" in a .pak file, in which case it shouldn't take too long just to copy the necessary entries and add a few from the distribution. In any case the end user could have his files in whatever format he prefers. This would require a very sophisticated "linker" program, which would read the end user's reference table and invoke the proper tools to change pieces of data from one format to another (eg. a model texture and a full model into another model where the texture has been replaced). And finally, any of this will be damn near useless until the file formats that Quake will support have been confirmed. So my idea is a system where every conceivable piece of data could be identified and automatically put in the right place to compose the final product. Silly me. Comments? How much of this would be conceivable? Lauri Alanko From quake-editing-owner@nvg.unit.no Thu Mar 14 19:12 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id TAA28571 for ; Thu, 14 Mar 1996 19:12:20 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id TAA30245 for quake-editing-outgoing; Thu, 14 Mar 1996 19:01:21 +0100 Received: from minerva.phyast.pitt.edu (minerva.phyast.pitt.edu [136.142.111.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id TAA30239 for ; Thu, 14 Mar 1996 19:01:16 +0100 Received: (brian@localhost) by minerva.phyast.pitt.edu (8.6.10/8.6.5) id NAA04253 for quake-editing@nvg.unit.no; Thu, 14 Mar 1996 13:01:13 -0500 From: "Brian K. Martin" Message-Id: <199603141801.NAA04253@minerva.phyast.pitt.edu> Subject: Re: One more file format suggestion To: quake-editing@nvg.unit.no Date: Thu, 14 Mar 1996 13:01:12 -0500 (EST) In-Reply-To: from "Lauri Alanko" at Mar 14, 96 05:23:03 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 11 Status: RO Content-Type: text/plain; charset="US-ASCII" Content-Length: 443 I think this talk may not be very useful at this exact moment. I'm not trying to sound like a smart ass, but I would guess that id will prolly have some type of load commands on the consol which allow one to add different maps while still using the standard textures. I hope they don't continue to have the maps and textures together. If they do, then we will surely need to think of something. (several good ideas so far though). brian From quake-editing-owner@nvg.unit.no Sat Mar 16 02:31 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id CAA01590 for ; Sat, 16 Mar 1996 02:31:00 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id CAA10566 for quake-editing-outgoing; Sat, 16 Mar 1996 02:18:45 +0100 Received: from relay-2.mail.demon.net (disperse.demon.co.uk [158.152.1.77]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id CAA10542 for ; Sat, 16 Mar 1996 02:17:34 +0100 Received: from post.demon.co.uk ([158.152.1.72]) by relay-2.mail.demon.net id af05634; 16 Mar 96 1:17 GMT Received: from tsys.demon.co.uk ([158.152.159.87]) by relay-3.mail.demon.net id aa09201; 16 Mar 96 0:11 GMT Date: Fri, 15 Mar 96 23:23:45 GMT Message-ID: <11503@tsys.demon.co.uk> From: Tom Wheeley Organization: City Zen FM To: quake-editing@nvg.unit.no Subject: One more file format suggestion X-Mailer: Demon Internet Simple News v1.30 Lines: 22 X-Sig-By: Tomsystems Quote v1.2. (c)1996 Tom Wheeley, tomw@tsys.demon.co.uk Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1113 X-Lines: 24 Status: RO In article <199603141801.NAA04253@minerva.phyast.pitt.edu> you write: > > I think this talk may not be very useful at this exact moment. > I'm not trying to sound like a smart ass, but I would guess > that id will prolly have some type of load commands on the consol > which allow one to add different maps while still using the standard > textures. I hope they don't continue to have the maps and textures > together. If they do, then we will surely need to think of something. > (several good ideas so far though). Well, I don't know if anyone has tried my TLM hack (beta, only available in a.b.g.q), but it runs so fast as to be transparent to the user, and reduces the distributable by a factor of approx 2. This will be greatly improved in the next version (still a hack, until we agree on a nice file format), as I think every map so far is just a modified thing list. BTW, does anyone else think that PHIL.BSP has a strange filesize, being an odd number and all? .splitbung -- * TQ 1.0 * 101 uses for dead bodies in Quake 84) Throw their Heads into other players faces to temporarily blind them. From quake-editing-owner@nvg.unit.no Sat Mar 16 22:09 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id WAA02152 for ; Sat, 16 Mar 1996 22:09:01 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id VAA29347 for quake-editing-outgoing; Sat, 16 Mar 1996 21:59:41 +0100 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id VAA29342 for ; Sat, 16 Mar 1996 21:59:37 +0100 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id VAA02137 for ; Sat, 16 Mar 1996 21:59:36 +0100 (MET) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id VAA05489 for quake-editing@nvg.unit.no; Sat, 16 Mar 1996 21:59:26 +0100 (MET) From: Bernd Kreimeier Date: Sat, 16 Mar 1996 21:59:26 +0100 (MET) Message-Id: <199603162059.VAA05489@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: WAD Conversion sketch X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 917 X-Lines: 29 Status: RO I thought again about the recent discussion of the possibility of a WAD conversion, and I recognized that I forgot one important detail. IMO the 2D BSP and a REJECT lump w/o special effects contains all information necessary to create a valid Quake BSP. We do not need a new BSP/REJECT builder for conversion. Any such converted map will still have only one floor and ceiling per z coordinate, or BSP and REJECT would not be sufficient for conversion. Nonetheless, the advantages seem to be worth the effort. I refrained from posting a lengthy but still sketchy proposal to the list. If you are interested, you will find a pointer on the Quake Developers Support page, at http://www.nero.uni-bonn.de/~dn/q-sup/ I have a deadline on easter weekend, and will probably not do much on this until then. If somebody is already working on this, please let me know. b. From quake-editing-owner@nvg.unit.no Mon Mar 18 05:55 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id FAA02996 for ; Mon, 18 Mar 1996 05:55:48 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id FAA08355 for quake-editing-outgoing; Mon, 18 Mar 1996 05:47:31 +0100 Received: from netcom9.netcom.com (etherton@netcom9.netcom.com [192.100.81.119]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id FAA08350 for ; Mon, 18 Mar 1996 05:47:28 +0100 Received: by netcom9.netcom.com (8.6.13/Netcom) id UAA10016; Sun, 17 Mar 1996 20:47:17 -0800 Date: Sun, 17 Mar 1996 20:47:17 -0800 From: etherton@netcom.com (David Etherton) Message-Id: <199603180447.UAA10016@netcom9.netcom.com> To: quake-editing@nvg.unit.no Subject: Rendering Quake surfaces Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 2289 X-Lines: 51 Status: RO [Please forgive me if this is asked a lot, I can't get through to the mail archives on http://www.nero.uni-bonn.de/~dn/qd/qd_welcome.html right now] Like just about everybody else around here, I've been playing around with trying to render the Quake levels. The Quake specs (3.0) have proved invaluable. First, in the List of Edges, if the sign bit of the edge is set, are we supposed to look at edge ~i or -i? (Nodes use ~i to mark leaves according to both the spec and my own experience). For the List of Edges, though, neither ~i nor -i seem to work particularly well, although -i seems to work slightly better. I can traverse the BSP tree and find the leaf containing my camera position correctly, so I know I've got the basics right. However, when I try to render, I find that the list of surfaces often tells me to (say) render surface 7 three times in a row, and that it's got 30 edges in the surface. Surfaces with small numbers of edges seem to "connect" together well (ie the end vertex of one edge is the start vertex of the next, and it forms a closed figure). Some surfaces with larger numbers of edges seem to form closed figures if you sort the edges after reading them in, but surfaces with 16 or more edges seem to not form closed figures. I can't imagine a fast renderer wanting to deal with anything larger than a tri or a quad, so I'm suspicious of anything with more than four edges. Combined with my experience with surfaces with large numbers of edges having nonsensical edge lists, I wonder if we're supposed to interpret the edge count differently if it's above a certain value. Also, why would the list of surfaces explicitly tell me to render the same surface two or three times in a row? I haven't done an exhaustive check, but it appears that every time a surface is supposed to render several times in a row, it usually also has a large number of edges. Am I totally off in the weeds here or is anybody else fighting the same things I am? -David Etherton ps. For what it's worth, I have been able to parse and render the models perfectly; either a Z-buffer or a bucket Z-sort seems to produce good results; the latter has some slight defects (ever seen a PlayStation?) but is *much* faster on both my PC and my SparcStation From quake-editing-owner@nvg.unit.no Mon Mar 18 11:56 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id LAA10017 for ; Mon, 18 Mar 1996 11:56:04 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id LAA12909 for quake-editing-outgoing; Mon, 18 Mar 1996 11:47:44 +0100 Received: from odin.diku.dk (root@odin.diku.dk [130.225.96.221]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id LAA12904 for ; Mon, 18 Mar 1996 11:47:42 +0100 Received: from embla.diku.dk (uffefl@embla.diku.dk [130.225.96.229]) by odin.diku.dk (8.6.12/8.6.12) with ESMTP id LAA04574 for ; Mon, 18 Mar 1996 11:47:40 +0100 Received: (uffefl@localhost) by embla.diku.dk (8.6.12/8.6.12) id LAA29329; Mon, 18 Mar 1996 11:47:36 +0100 Date: Mon, 18 Mar 1996 11:47:35 +0100 (MET) From: Uffe Friis Lichtenberg To: quake-editing@nvg.unit.no Subject: Re: WAD Conversion sketch In-Reply-To: <199603162059.VAA05489@colossus.nero.uni-bonn.de> Message-ID: MIME-Version: 1.0 Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 60 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 2554 On Sat, 16 Mar 1996, Bernd Kreimeier wrote: > I thought again about the recent discussion of the > possibility of a WAD conversion, and I recognized that > I forgot one important detail. IMO the 2D BSP and a > REJECT lump w/o special effects contains all information > necessary to create a valid Quake BSP. > > We do not need a new BSP/REJECT builder for conversion. Well, I tend to disagree. You do need additional information, as you say in your 'WAD conversions sketch', like plane-bundling (trivial), vertices (trivial), hull generation (not so trivial?), etc. But firstly you do need a 3D BSP tree: remember all the floors and ceilings are planes in Quake, and must thus partition the rest of the polygons in some way. This could lead to a number of problems if not handled right. My guess is that wad conversion would be easiest to implement if you had two utilities: one to convert a wad to an intermediate file format (perhaps the same used to distribute Quake levels) specifying polygons (with textures) and entities, and another tool to build a valid .BSP from this file format (ie. a 3D BSP generator, as well as texture reference resolving and so on.) Having it split up into two utilities would also make .DXF -> intermediate file format, .3DS -> intermediate file format, etc. a lot easier to manage, as we would be able to use all sorts of excellent 3D editors already available to edit Quake levels, and let the second utility to all the hard work afterwards. But of course, it wouldn't be trivial to create a utility that builds an efficient BSP tree. But it wouldn't be any more difficult than doing it in 2D was. > Any such converted map will still have only one floor > and ceiling per z coordinate, or BSP and REJECT would not > be sufficient for conversion. Nonetheless, the advantages > seem to be worth the effort. But where do you find wads that fulfil this requirement? I can't think of a single one. (If I understand you right.) > I refrained from posting a lengthy but still sketchy > proposal to the list. If you are interested, you will > find a pointer on the Quake Developers Support page, > at > > http://www.nero.uni-bonn.de/~dn/q-sup/ Regarding the legal issues: Maybe iD's licence doesn't explicitly forbid the creation/distribution of add-on levels for Quake, but personally I feel that we should respect iD's work and not bring out any fully-fledged editor before the registered version becomes available. But perhaps I'm alone in this? Zonk, Uffe. [uphfe] uffefl@diku.dk From quake-editing-owner@nvg.unit.no Mon Mar 18 13:57 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id NAA10577 for ; Mon, 18 Mar 1996 13:57:19 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id NAA15526 for quake-editing-outgoing; Mon, 18 Mar 1996 13:53:49 +0100 Received: from minerva.phyast.pitt.edu (minerva.phyast.pitt.edu [136.142.111.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id NAA15517 for ; Mon, 18 Mar 1996 13:53:37 +0100 Received: (brian@localhost) by minerva.phyast.pitt.edu (8.6.10/8.6.5) id HAA24996 for quake-editing@nvg.unit.no; Mon, 18 Mar 1996 07:53:25 -0500 From: "Brian K. Martin" Message-Id: <199603181253.HAA24996@minerva.phyast.pitt.edu> Subject: Re: WAD Conversion sketch To: quake-editing@nvg.unit.no Date: Mon, 18 Mar 1996 07:53:25 -0500 (EST) In-Reply-To: from "Uffe Friis Lichtenberg" at Mar 18, 96 11:47:35 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 18 Status: RO Content-Type: text/plain; charset="US-ASCII" Content-Length: 649 > > On Sat, 16 Mar 1996, Bernd Kreimeier wrote: > > Regarding the legal issues: > > Maybe iD's licence doesn't explicitly forbid the creation/distribution of > add-on levels for Quake, but personally I feel that we should respect > iD's work and not bring out any fully-fledged editor before the > registered version becomes available. But perhaps I'm alone in this? > I agree. I was upset to see complete levels and mdl files uploaded to ftp and net sites. I think the level/model editors should not work with the shareware release, unless id gives an ok. I will most likely hold back the next version of meddle because of this. brian From quake-editing-owner@nvg.unit.no Mon Mar 18 14:34 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id OAA10801 for ; Mon, 18 Mar 1996 14:34:11 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id OAA16248 for quake-editing-outgoing; Mon, 18 Mar 1996 14:24:01 +0100 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id OAA16239 for ; Mon, 18 Mar 1996 14:23:57 +0100 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id OAA10726 for ; Mon, 18 Mar 1996 14:23:48 +0100 (MET) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id OAA07312 for quake-editing@nvg.unit.no; Mon, 18 Mar 1996 14:23:42 +0100 (MET) From: Bernd Kreimeier Date: Mon, 18 Mar 1996 14:23:42 +0100 (MET) Message-Id: <199603181323.OAA07312@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: Re: WAD conversion sketch X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1113 X-Lines: 29 Status: RO I try to separate the legal issues thread from the more technical aspects. It is a futile discussion anyway. There is only one way to resolve this, namely a request from id Software. You might want to ask them. > Legal issues: not bring out any useful tools prior to > registered release. This is a slightly difficult issue. I have no intention to end discussion of such topics, which is a far cry from a public production release of anything. After all, we might as well shutdown this list for a few months if we all agree to wait for registered Quake. > tools should not work with shareware release In this case we could as well abandon any discussion of distribution file formats, and DMADDS/DeuSF-style or pack/unpack tools source distribution. It has always been possible to create a replacement IWAD because id decided to distribute the same EXE as shareware, registered, and commercial. The qtest1 seems to indicate that this will not change, which is a bad thing. b. From quake-editing-owner@nvg.unit.no Mon Mar 18 14:44 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id OAA10832 for ; Mon, 18 Mar 1996 14:44:20 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id OAA16491 for quake-editing-outgoing; Mon, 18 Mar 1996 14:35:37 +0100 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id OAA16483 for ; Mon, 18 Mar 1996 14:35:30 +0100 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id OAA10806 for ; Mon, 18 Mar 1996 14:35:26 +0100 (MET) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id OAA07387 for quake-editing@nvg.unit.no; Mon, 18 Mar 1996 14:35:18 +0100 (MET) From: Bernd Kreimeier Date: Mon, 18 Mar 1996 14:35:18 +0100 (MET) Message-Id: <199603181335.OAA07387@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: Re: WAD Conversion sketch X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1461 X-Lines: 38 Status: RO >From: Uffe Friis Lichtenberg >additional info need, namely convex hulls Has anybody verified that a Slab BSP tree is needed, or might it be easily omitted with a zero length entry? If there is only one Slab, does it have to be a convex hull, or is a bounding box sufficient? >we do need a 3D BSP tree If I am not mistaken, you could simply copy the 2D BSP into a matching 3D BSP, and convert the information from the old NODES and SSECTORS. Think about it. >the floors and ceilings are planes and have to be partitioned You are perfectly right. In fact, this might be the most difficult task to solve. It breaks down to creating closed polygons from SECTORS and LINEDEFS for each floor (ceilings will have the same partitions), and using the 2D BSP NODES info (namely the partition lines) to split the SECTORS' polygon into the Leaf2D surfaces. I already added this to the proposal. >misc. remarks on conversion, DXF, intermediate file formats All very true. However, I am skeptical that any file format not done by id will ever be agreed upon. Anybody remember the porposal by Tom Neff (WAD Interchange Format)? >>The WAD will have to have only one floor/ceiling per xy plane, >>i.e. the DOOM world geometry restrictions >But where do you find wads that fulfil this requirement? Hmmm? Any WAD that can be used with DOOM does :-). b. From quake-editing-owner@nvg.unit.no Mon Mar 18 15:08 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id PAA10880 for ; Mon, 18 Mar 1996 15:08:25 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id PAA17084 for quake-editing-outgoing; Mon, 18 Mar 1996 15:03:55 +0100 Received: from marvin.nero.uni-bonn.de (root@marvin.nero.uni-bonn.de [131.220.7.30]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id PAA17078 for ; Mon, 18 Mar 1996 15:03:52 +0100 Received: from colossus.nero.uni-bonn.de (bernd@colossus [131.220.7.29]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with ESMTP id PAA10869 for ; Mon, 18 Mar 1996 15:03:47 +0100 (MET) Received: (from bernd@localhost) by colossus.nero.uni-bonn.de (8.7.1-NeRo-SW/8.7.1) id PAA07438 for quake-editing@nvg.unit.no; Mon, 18 Mar 1996 15:03:43 +0100 (MET) From: Bernd Kreimeier Date: Mon, 18 Mar 1996 15:03:43 +0100 (MET) Message-Id: <199603181403.PAA07438@colossus.nero.uni-bonn.de> To: quake-editing@nvg.unit.no Subject: Re: WAD conversion sketch X-Sun-Charset: US-ASCII Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1326 X-Lines: 39 Status: RO I updated the proposal at http://www.nero.uni-bonn.de/~dn/q-sup/ and added some details I omitted in the first draft. It is still sketchy. Here are some important aspects: A modified DOOM BSP Node builder might be a better solution, instead of a completely separate conversion tool. I would appreciate any comment from those on the list who have actually written such a tool. Automatic conversion and DOOM map recycling is no worthwhile reason to create such a tool. Texture, door, switch issues will make any such attempt futile. Any given WAD map will not be playable, and look worse. What's the point of DOOM restricted geometry in Quake anyway? The DOOM WAD file format provides a commonly accepted intermediate file format. We could start there, and might even agree on how it should be extended. Any DOOM map editor could be modified along with a qbsp/BSP_3D Node builder to take into account different texture handling, different entities. This is a migration path. Put quite simply: if there were a 3D editor, full specs, and a working node builder guaranteed, I wouldn't waste a single thought. Right now, this project is quite educational in several regards. b. From quake-editing-owner@nvg.unit.no Mon Mar 18 15:37 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id PAA10988 for ; Mon, 18 Mar 1996 15:37:32 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id PAA17677 for quake-editing-outgoing; Mon, 18 Mar 1996 15:33:16 +0100 Received: from mailgate.ericsson.se (mailgate.ericsson.se [130.100.2.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id PAA17672 for ; Mon, 18 Mar 1996 15:33:09 +0100 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.132.130]) by mailgate.ericsson.se (8.6.11/1.0) with ESMTP id PAA16729 for ; Mon, 18 Mar 1996 15:32:58 +0100 Received: (from eedraq@localhost) by chapelle.eed.ericsson.se (8.7.1/8.7.1) id PAA22685 for quake-editing@nvg.unit.no; Mon, 18 Mar 1996 15:32:56 +0100 (MET) Date: Mon, 18 Mar 1996 15:32:56 +0100 (MET) Message-Id: <199603181432.PAA22685@chapelle.eed.ericsson.se> To: quake-editing@nvg.unit.no Subject: Legal stuff (was Re: WAD conversion sketch) From: Raphael.Quinet@eed.ericsson.se Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 3978 X-Lines: 79 Status: RO On Mon, 18 Mar 1996, Bernd Kreimeier wrote: > I try to separate the legal issues thread from the more > technical aspects. [...] I changed the subject, so that it is more obvious... > > tools should not work with shareware release > > In this case we could as well abandon any discussion > of distribution file formats, and DMADDS/DeuSF-style > or pack/unpack tools source distribution. As long as the full-featured editors do not allow you to edit the shareware game, it should be OK. The current tools are far from being "full-featured". I don't think that small tools would really harm id Software, if they work with the shareware game. Besides, it would be too much trouble for some of these small tools to check if the user has the registered game. Here is what I am planning to do for QEU: I will probably split the code in three parts. There will be the GUI library (SWAPI), the routines for handling Quake files as well as the files for other games such as Doom (I will probably call this part "GEL", for "Game Editing Library") and the programs themselves: the editor and the tools that are currently in QEU 0.3. The first two parts (SWAPI and GEL) will work with the shareware version of the game. The GUI library is independent of the game and I am planning to use it for other programs, so it is normal that it doesn't check for a registered version of anything. The Game Editing Library (or whatever it is called - suggestions are welcome) will also work with the shareware game(s) because it contains mostly low-level functions for loading and saving file related to various games. These routines don't know much about the high-level structures or the contents of the PACK file and they should be independant of the version of the game being loaded or saved. The editor will check for the registered version, because this is the only part of the code which will know the meaning of the various parts of the PACK file (or BSP files). Thus it will be able to check if the PACK file contains some entries that are only available in the registered game. By the way, I intend to release the first two parts (SWAPI and GEL) under a non-restrictive license so that anyone can copy, modify or distribute this code. The editor and tools will also be free and the source code will be available, but I will restrict commercial distribution and encourage people to contribute to the main code instead of distributing modified versions. > It has always > been possible to create a replacement IWAD because id > decided to distribute the same EXE as shareware, > registered, and commercial. The qtest1 seems to indicate > that this will not change, which is a bad thing. I'm not sure if it is a bad thing. Maintaining two different EXE's would mean more work for id Software (creating the two versions, supporting them, etc.). They cannot simply create a shareware EXE which differs only by a few bytes (i.e. a hard-coded flag), because some cracker would certainly post a patch to enable all the disabled features. Also, it is easier to pirate and distribute a single EXE file than to copy the whole CD-ROM, so a different EXE wouldn't protect id Software for a long time. If all editors are fair (towards id Software) and refuse to work with the shareware version, I think this will be enough. Some of them will be distributed as source code (such as QEU for Quake or DEU for Doom), so it would theoretically be possible for someone to patch them so that they work with the shareware game. However, someone who takes the time to go through the whole source code and track the various tests that have been scattered in the code by the author of the program would probably find it easier to get a pirate copy of the game, so I don't think this is a real problem. Of course, I assume that the authors of the editors include more than one test which checks if the user has a registered version of the game. -Raphael From quake-editing-owner@nvg.unit.no Mon Mar 18 18:20 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id SAA11529 for ; Mon, 18 Mar 1996 18:20:16 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id SAA20964 for quake-editing-outgoing; Mon, 18 Mar 1996 18:11:03 +0100 Received: from megatek.com (megatek.com [204.30.207.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id SAA20954 for ; Mon, 18 Mar 1996 18:10:58 +0100 Received: from fuzz.megatek (fuzz.megatek.com [192.43.236.81]) by megatek.com (8.6.9/8.6.6) with SMTP id JAA10162 for ; Mon, 18 Mar 1996 09:11:30 -0800 Received: by fuzz.megatek (5.0/SMI-SVR4) id AA25455; Mon, 18 Mar 1996 09:11:28 +0800 Date: Mon, 18 Mar 1996 09:11:28 +0800 From: etherton@megatek.com (David Etherton) Message-Id: <9603181711.AA25455@fuzz.megatek> To: quake-editing@nvg.unit.no Subject: Visibility Lists Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 2688 X-Lines: 65 Status: RO When trying to determine which leaves are visible from a current leaf, one looks at the vislist memory of the leaf data structure. However, it's not clear to me which of the following two formulas is correct: int i; // leaf number to check u_char *vp = start_of_vislist + leaf->vislist if (vp[i>>3] & (1<<(i&7))) { puts("is visibile"); } - or - if (vp[i>>3] & (128>>(i&7))) { puts("is visibile"); } My renderer isn't far enough along that I can readily tell; the obvious solution would be to play with the bits and run it through quake itself, but id didn't distribute a Sparc version of quake yet :(. My guess is that the first formula is correct, but I suspect there's something weird with the visibility lists because I had assumed (hoped) that for any leaf i, its own visibility bit is set in its visbility list. This would seem to make sense to me because (barring special effects), two adjacent leaves may very well have the exact same visibility lists, so they could share the list. Unfortunately, while test1.bsp and test2.bsp both have starting positions in leaves that can "see" themselves, test3.bsp does not. Any comments? Obviously my own implementation could be at fault and I'm wondering if anybody else is having similar problems. On another topic [as a bonus if you've actually read this far :)], I've found that augmenting the node structures with backpointers to their parents (after reading in the map) might prove useful for optimizing rendering. In order to render from a specific position, I'm doing the following: - Traverse the bsp tree to find which leaf the camera is in, caching the result so that I can do a quick bbox check the next time to see if I'm in the same leaf. - See if the current leaf has the same visibility list (ie offset) as our cached result. - If it does not, scan the visibility list, and for each leaf which is visible, mark the leaf as needing to be rendered, then mark its parent node as needing to be visited, and then mark *that* parent's node, and so on, until we either hit the root of the tree or hit a node that's already marked for visitation. - Start traversing the tree at the top. - If neither child node needs to be visited, stop. - If only one child node needs to be visited, only visit that child. - If both children need to be visited, then and only then test the camera position against the node's split plane to see which child needs to be visited first. We can also project the bounding box of a node or leaf into the view frustum to see if we can trivially reject the entire subtree (off the side, or behind the viewer) before visiting it as well. -David Etherton From quake-editing-owner@nvg.unit.no Mon Mar 18 18:55 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id SAA11563 for ; Mon, 18 Mar 1996 18:55:14 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id SAA21688 for quake-editing-outgoing; Mon, 18 Mar 1996 18:46:01 +0100 Received: from megatek.com (megatek.com [204.30.207.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id SAA21679 for ; Mon, 18 Mar 1996 18:45:57 +0100 Received: from fuzz.megatek (fuzz.megatek.com [192.43.236.81]) by megatek.com (8.6.9/8.6.6) with SMTP id JAA10945 for ; Mon, 18 Mar 1996 09:46:31 -0800 Received: by fuzz.megatek (5.0/SMI-SVR4) id AA25580; Mon, 18 Mar 1996 09:46:29 +0800 From: etherton@megatek.com (David Etherton) Message-Id: <9603181746.AA25580@fuzz.megatek> Subject: Re: Visibility Lists To: quake-editing@nvg.unit.no Date: Mon, 18 Mar 1996 09:46:28 -0800 (PST) In-Reply-To: <9603181711.AA25455@fuzz.megatek> from "David Etherton" at Mar 18, 96 09:11:28 am X-Mailer: ELM [version 2.4 PL21] Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1974 X-Lines: 50 Status: RO Here's a data dump from test1.bsp: VISILIST SIZE 14039 494 total leaves, 1068 total nodes leaf 0: visoffs=0 {0 bits since last} leaf 1: visoffs=0 {0 bits since last} leaf 2: visoffs=29 {232 bits since last} leaf 3: visoffs=54 {200 bits since last} leaf 4: visoffs=76 {176 bits since last} leaf 5: visoffs=102 {208 bits since last} leaf 6: visoffs=125 {184 bits since last} leaf 7: visoffs=148 {184 bits since last} leaf 8: visoffs=171 {184 bits since last} leaf 9: visoffs=197 {208 bits since last} leaf 10: visoffs=223 {208 bits since last} leaf 11: visoffs=246 {184 bits since last} leaf 12: visoffs=272 {208 bits since last} leaf 13: visoffs=298 {208 bits since last} leaf 14: visoffs=321 {184 bits since last} leaf 15: visoffs=344 {184 bits since last} leaf 16: visoffs=370 {208 bits since last} leaf 17: visoffs=393 {184 bits since last} leaf 18: visoffs=416 {184 bits since last} leaf 19: visoffs=442 {208 bits since last} leaf 20: visoffs=468 {208 bits since last} leaf 21: visoffs=494 {208 bits since last} leaf 22: visoffs=520 {208 bits since last} .... I suspect there's something weird about the visibility lists. While all of the offsets are within the boundaries of the visibility list, and some of the lists do run off the end of the end of the lump, I find the fact that all of the visibility lists overlap is rather disturbing. I can't see how sharing the same bit pattern between multiple visibility lists could ever be useful. I suspect that there's an offset and length field that we don't know about yet which would allow us to say that all leaves not in a specified range are either visible or invisible; leaves within the specified range check the visibility bitmask. Also, several of the later leaves have a visibility offset of -1; does that mean no other leaves are visible from here or all other leaves are visible from here? -David -- David Etherton | Megatek Corporation | "Shop as usual, and avoid panic buying." From quake-editing-owner@nvg.unit.no Mon Mar 18 19:20 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id TAA11597 for ; Mon, 18 Mar 1996 19:20:15 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id TAA22268 for quake-editing-outgoing; Mon, 18 Mar 1996 19:17:25 +0100 Received: from odin.diku.dk (root@odin.diku.dk [130.225.96.221]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id TAA22263 for ; Mon, 18 Mar 1996 19:17:20 +0100 Received: from andvare.diku.dk (uffefl@andvare.diku.dk [130.225.96.241]) by odin.diku.dk (8.6.12/8.6.12) with ESMTP id TAA25579 for ; Mon, 18 Mar 1996 19:17:17 +0100 Received: (uffefl@localhost) by andvare.diku.dk (8.6.12/8.6.12) id TAA01410; Mon, 18 Mar 1996 19:17:14 +0100 Date: Mon, 18 Mar 1996 19:17:14 +0100 (MET) From: Uffe Friis Lichtenberg To: quake-editing@nvg.unit.no Subject: Legal issues (was: WAD conversion sketch) In-Reply-To: <199603181323.OAA07312@colossus.nero.uni-bonn.de> Message-ID: MIME-Version: 1.0 Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 42 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 1485 On Mon, 18 Mar 1996, Bernd Kreimeier wrote: > You might want to ask them. I don't think there could be any other answer than 'no, please don't make editors available for anything other than the registered version', but of course I could be wrong. > > Legal issues: not bring out any useful tools prior to > > registered release. > > This is a slightly difficult issue. I have no intention > to end discussion of such topics, which is a far cry from a > public production release of anything. After all, we might > as well shutdown this list for a few months if we all > agree to wait for registered Quake. No no. There is IMO a BIG difference between discussing Quake hacking/editing and releasing small utils to demonstrate the concepts, and releasing fully-fledged software to modify Quake with (ie. hacking tools vs. end-user products.) I can't see any harm in the discussion or release of viewers/small editors/file format converters/etc. as long as they are not "marketed" as Quake-editors. BTW: until a Quake non-test version comes out this is all we have to play around with anyway, so there's no need trying to stop us now :) > > tools should not work with shareware release > > In this case we could as well abandon any discussion > of distribution file formats, and DMADDS/DeuSF-style > or pack/unpack tools source distribution. Well, it's a bit hard to speculate on that until the shareware finally hits the net. Zonk, Uffe. [uphfe] uffefl@diku.dk From quake-editing-owner@nvg.unit.no Mon Mar 18 19:33 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id TAA11619 for ; Mon, 18 Mar 1996 19:33:09 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id TAA22512 for quake-editing-outgoing; Mon, 18 Mar 1996 19:30:05 +0100 Received: from odin.diku.dk (root@odin.diku.dk [130.225.96.221]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id TAA22499 for ; Mon, 18 Mar 1996 19:30:00 +0100 Received: from andvare.diku.dk (uffefl@andvare.diku.dk [130.225.96.241]) by odin.diku.dk (8.6.12/8.6.12) with ESMTP id TAA26051 for ; Mon, 18 Mar 1996 19:29:57 +0100 Received: (uffefl@localhost) by andvare.diku.dk (8.6.12/8.6.12) id TAA01639; Mon, 18 Mar 1996 19:29:56 +0100 Date: Mon, 18 Mar 1996 19:29:55 +0100 (MET) From: Uffe Friis Lichtenberg To: quake-editing@nvg.unit.no Subject: Re: Legal stuff (was Re: WAD conversion sketch) In-Reply-To: <199603181432.PAA22685@chapelle.eed.ericsson.se> Message-ID: MIME-Version: 1.0 Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 54 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 2334 On Mon, 18 Mar 1996 Raphael.Quinet@eed.ericsson.se wrote: > As long as the full-featured editors do not allow you to edit the > shareware game, it should be OK. The current tools are far from being > "full-featured". Agreed. > I don't think that small tools would really harm id > Software, if they work with the shareware game. Dunno about that. Perhaps a message in these small tools that simply states "Will Not Work With The Shareware" (or something similar) would be sufficient, even though they might actually work? > The editor will check for the registered version, because this is the > only part of the code which will know the meaning of the various parts > of the PACK file (or BSP files). Thus it will be able to check if the > PACK file contains some entries that are only available in the > registered game. This is of course assuming that iD will choose a strategy similar to Doom with the registered contra shareware versions. > I'm not sure if it is a bad thing. Maintaining two different EXE's > would mean more work for id Software (creating the two versions, > supporting them, etc.). They cannot simply create a shareware EXE > which differs only by a few bytes (i.e. a hard-coded flag), because > some cracker would certainly post a patch to enable all the disabled > features. Also, it is easier to pirate and distribute a single EXE > file than to copy the whole CD-ROM, so a different EXE wouldn't > protect id Software for a long time. I don't think it would be difficult for iD to do separate compiles (perhaps with a -DSHAREWARE for the shareware version) that actually makes two very different exes. But the discussion is futile anyway: pirates will circumvent anything iD can throw at them, so iD are probably better off directing their energy towards the game engine. > Of course, I assume > that the authors of the editors include more than one test which > checks if the user has a registered version of the game. Can't see the problem here. If there is just a single test the author of the editor can't take responsibility for modified versions of the editor. Again, pirates circumvent just about anything, and wasting time on copy-protection is useless. Just make the test so an ordinary user wouldn't be able to circumvent it. Zonk, Uffe. [uphfe] uffefl@diku.dk From quake-editing-owner@nvg.unit.no Mon Mar 18 23:13 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id XAA12113 for ; Mon, 18 Mar 1996 23:13:57 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id XAA26168 for quake-editing-outgoing; Mon, 18 Mar 1996 23:03:58 +0100 Received: from ws01 ([147.51.55.53]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id XAA26163 for ; Mon, 18 Mar 1996 23:03:43 +0100 Date: Mon, 18 Mar 96 17:07:29 EST Message-Id: <9603181707.AA02556@WS055052> Mime-Version: 1.0 From: "Michael G. Clawson" X-Sender: To: quake-editing@nvg.unit.no Subject: Re: Legal stuff (was Re: WAD conversion sketch) X-Mailer: Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 20 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 761 In reply to 18 Mar message from quake-editing@nvg.unit.no: >> It has always >> been possible to create a replacement IWAD because id >> decided to distribute the same EXE as shareware, >> registered, and commercial. The qtest1 seems to indicate >> that this will not change, which is a bad thing. >I'm not sure if it is a bad thing. Maintaining two different >EXE's would mean more work for id Software (creating the two >versions, supporting them, etc.). Allow me to add to that: It may or may not be the best way of doing business, but I would hardly call giving people the benefit of the doubt by simply asking programmers to not make their tools work with the shareware version of doom a 'bad thing'. I rather admire that policy. It's refreshing. From quake-editing-owner@nvg.unit.no Mon Mar 18 23:37 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id XAA12125 for ; Mon, 18 Mar 1996 23:37:50 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id XAA26673 for quake-editing-outgoing; Mon, 18 Mar 1996 23:30:14 +0100 Received: from msuvx2.memphis.edu (msuvx2.memphis.edu [141.225.1.3]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id XAA26667 for ; Mon, 18 Mar 1996 23:30:04 +0100 Received: from EviLiNuX.memphis.edu (wok-11.memphis.edu) by MSUVX2.MEMPHIS.EDU (PMDF V5.0-3 #7188) id <01I2HO5HDM1S98760B@MSUVX2.MEMPHIS.EDU> for quake-editing@nvg.unit.no; Mon, 18 Mar 1996 16:30:04 -0600 (CST) Date: Mon, 18 Mar 1996 16:31:07 -0600 (CST) From: Jimmy Sieben Subject: Re: WAD Conversion sketch In-reply-to: <199603181253.HAA24996@minerva.phyast.pitt.edu> To: quake-editing@nvg.unit.no Message-id: MIME-version: 1.0 Content-transfer-encoding: 7BIT Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 24 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 1328 > On Sat, 16 Mar 1996, Bernd Kreimeier wrote: > > Regarding the legal issues: > > Maybe iD's licence doesn't explicitly forbid the creation/distribution of > add-on levels for Quake, but personally I feel that we should respect > iD's work and not bring out any fully-fledged editor before the > registered version becomes available. But perhaps I'm alone in this? I think editors should be released; the 3D design interface would need some extensive end-user testing. The file formats and graphics are changing, as stated by several id employees, so there is no risk of shareware compatibility there. I cannot see any reason not to release an editor, technical/programming issues aside. +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | _______ _ _ _____ IRC: EvlGenius | | |______ \ / | | Mail: l-sieben@memphis.edu | | |______ \/ __|__ |_____ | | ______ _______ __ _ _____ _ _ _______ DOOM Player, Programmer, | | | ____ |______ | \ | | | | |______ IRC hacker extraordinaire | | |_____| |______ | \_| __|__ |_____| ______| Bow down to The Genius | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ From quake-editing-owner@nvg.unit.no Tue Mar 19 12:53 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id MAA22047 for ; Tue, 19 Mar 1996 12:53:29 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id MAA04100 for quake-editing-outgoing; Tue, 19 Mar 1996 12:41:48 +0100 Received: from gallup.cia-g.com (root@gallup.cia-g.com [206.206.162.10]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id MAA04095 for ; Tue, 19 Mar 1996 12:41:42 +0100 Received: from sietch.bloomington.IN.US (shooter.bluemarble.net [199.18.207.25]) by gallup.cia-g.com (8.6.11/8.6.9) with SMTP id EAA16192 for ; Tue, 19 Mar 1996 04:42:12 -0700 Date: Tue, 19 Mar 1996 04:42:12 -0700 Message-Id: <199603191142.EAA16192@gallup.cia-g.com> Subject: Howdy Dudey Time. [RANDOM TITLE] From: "Muad'Dib" To: quake-editing@nvg.unit.no Recieved: by WWIV NET36 03/19 06:43 Internet ->1 for Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 768 X-Lines: 18 Status: RO Responding :* Re: WAD Conversion sketch ************ > Maybe iD's licence doesn't explicitly forbid the creation/distribution > of > add-on levels for Quake, but personally I feel that we should respect > iD's work and not bring out any fully-fledged editor before the > registered version becomes available. But perhaps I'm alone in this? Way back when ID was telling us all this hype, one of the things they bragged about was that someone independant would probably release a level editor in no time. I suspect they don't care. 'sides, on IRC someone asked Barrett Alexander and he said he didn't know of any policy, so I believe tehy probably haven't given it too much thought. Muad'Dib The Mouse a.k.a. Greg Alexander From quake-editing-owner@nvg.unit.no Tue Mar 19 14:54 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id OAA23551 for ; Tue, 19 Mar 1996 14:54:34 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id OAA06149 for quake-editing-outgoing; Tue, 19 Mar 1996 14:45:30 +0100 Received: from conline.com (root@conline.com [204.96.7.68]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id OAA06141 for ; Tue, 19 Mar 1996 14:45:25 +0100 Received: from dal1-13.conline.com (Muddy1@dal1-13.conline.com [204.96.7.13]) by conline.com (8.6.12/8.6.12) with SMTP id HAA01842; Tue, 19 Mar 1996 07:46:34 -0600 Message-Id: <199603191346.HAA01842@conline.com> X-Sender: jelson@conline.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Date: Tue, 19 Mar 1996 07:45:30 -0600 To: quake-editing@nvg.unit.no, quake-editing@nvg.unit.no From: jelson@l1.conline.com (Jim Elson) Subject: Re: Legal issues (was: WAD conversion sketch) Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 26 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 1190 Uffe Friis Lichtenberg wrote: >I can't see any harm in the discussion or release of viewers/small >editors/file format converters/etc. as long as they are not "marketed" as >Quake-editors. > >BTW: until a Quake non-test version comes out this is all we have to play >around with anyway, so there's no need trying to stop us now :) Quite. However, there is another factor in this equation: Exactly WHY did id release the test in the form they did? (monsters, etc.) It's not as if they are stupid enough to believe that no one would try to implement them or that they could care less what we could do with it. Of course, I don't explain a candid answer to this from them, but it is an interesting question and the possibilities might shed some light on id's plans concerning editors, utilities, etc. --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 quake-editing-owner@nvg.unit.no Tue Mar 19 15:17 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 PAA25769 for ; Tue, 19 Mar 1996 15:17:41 +0100 (MET) Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with SMTP id PAA16901 for ; Tue, 19 Mar 1996 15:18:44 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id PAA06592 for quake-editing-outgoing; Tue, 19 Mar 1996 15:09:39 +0100 Received: from pelican.lannion.cnet.fr (pelican.lannion.cnet.fr [192.44.58.25]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id JAA01442 for ; Tue, 19 Mar 1996 09:34:39 +0100 Relayed; 19 Mar 96 09:34:10+0100 X400-Received: by /PRMD=cnet/ADMD=atlas/C=fr/; Relayed; 19 Mar 96 09:34:10+0100 Date: 19 Mar 96 09:34:10+0100 From: Olivier To: quake-editing@nvg.unit.no Subject: WinTex 4.3 and Quake specs Message-ID: <9603190833.1C28B8@lat1192.lannion.cnet.fr> X-Mailer: E-Mail 1.6 Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 723 X-Lines: 20 Status: RO About WinTex: I am currently addapting WinTex 4.2 to Quake, and that gives WinTex 4.3. This tool is intended as an HELP for nodebuilder and level builder programmers. It is not an editor (I don't have enough time). It will display and let you check all the structures in the Quake BSP levels. Texture display, wireframe view of the levels, (surfaces, BSP tree, BSP leaves) already work, but the planes and visilists are missing. I get 3 FPS with my wireframe viewer under windoze 3.1. Slower than Quake! :-) About Specs: The Quake specs 3.1 should be released in a few days, they will include more info about the BSP levels and the MDL. All the MDL is clarified now, including the lightnormalindexes. From quake-editing-owner@nvg.unit.no Tue Mar 19 18:46 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id SAA28180 for ; Tue, 19 Mar 1996 18:46:09 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id SAA10965 for quake-editing-outgoing; Tue, 19 Mar 1996 18:34:59 +0100 Received: from satan.idsoftware.com (satan.idsoftware.com [192.246.40.37]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id SAA10955 for ; Tue, 19 Mar 1996 18:34:48 +0100 Received: by satan.idsoftware.com; id AA03088; Tue, 19 Mar 1996 11:33:26 -0600 Message-Id: <1.5.4b11.32.19960317000313.00ad9d88@idsoftware.com> X-Sender: shawng@idsoftware.com X-Mailer: Windows Eudora Light Version 1.5.4b11 (32) Mime-Version: 1.0 Date: Sat, 16 Mar 1996 18:03:13 -0600 To: quake-editing@nvg.unit.no From: Shawn Green Subject: Re: Legal issues (was: WAD conversion sketch) Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 22 Status: RO Content-Type: text/plain; charset="us-ascii" Content-Length: 841 At 07:45 AM 3/19/96 -0600, you wrote: >However, there is another factor in this equation: Exactly WHY did id release >the test in the form they did? (monsters, etc.) It's not as if they are >stupid enough to believe that no one would try to implement them or that >they could care less what we could do with it. Of course, I don't explain >a candid answer to this from them, but it is an interesting question and >the possibilities might shed some light on id's plans concerning editors, >utilities, etc. We didn't release it for any other reason than testing the technology. Had we thought about it, we would have removed the models and other items that were not in the game from the pak file. -Shawn Green Project Manager id Software Official release date for everything - "When it's done!" That's the only one you'll ever get. From quake-editing-owner@nvg.unit.no Wed Mar 20 17:40 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id RAA07710 for ; Wed, 20 Mar 1996 17:40:22 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id RAA32093 for quake-editing-outgoing; Wed, 20 Mar 1996 17:30:00 +0100 Received: from Walden.MO.NET (root@walden.mo.net [199.250.196.5]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id RAA32081 for ; Wed, 20 Mar 1996 17:29:51 +0100 Received: (from uutss@localhost) by Walden.MO.NET (8.6.12/8.6.10) with UUCP id KAA25132 for quake-editing@nvg.unit.no; Wed, 20 Mar 1996 10:21:20 -0600 Received: by tss.survivor.org (1.65/waf) via UUCP; Wed, 20 Mar 96 10:00:31 CST for quake-editing@nvg.unit.no Received: (from chronomancer@localhost) by sfi.survivor.org (8.6.9/8.6.9) id JAA05830; Wed, 20 Mar 1996 09:25:48 -0600 Date: Wed, 20 Mar 1996 09:25:48 -0600 From: Herschel Giansiracusa Subject: Re: Legal issues (was: WAD conversion sketch) To: quake-editing@nvg.unit.no In-Reply-To: <199603191346.HAA01842@conline.com> Message-ID: MIME-Version: 1.0 Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no X-Lines: 21 Status: RO Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 984 On Tue, 19 Mar 1996, Jim Elson wrote: > However, there is another factor in this equation: Exactly WHY did id release > the test in the form they did? (monsters, etc.) It's not as if they are > stupid enough to believe that no one would try to implement them or that > they could care less what we could do with it. Of course, I don't explain > a candid answer to this from them, but it is an interesting question and > the possibilities might shed some light on id's plans concerning editors, > utilities, etc. It seems like id wanted to get some "Quake hacking" going to increase to popularity of the Qtest1, so they made it easy for us hackers to get started by doing that thing with the monsters... Just think, without that now famous "fun with hex" post on doom-editing a couple days after the release of Qtest1, decoding the PAK and all of it's sub-formats would've progressed much slower. -Chronomancer chronomancer@sfi.survivor.org From quake-editing-owner@nvg.unit.no Wed Mar 20 21:11 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id VAA09754 for ; Wed, 20 Mar 1996 21:11:46 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id VAA05282 for quake-editing-outgoing; Wed, 20 Mar 1996 21:10:01 +0100 Received: from megatek.com (megatek.com [204.30.207.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id VAA05270 for ; Wed, 20 Mar 1996 21:09:55 +0100 Received: from fuzz.megatek (fuzz.megatek.com [192.43.236.81]) by megatek.com (8.6.9/8.6.6) with SMTP id MAA28376 for ; Wed, 20 Mar 1996 12:10:27 -0800 Received: by fuzz.megatek (5.0/SMI-SVR4) id AA22152; Wed, 20 Mar 1996 12:10:25 +0800 Date: Wed, 20 Mar 1996 12:10:25 +0800 From: etherton@megatek.com (David Etherton) Message-Id: <9603202010.AA22152@fuzz.megatek> To: quake-editing@nvg.unit.no Subject: Visibility Lists Revisited Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1400 X-Lines: 31 Status: RO [Olivier has probably already figured this out and written it up in the specs, but just in case...] It looks like the visibility lists are RLE compressed. The encoding is very simple: if a byte is nonzero, it contains the visibility data for the next eight leaves. If it is zero, the next byte contains a skip count. This skip count (probably) means that the next (count<<3) leaves are not visible. I guess that it means they're *not* visible because I see lots of (consecutive) 0xFF's in the visibility lists of test1.bsp. It seems like RLE compressing 0xFF's as well as 0x00's would work well, but who am I to question to id gods? :) I'm reasonably sure that I'm on the right track, because every visibility list in test1.bsp "unpacks" to 57 bytes, or 456 leaves. While there are 494 leaves on test1.bsp, leaves 452 and onward all have a visibility offset of -1. Not sure whether that means "all visible" or "none visible" yet. [Note floor((452+7)>>3)==57] [I also just ran test2.bsp through, and it sees them all as 118 bytes long, and the first leaf with a visoffs of -1 is 941] I'm still not sure whether the bit test for testing individual unpacked visibility bytes is (1<<(offset&7)) or (128>>(offset&7)); my usual sanity check of "any leaf should be able to see itself" still doesn't work consistently for either method. I hope this furthers the Great Hacking Effort... -dce From quake-editing-owner@nvg.unit.no Wed Mar 20 22:10 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id WAA10152 for ; Wed, 20 Mar 1996 22:10:14 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id WAA06137 for quake-editing-outgoing; Wed, 20 Mar 1996 22:00:12 +0100 Received: from gallup.cia-g.com (root@gallup.cia-g.com [206.206.162.10]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id WAA06128 for ; Wed, 20 Mar 1996 22:00:06 +0100 Received: from sietch.bloomington.IN.US (shooter.bluemarble.net [199.18.207.25]) by gallup.cia-g.com (8.6.11/8.6.9) with SMTP id OAA25809 for ; Wed, 20 Mar 1996 14:01:00 -0700 Date: Wed, 20 Mar 1996 14:01:00 -0700 Message-Id: <199603202101.OAA25809@gallup.cia-g.com> Subject: just another brick in the wall.. [RANDOM TITLE] From: "Muad'Dib" To: quake-editing@nvg.unit.no Recieved: by WWIV NET36 03/19 15:56 Internet ->1 for Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1103 X-Lines: 24 Status: RO Responding :* One EXE for all? (was Re: Legal stuff) ************ > It could be made sufficently hard to remove if it was a key that was > spread throughout the WAD and was used to construct some weird > checkdigit at the end. It could remain undocumented, so nobody could > remove it and the EXE would be the only thing that had to know how to > look for it. > > That way everyone could make whatever editor they wanted, and if you > didn't have the registered WAD, then you would not be able to play > the add-on levels. In fact, the editor-designers wouldn't have to worry > about checking for registered versions of the game at all, because the > EXE would handle it. This is a thingy for ID to do. They will figure out how they wanna do that. I don't think we need to worry. As EvilGenius or someone said, we're not making something Shareware compatable, we're making something test compatable. It will almost definitely not work with shareware, so when there is a registered out, it'll be updated for that. Muad'Dib The Mouse a.k.a. Greg Alexander From quake-editing-owner@nvg.unit.no Thu Mar 21 09:09 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id JAA15090 for ; Thu, 21 Mar 1996 09:09:40 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id IAA13521 for quake-editing-outgoing; Thu, 21 Mar 1996 08:14:19 +0100 Received: from megatek.com (megatek.com [204.30.207.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id IAA13494 for ; Thu, 21 Mar 1996 08:12:51 +0100 Received: from fuzz.megatek (fuzz.megatek.com [192.43.236.81]) by megatek.com (8.6.9/8.6.6) with SMTP id XAA13692 for ; Wed, 20 Mar 1996 23:13:21 -0800 Received: by fuzz.megatek (5.0/SMI-SVR4) id AA22306; Wed, 20 Mar 1996 23:13:19 +0800 Date: Wed, 20 Mar 1996 23:13:19 +0800 From: etherton@megatek.com (David Etherton) Message-Id: <9603210713.AA22306@fuzz.megatek> To: quake-editing@nvg.unit.no Subject: More Visibility Progress Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 966 X-Lines: 30 Status: RO Okay, here's what I've been able to nail down. - If a leaf's visibility offset is -1, this means that it can see all other leaves. Likewise, all other leaves can see this one. I determined this by setting every leaf's offset to -1 in test1.bsp and then noting that the reverse BSP draw now showed the entire level (and the framerate dropped even more). - The visibility list is 1-based, not 0-based. Furthermore, individual bits are encoded using (1<<((offset-1)&7). With this new formula, I was able to finally verify that every leaf's visibility list does indeed contain its own leaf. So, in other words, the visibility list 10 ff 00 03 7f "unpacks" to 10 ff 00 00 00 7f Leaf 5 is visible because 0x10 & (1<<((5-1)&7)) is true. Leaves 9-16 are visible, leaves 1,2,3,4,6,7,8,17-40 are not visible, and leaves 41-47 are visible. Leaf 48 is not visible either. (It's almost midnight here, hope I didn't screw that up). Hope this helps, -Dave From quake-editing-owner@nvg.unit.no Thu Mar 21 10:37 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 KAA16150 for ; Thu, 21 Mar 1996 10:36:54 +0100 (MET) Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with SMTP id KAA26880 for ; Thu, 21 Mar 1996 10:37:54 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id KAA15644 for quake-editing-outgoing; Thu, 21 Mar 1996 10:31:58 +0100 Received: from pelican.lannion.cnet.fr (pelican.lannion.cnet.fr [192.44.58.25]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id KAA15635 for ; Thu, 21 Mar 1996 10:31:53 +0100 Relayed; 21 Mar 96 10:31:43+0100 X400-Received: by /PRMD=cnet/ADMD=atlas/C=fr/; Relayed; 21 Mar 96 10:31:43+0100 Date: 21 Mar 96 10:31:43+0100 From: Olivier To: quake-editing@nvg.unit.no Subject: RE: Visibility Lists Revisited Message-ID: <9603210930.3A28C4@lat1192.lannion.cnet.fr> X-Mailer: E-Mail 1.6 Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1593 X-Lines: 45 Status: RO >Olivier has probably already figured this out and written it up in > the specs, but just in case... Yeah, but I found out only this morning (because I wasted time trying to check if it was related to BSP trees, as experiments seems to show) You're first to claim. >It looks like the visibility lists are RLE compressed. I confirm this. My explanation differs a bit though. >It seems like RLE compressing 0xFF's as well as 0x00's would work >well, but who am I to question to id gods? :) I think they DO NOT DECOMPRESS the visilists in memory. The WinTex visibility list viewer just decodes the visilists each time it's needed. If you test for zero, and unpack on the fly, you go faster than if you read the unpacked visibility list, even from the processor L2 cache. BTW, that's would explain why only ZERO is tested, two tests would slow down the processor too much. >I hope this furthers the Great Hacking Effort... Sure justify a mention in upcoming specs 3.1. Nice to see I'm not the only one hacking levels to death. Well, now the spec is complete. I just have to correct it and publish. --------------------------- BTW, anyone has already swam into acid? it hurts. less than lava, though. Leaf code for acid is -4 Another trick: if you put a leaf code of -3 (water) in a leaf, then the player inside can swim, but his vision is blurred. whereas players outside the leaf can see him as usual, not blurred. Now that's a deadly deathmatch trick :-) I love that concept of water appearing by surprise in the middle of nowhere. Olivier From quake-editing-owner@nvg.unit.no Sat Mar 23 20:56 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 UAA28490 for ; Sat, 23 Mar 1996 20:56:13 +0100 (MET) Received: from sabre-wulf.nvg.unit.no (sabre-wulf.nvg.unit.no [129.241.161.9]) by olymp.informatik.uni-bonn.de (8.7.1/8.6.12) with SMTP id UAA15741 for ; Sat, 23 Mar 1996 20:57:14 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id FAA08355 for quake-editing-outgoing; Mon, 18 Mar 1996 05:47:31 +0100 Received: from netcom9.netcom.com (etherton@netcom9.netcom.com [192.100.81.119]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id FAA08350 for ; Mon, 18 Mar 1996 05:47:28 +0100 Received: by netcom9.netcom.com (8.6.13/Netcom) id UAA10016; Sun, 17 Mar 1996 20:47:17 -0800 Date: Sun, 17 Mar 1996 20:47:17 -0800 From: etherton@netcom.com (David Etherton) Message-Id: <199603180447.UAA10016@netcom9.netcom.com> To: quake-editing@nvg.unit.no Subject: Rendering Quake surfaces Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 2289 Status: RO X-Lines: 51 [Please forgive me if this is asked a lot, I can't get through to the mail archives on http://www.nero.uni-bonn.de/~dn/qd/qd_welcome.html right now] Like just about everybody else around here, I've been playing around with trying to render the Quake levels. The Quake specs (3.0) have proved invaluable. First, in the List of Edges, if the sign bit of the edge is set, are we supposed to look at edge ~i or -i? (Nodes use ~i to mark leaves according to both the spec and my own experience). For the List of Edges, though, neither ~i nor -i seem to work particularly well, although -i seems to work slightly better. I can traverse the BSP tree and find the leaf containing my camera position correctly, so I know I've got the basics right. However, when I try to render, I find that the list of surfaces often tells me to (say) render surface 7 three times in a row, and that it's got 30 edges in the surface. Surfaces with small numbers of edges seem to "connect" together well (ie the end vertex of one edge is the start vertex of the next, and it forms a closed figure). Some surfaces with larger numbers of edges seem to form closed figures if you sort the edges after reading them in, but surfaces with 16 or more edges seem to not form closed figures. I can't imagine a fast renderer wanting to deal with anything larger than a tri or a quad, so I'm suspicious of anything with more than four edges. Combined with my experience with surfaces with large numbers of edges having nonsensical edge lists, I wonder if we're supposed to interpret the edge count differently if it's above a certain value. Also, why would the list of surfaces explicitly tell me to render the same surface two or three times in a row? I haven't done an exhaustive check, but it appears that every time a surface is supposed to render several times in a row, it usually also has a large number of edges. Am I totally off in the weeds here or is anybody else fighting the same things I am? -David Etherton ps. For what it's worth, I have been able to parse and render the models perfectly; either a Z-buffer or a bucket Z-sort seems to produce good results; the latter has some slight defects (ever seen a PlayStation?) but is *much* faster on both my PC and my SparcStation From quake-editing-owner@nvg.unit.no Sun Mar 24 19:00 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id TAA08418 for ; Sun, 24 Mar 1996 19:00:07 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id SAA05062 for quake-editing-outgoing; Sun, 24 Mar 1996 18:36:38 +0100 Received: from gallup.cia-g.com (root@gallup.cia-g.com [206.206.162.10]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id SAA05057 for ; Sun, 24 Mar 1996 18:36:34 +0100 Received: from sietch.bloomington.IN.US (shooter.bluemarble.net [199.18.207.25]) by gallup.cia-g.com (8.6.11/8.6.9) with SMTP id KAA24256 for ; Sun, 24 Mar 1996 10:38:02 -0700 Date: Sun, 24 Mar 1996 10:38:02 -0700 Message-Id: <199603241738.KAA24256@gallup.cia-g.com> Subject: Uwouldn'tHoldAThingLikeSanityAgainstAGuy? [RT] From: "Muad'Dib" To: quake-editing@nvg.unit.no Recieved: by WWIV NET36 03/23 18:49 Internet ->1 for Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 917 Status: RO X-Lines: 19 Responding :* Re: WAD Conversion sketch ************ > I agree. I was upset to see complete levels and mdl files uploaded > to ftp and net sites. I think the level/model editors should not > work with the shareware release, unless id gives an ok. I will > most likely hold back the next version of meddle because of this. This is just plain silly. It DOESN'T work with the shareware release. It probably WON'T work with the shareware release. This is just a test version. Goodness, people are scared of ID software when whatever you do can only gain them more business. One of the few things I really hate about Quake right now is that it doesn't have all of the specs and stuff they promised. If it looks like there's no hope for getting an editor unless it's from ID, quite a few people will probably become disgruntled. Muad'Dib The Mouse a.k.a. Greg Alexander From quake-editing-owner@nvg.unit.no Sun Mar 24 20:06 MET 1996 Received: from sabre-wulf.nvg.unit.no (sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id UAA08876 for ; Sun, 24 Mar 1996 20:06:51 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id TAA00558 for quake-editing-outgoing; Sun, 24 Mar 1996 19:47:25 +0100 Received: from runix.runit.sintef.no (runix.runit.sintef.no [129.241.1.5]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id TAA00547 for ; Sun, 24 Mar 1996 19:47:22 +0100 Received: from minerva.phyast.pitt.edu by runix.runit.sintef.no with SMTP (PP); Sun, 24 Mar 1996 19:47:13 +0100 Received: (brian@localhost) by minerva.phyast.pitt.edu (8.6.10/8.6.5) id NAA16372 for quake-editing@nvg.unit.no; Sun, 24 Mar 1996 13:42:07 -0500 From: "Brian K. Martin" Message-Id: <199603241842.NAA16372@minerva.phyast.pitt.edu> Subject: Re: Uwouldn'tHoldAThingLikeSanityAgainstAGuy? [RT] To: quake-editing@nvg.unit.no Date: Sun, 24 Mar 1996 13:42:07 -0500 (EST) In-Reply-To: <199603241738.KAA24256@gallup.cia-g.com> from "Muad'Dib" at Mar 24, 96 10:38:02 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Status: RO X-Lines: 27 Content-Type: text/plain; charset="US-ASCII" Content-Length: 1157 > > Responding :* Re: WAD Conversion sketch > ************ > > > I agree. I was upset to see complete levels and mdl files uploaded > > to ftp and net sites. I think the level/model editors should not > > work with the shareware release, unless id gives an ok. I will > > most likely hold back the next version of meddle because of this. > > This is just plain silly. It DOESN'T work with the shareware release. It > probably WON'T work with the shareware release. This is just a test version. Are you so sure the models will be in a completely different format in the shareware or final release? > Goodness, people are scared of ID software when whatever you do can only gain > them more business. One of the few things I really hate about Quake right now > is that it doesn't have all of the specs and stuff they promised. If it looks > like there's no hope for getting an editor unless it's from ID, quite a few > people will probably become disgruntled. > Uh, I think the quake specs are almost entirely complete. You have to give people time to write things. (i mean the new quake specs, olivier, did you release these yet?) From quake-editing-owner@nvg.unit.no Mon Mar 25 01:00 MET 1996 Received: from sabre-wulf.nvg.unit.no (sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id BAA11023 for ; Mon, 25 Mar 1996 01:00:24 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id AAA04823 for quake-editing-outgoing; Mon, 25 Mar 1996 00:59:04 +0100 Received: from relay-4.mail.demon.net (relay-4.mail.demon.net [158.152.1.108]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id AAA04818 for ; Mon, 25 Mar 1996 00:59:01 +0100 Received: from post.demon.co.uk ([158.152.1.72]) by relay-4.mail.demon.net id aa16289; 24 Mar 96 23:57 GMT Received: from tsys.demon.co.uk ([158.152.159.87]) by relay-3.mail.demon.net id ac29848; 24 Mar 96 23:49 GMT Date: Sun, 24 Mar 96 23:31:27 GMT Message-ID: <11870@tsys.demon.co.uk> From: Tom Wheeley Organization: City Zen FM To: quake-editing@nvg.unit.no Subject: Descriptions of Quake Utilities for a faq file X-Mailer: Demon Internet Simple News v1.30 Lines: 41 X-Sig-By: Tomsystems Quote v1.2. (c)1996 Tom Wheeley, tomw@tsys.demon.co.uk Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1318 Status: RO X-Lines: 43 Those of you who are on rgcq-support will have seen my skeletal FAQ file for the Quake Test 1. Anyway, there is a section on quake utilities, and I think it will be best if people describe their own. Rationale: a) I couldn't possibly download every utility b) I may miss an important facility c) Personal bias against methodology etc (eg, I hated DeePs ASCII screens) There are a couple of rules: a) Not too long / imprecise b) No deriding of other peoples utilities c) your utility must be good (ie, not the dodgy UNPACK.C posted to rgcqe) Here is a section from the index: 6 - Quake Utilities 6.1 PAK file utilities 6.2 Level editors (BSP files) 6.3 Model editors (MDL files) 6.4 Sprite editors (SPR files) 6.5 The QEU project And a sample entry: 6.1 PAK file utilities 6.1.1 XPAK XPAK allows complete manipulation of PAK files; listing, extracting adding, creating, updating and the renaming of entries. DOS only, command line driven. Filename: xpak036.zip It is probably best to mail your descriptions to me preferably with this Subject: line, or one with `quakefaq' in it. :) Thankyou in advance for your contributions. .splitbung -- * TQ 1.0 * 101 Weapons for Quake 78. The 2" long kitchen knife. From quake-editing-owner@nvg.unit.no Mon Mar 25 11:45 MET 1996 Received: from sabre-wulf.nvg.unit.no (sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id LAA19209 for ; Mon, 25 Mar 1996 11:45:16 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id LAA12101 for quake-editing-outgoing; Mon, 25 Mar 1996 11:39:08 +0100 Received: from odin.diku.dk (root@odin.diku.dk [130.225.96.221]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id LAA12094 for ; Mon, 25 Mar 1996 11:39:04 +0100 Received: from embla.diku.dk (uffefl@embla.diku.dk [130.225.96.229]) by odin.diku.dk (8.6.12/8.6.12) with ESMTP id LAA09137 for ; Mon, 25 Mar 1996 11:38:59 +0100 Received: (uffefl@localhost) by embla.diku.dk (8.6.12/8.6.12) id LAA13129; Mon, 25 Mar 1996 11:38:57 +0100 Date: Mon, 25 Mar 1996 11:38:57 +0100 (MET) From: Uffe Friis Lichtenberg To: quake-editing@nvg.unit.no Subject: Re: WAD Conversion sketch In-Reply-To: <199603181335.OAA07387@colossus.nero.uni-bonn.de> Message-ID: MIME-Version: 1.0 Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Status: RO X-Lines: 62 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 2646 On Mon, 18 Mar 1996, Bernd Kreimeier wrote: > >From: Uffe Friis Lichtenberg > > >we do need a 3D BSP tree > If I am not mistaken, you could simply copy the 2D BSP into > a matching 3D BSP, and convert the information from the old > NODES and SSECTORS. Think about it. I just tried creating a small example to prove my point, and somehow proved yours, hehe :) Anyway, it seems you are right: we could convert the SSEGS of Doom (convex structures) to Quake leaves because there would only be 1 ceiling for each SSEG and only 1 floor. As long as the split-planes are chosen to be vertical (ie. normal=(x,0,z)) -- as they would be if converted from Doom -- the floors and ceilings would be the last planes to be insert into the BSP tree and thus not intersect anything. > >the floors and ceilings are planes and have to be partitioned > You are perfectly right. In fact, this might be the most > difficult task to solve. It breaks down to creating closed > polygons from SECTORS and LINEDEFS for each floor (ceilings > will have the same partitions), and using the 2D BSP NODES > info (namely the partition lines) to split the SECTORS' > polygon into the Leaf2D surfaces. I already added this > to the proposal. But couldn't the floor and ceiling surfaces be created using the convex information from the SSEG structure? (It's been awhile since I hacked Doom, so my terminology might be off...) > >misc. remarks on conversion, DXF, intermediate file formats > All very true. However, I am skeptical that any file format > not done by id will ever be agreed upon. Anybody remember the > porposal by Tom Neff (WAD Interchange Format)? Yeah, I remember that one. But it didn't have quite the same idea as one for Quake -- ie. letting us distribute levels... But I think you are right, any file format not from id won't survive long :) Anyway, id would probably analyse our fileformat and make some small changes just to tease us... >;) (Things are bound to change with every version up until registered, so why bother anyway?) > >>The WAD will have to have only one floor/ceiling per xy plane, > >>i.e. the DOOM world geometry restrictions > >But where do you find wads that fulfil this requirement? > Hmmm? Any WAD that can be used with DOOM does :-). Only one floor/ceiling per xy plane: disallow multiple sectors to have floors/ceilings with the same z-coordinates... I think I misunderstood you. You mean that each sector only has one floor/ceiling xy plane, right? (Which then also applies to SSEGs, which hopefully could be our path through conversion hell.) Zonk, Uffe. [uphfe] uffefl@diku.dk From quake-editing-owner@nvg.unit.no Mon Mar 25 11:46 MET 1996 Received: from sabre-wulf.nvg.unit.no (sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id LAA19216 for ; Mon, 25 Mar 1996 11:46:19 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id LAA12199 for quake-editing-outgoing; Mon, 25 Mar 1996 11:44:48 +0100 Received: from odin.diku.dk (root@odin.diku.dk [130.225.96.221]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id LAA12194 for ; Mon, 25 Mar 1996 11:44:47 +0100 Received: from embla.diku.dk (uffefl@embla.diku.dk [130.225.96.229]) by odin.diku.dk (8.6.12/8.6.12) with ESMTP id LAA09335 for ; Mon, 25 Mar 1996 11:44:44 +0100 Received: (uffefl@localhost) by embla.diku.dk (8.6.12/8.6.12) id LAA13968; Mon, 25 Mar 1996 11:44:41 +0100 Date: Mon, 25 Mar 1996 11:44:41 +0100 (MET) From: Uffe Friis Lichtenberg To: quake-editing@nvg.unit.no Subject: Re: Legal issues (was: WAD conversion sketch) In-Reply-To: <1.5.4b11.32.19960317000313.00ad9d88@idsoftware.com> Message-ID: MIME-Version: 1.0 Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Status: RO X-Lines: 28 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 726 On Sat, 16 Mar 1996, Shawn Green wrote: > We didn't release it for any other reason than testing the technology. Had > we thought about it, we would have removed the models and other items that > were not in the game from the pak file. Which is exactly what id has been saying from the start... It can't be _that_ hard to read the .txt's. > -Shawn Green > Project Manager > id Software See? Anyway, this doesn't clarify id's stand regarding the continuous hacking/editing of the Quake Test 1 release. Where exactly will they draw the line? > Official release date for everything - "When it's done!" > That's the only one you'll ever get. Yeah, yeah. Heard that one before :) Zonk, Uffe. [uphfe] uffefl@diku.dk From quake-editing-owner@nvg.unit.no Mon Mar 25 12:11 MET 1996 Received: from sabre-wulf.nvg.unit.no (sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id MAA20358 for ; Mon, 25 Mar 1996 12:11:15 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id MAA12569 for quake-editing-outgoing; Mon, 25 Mar 1996 12:02:10 +0100 Received: from pelican.lannion.cnet.fr (pelican.lannion.cnet.fr [192.44.58.25]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id MAA12564 for ; Mon, 25 Mar 1996 12:02:05 +0100 Relayed; 25 Mar 96 12:02:01+0100 X400-Received: by /PRMD=cnet/ADMD=atlas/C=fr/; Relayed; 25 Mar 96 12:02:01+0100 Date: 25 Mar 96 12:02:01+0100 From: Olivier Montanuy To: quake-editing@nvg.unit.no Subject: RE: Descriptions of Quake Utilities for a faq file Message-ID: <9603251101.123BE4@lat1192.lannion.cnet.fr> X-Mailer: E-Mail 1.6 Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 332 Status: RO X-Lines: 18 Hello again, I forgot to mention a detail, about WinTex 4.3 (for Quake) My name is Olivier Montanuy, and my personnal e-mail is 100625.2622@compuserve.com (This message comes from my work address, please do not publish this address montanuy@cnet.fr, I can't handle Quake related mails here). Regards, Olivier From quake-editing-owner@nvg.unit.no Tue Mar 26 00:10 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id AAA27622 for ; Tue, 26 Mar 1996 00:10:06 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id AAA24614 for quake-editing-outgoing; Tue, 26 Mar 1996 00:02:32 +0100 Received: from lubricant.free.org (smap@lubricant.free.org [199.3.242.5]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id AAA24609 for ; Tue, 26 Mar 1996 00:02:28 +0100 Received: (from smap@localhost) by lubricant.free.org (8.7.3/8.6.9) id RAA03210 for ; Mon, 25 Mar 1996 17:00:39 -0600 (CST) Received: from ppp001.free.org(199.3.242.32) by lubricant.free.org via smap (V1.3) id sma003198; Mon Mar 25 17:00:08 1996 Received: by ppp001.free.org with Microsoft Mail id <01BB1A6C.CBC201A0@ppp001.free.org>; Mon, 25 Mar 1996 17:02:06 -0600 X-Authentication-Warning: lubricant.free.org: smap set sender to using -f Message-ID: <01BB1A6C.CBC201A0@ppp001.free.org> From: Stephen Crowley To: "'Quake Developers'" Subject: List of entity classnames Date: Mon, 25 Mar 1996 17:01:03 -0600 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Status: RO X-Lines: 13 Content-Type: text/plain; charset="us-ascii" Content-Length: 503 I hope this is not off topic, but I was wondering if anyone has compiled = a list of all the entity classnames. So people can implement them in = map editors. I have about 36 listed so far. That's just by looking over = progs.dat a few times, I probably missed quite a few.=20 BTW, I'm having a little trouble understanding how to figure the = distance between (0,0,0) and a plane. If anyone could enlighten me on = this subject I be really grateful. Thanks, Stephen Crowley - stephenc@free.org From quake-editing-owner@nvg.unit.no Tue Mar 26 00:26 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id AAA27768 for ; Tue, 26 Mar 1996 00:26:39 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id AAA24900 for quake-editing-outgoing; Tue, 26 Mar 1996 00:19:29 +0100 Received: from megatek.com (megatek.com [204.30.207.2]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id AAA24894 for ; Tue, 26 Mar 1996 00:19:20 +0100 Received: from fuzz.megatek (fuzz.megatek.com [192.43.236.81]) by megatek.com (8.6.9/8.6.6) with SMTP id PAA01486 for ; Mon, 25 Mar 1996 15:19:55 -0800 Received: by fuzz.megatek (5.0/SMI-SVR4) id AA17245; Mon, 25 Mar 1996 15:19:54 +0800 From: etherton@megatek.com (David Etherton) Message-Id: <9603252319.AA17245@fuzz.megatek> Subject: Re: List of entity classnames To: quake-editing@nvg.unit.no Date: Mon, 25 Mar 1996 15:19:53 -0800 (PST) In-Reply-To: <01BB1A6C.CBC201A0@ppp001.free.org> from "Stephen Crowley" at Mar 25, 96 05:01:03 pm X-Mailer: ELM [version 2.4 PL21] Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 678 Status: RO X-Lines: 25 > BTW, I'm having a little trouble understanding how to figure the = > distance between (0,0,0) and a plane. If anyone could enlighten me on = > this subject I be really grateful. The plane equation is Ax + By + Cz + D = 0 where (x,y,z) is any point in 3-space, (A,B,C) is the unit normal (ie the vector perpendicular to the plane), and D is the distance in 3-space to the plane. Therefore, D is the value you desire. If you want the distance between two points, it's just sqrt(dx*dx + dy*dy + dz*dz) where (dx,dy,dz) is the vector difference of the two points. Hope this helps, -Dave -- David Etherton | Megatek Corporation | "Shop as usual, and avoid panic buying." From quake-editing-owner@nvg.unit.no Tue Mar 26 01:42 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id BAA28335 for ; Tue, 26 Mar 1996 01:42:51 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id BAA25946 for quake-editing-outgoing; Tue, 26 Mar 1996 01:35:15 +0100 Received: from mailgate.datametrics.com (mailgate.datametrics.com [198.242.57.11]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id BAA25940 for ; Tue, 26 Mar 1996 01:35:11 +0100 Received: from NetWare MHS (SMF71) by mailgate.datametrics.com via Connect2-SMTP 4.01.b29; Mon, 25 Mar 1996 19:32:25 -0500 Message-ID: <7337573181541273@mailgate.datametrics.com> Date: Mon, 25 Mar 1996 19:32:08 -0500 From: John Wakelin Organization: Datametrics Systems Corporation To: quake-editing@nvg.unit.no Subject: Re: List of entity classnames X-Mailer: Connect2-SMTP 4.01.b29 MHS to SMTP Gateway Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1131 Status: RO X-Lines: 29 > From: Stephen Crowley > I hope this is not off topic, but I was wondering if anyone has > compiled a list of all the entity classnames. So people can > implement them in map editors. I have about 36 listed so far. That's > just by looking over progs.dat a few times, I probably missed > quite a few. I have have this pretty much hammered out. I passed along my work in this area to Raphael and I believe it will be munged into the next release of the UQS. If anyone wants what I sent to him, speak up. It is nothing really amazing but it is a lot of work to hack out and you may want to save yourself from duplicating what I have already done. > BTW, I'm having a little trouble understanding how to figure the > distance between (0,0,0) and a plane. If anyone could enlighten me > on this subject I be really grateful. On this, I doubt that I will be of any help, sorry. Have a great day, johnw -= Sysop - The Netherworld =- -= Multi-player Gaming 703-471-6265 =- -= TeamTNT Member & DSC Datamaniac =- -= DECLARE SOFT WAR!!! =- From quake-editing-owner@nvg.unit.no Tue Mar 26 02:39 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id CAA28805 for ; Tue, 26 Mar 1996 02:39:54 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id CAA26796 for quake-editing-outgoing; Tue, 26 Mar 1996 02:32:21 +0100 Received: from lubricant.free.org (smap@lubricant.free.org [199.3.242.5]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id CAA26791 for ; Tue, 26 Mar 1996 02:32:17 +0100 Received: (from smap@localhost) by lubricant.free.org (8.7.3/8.6.9) id TAA07146 for ; Mon, 25 Mar 1996 19:30:37 -0600 (CST) Received: from ppp049.free.org(199.3.242.80) by lubricant.free.org via smap (V1.3) id sma007142; Mon Mar 25 19:30:33 1996 Received: by ppp049.free.org with Microsoft Mail id <01BB1A81.CDC0F960@ppp049.free.org>; Mon, 25 Mar 1996 19:32:28 -0600 X-Authentication-Warning: lubricant.free.org: smap set sender to using -f Message-ID: <01BB1A81.CDC0F960@ppp049.free.org> From: Stephen Crowley To: "'Quake Developers'" Subject: New info on surface.flips Date: Mon, 25 Mar 1996 19:31:28 -0600 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Status: RO X-Lines: 18 Content-Type: text/plain; charset="us-ascii" Content-Length: 696 Hey everyone, I've found some new info that probably needs to be put in = the next version of the Quake Specs. There is one more bit in = surface_t.flips that controls whether a texure is treated like a sky or = wavy like water. If bit4 of surface.flips is set and texture name begins with a "*" then = it is wavy like water, else it scrolls like a sky texture. Note: I tried changing "*water1" in test3 to "water1" and I get "Error: = Surface extent > 255". But I eventuall'y messed around and got the water = to look like a scrolling blob of weird textures. Very strange effect = indeed. I am sorry if this has already been discovered, but if it hasn't then = whoopee! :) Stephen Crowley From quake-editing-owner@nvg.unit.no Tue Mar 26 04:33 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id EAA29684 for ; Tue, 26 Mar 1996 04:33:44 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id EAA28385 for quake-editing-outgoing; Tue, 26 Mar 1996 04:26:04 +0100 Received: from relay-2.mail.demon.net (disperse.demon.co.uk [158.152.1.77]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id EAA28376 for ; Tue, 26 Mar 1996 04:25:56 +0100 Received: from post.demon.co.uk ([158.152.1.72]) by relay-2.mail.demon.net id ai08647; 26 Mar 96 3:24 GMT Received: from tsys.demon.co.uk ([158.152.159.87]) by relay-3.mail.demon.net id aa04064; 26 Mar 96 3:13 GMT Date: Tue, 26 Mar 96 03:07:12 GMT Message-ID: <11980@tsys.demon.co.uk> From: Tom Wheeley Organization: City Zen FM To: quake-editing@nvg.unit.no Subject: List of entity classnames X-Mailer: Demon Internet Simple News v1.30 Lines: 19 X-Sig-By: Tomsystems Quote v1.2. (c)1996 Tom Wheeley, tomw@tsys.demon.co.uk Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 790 Status: RO X-Lines: 22 In article <01BB1A6C.CBC201A0@ppp001.free.org> you write: > BTW, I'm having a little trouble understanding how to figure the = > distance between (0,0,0) and a plane. If anyone could enlighten me on = > this subject I be really grateful. Eh? How is your plane definition stored? id store their planes: r.n-hat = d (n-hat is an `n' with a `^' circonflex (sp?) on top.) Where `d' _is_ the distance from (0,0,0) and `r' is a general point, and `.' is the scalar product (x1*x2+y1*y2+z1*z2). n-hat is the unit-vector stored at the beginning of each plane entry in the BSP, it is followed by `d'. It is hard to help without knowing just what information you do have about your plane. .splitbung -- * TQ 1.0 * 101 Cheats for Quake 56. IDCOLA Makes you go suddenly very quiet From quake-editing-owner@nvg.unit.no Tue Mar 26 04:39 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id EAA29726 for ; Tue, 26 Mar 1996 04:39:29 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id EAA28455 for quake-editing-outgoing; Tue, 26 Mar 1996 04:32:42 +0100 Received: from lubricant.free.org (smap@lubricant.free.org [199.3.242.5]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id EAA28450 for ; Tue, 26 Mar 1996 04:32:39 +0100 Received: (from smap@localhost) by lubricant.free.org (8.7.3/8.6.9) id VAA09498 for ; Mon, 25 Mar 1996 21:31:00 -0600 (CST) Received: from ppp018.free.org(199.3.242.49) by lubricant.free.org via smap (V1.3) id sma009490; Mon Mar 25 21:30:36 1996 Received: by ppp018.free.org with Microsoft Mail id <01BB1A92.92D683E0@ppp018.free.org>; Mon, 25 Mar 1996 21:32:31 -0600 X-Authentication-Warning: lubricant.free.org: smap set sender to using -f Message-ID: <01BB1A92.92D683E0@ppp018.free.org> From: Stephen Crowley To: "'Quake Developers'" Subject: Note about surface.flips bit4 Date: Mon, 25 Mar 1996 21:31:39 -0600 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Status: RO X-Lines: 11 Content-Type: text/plain; charset="us-ascii" Content-Length: 510 Sorry about this, I should have put it in the last post. I've done some more experimenting and found that changing bit4 of then = surface.flips changes nothing in the game. But it seems the bit is set = just like I said in the last post. Even setting every surface in the = level with bit4 on does nothing. I have no idea why it is like this. I = have successfully changed the sky texure to the swirling water without = changing the bit. If anyone has any idea why it is like this then feel = free to share From quake-editing-owner@nvg.unit.no Tue Mar 26 11:42 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id LAA03373 for ; Tue, 26 Mar 1996 11:42:20 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id LAA00676 for quake-editing-outgoing; Tue, 26 Mar 1996 11:32:12 +0100 Received: from odin.diku.dk (root@odin.diku.dk [130.225.96.221]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id LAA00670 for ; Tue, 26 Mar 1996 11:32:04 +0100 Received: from embla.diku.dk (root@embla.diku.dk [130.225.96.229]) by odin.diku.dk (8.6.12/8.6.12) with ESMTP id LAA02672 for ; Tue, 26 Mar 1996 11:31:58 +0100 Received: (uffefl@localhost) by embla.diku.dk (8.6.12/8.6.12) id LAA28237; Tue, 26 Mar 1996 11:26:05 +0100 Date: Tue, 26 Mar 1996 11:26:04 +0100 (MET) From: Uffe Friis Lichtenberg To: quake-editing@nvg.unit.no Subject: Distance from plane to point In-Reply-To: <11980@tsys.demon.co.uk> Message-ID: MIME-Version: 1.0 Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Status: RO X-Lines: 38 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 1160 On Tue, 26 Mar 1996, Tom Wheeley wrote: > In article <01BB1A6C.CBC201A0@ppp001.free.org> you write: > > > BTW, I'm having a little trouble understanding how to figure the = > > distance between (0,0,0) and a plane. If anyone could enlighten me on = > > this subject I be really grateful. > > Eh? How is your plane definition stored? id store their planes: > > r.n-hat = d (n-hat is an `n' with a `^' circonflex (sp?) on top.) > > Where `d' _is_ the distance from (0,0,0) and `r' is a general point, and `.' > is the scalar product (x1*x2+y1*y2+z1*z2). n-hat is the unit-vector stored > at the beginning of each plane entry in the BSP, it is followed by `d'. > > It is hard to help without knowing just what information you do have about > your plane. I couldn't quite follow that, so maybe I can be of help... You've got an equation for the plane a*x+b*y+c*z+d=0 The distance from any point (x',y',z') to the plane should be given by sqrt(a*x'+b*y'+c*z'+d) But of course I could be mistaken (it has been quite a while...) Zonk, Uffe. [uphfe] uffefl@diku.dk -- "This .signature hasn't been left unintentionally void of blankness" From quake-editing-owner@nvg.unit.no Thu Mar 28 02:52 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id CAA08973 for ; Thu, 28 Mar 1996 02:52:08 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id CAA24702 for quake-editing-outgoing; Thu, 28 Mar 1996 02:43:16 +0100 Received: from runix.runit.sintef.no (runix.runit.sintef.no [129.241.1.5]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id CAA24697 for ; Thu, 28 Mar 1996 02:43:11 +0100 Received: from relay-2.mail.demon.net (actually disperse.demon.co.uk) by runix.runit.sintef.no with SMTP (PP); Thu, 28 Mar 1996 02:37:01 +0100 Received: from post.demon.co.uk ([158.152.1.72]) by relay-2.mail.demon.net id aa27411; 28 Mar 96 0:14 GMT Received: from tsys.demon.co.uk ([158.152.159.87]) by relay-3.mail.demon.net id aa12176; 28 Mar 96 0:09 GMT Date: Wed, 27 Mar 96 00:21:16 GMT Message-ID: <12067@tsys.demon.co.uk> From: Tom Wheeley Organization: City Zen FM To: quake-editing@nvg.unit.no Subject: Distance from plane to point X-Mailer: Demon Internet Simple News v1.30 Lines: 59 X-Sig-By: Tomsystems Quote v1.2. (c)1996 Tom Wheeley, tomw@tsys.demon.co.uk Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 1844 Status: RO X-Lines: 61 In article you write: > On Tue, 26 Mar 1996, Tom Wheeley wrote: > > > In article <01BB1A6C.CBC201A0@ppp001.free.org> you write: > > > > > BTW, I'm having a little trouble understanding how to figure the = > > > distance between (0,0,0) and a plane. If anyone could enlighten me on = > > > this subject I be really grateful. > > > > Eh? How is your plane definition stored? id store their planes: > > > > r.n-hat = d (n-hat is an `n' with a `^' circonflex (sp?) on top.) > > > > Where `d' _is_ the distance from (0,0,0) and `r' is a general point, and `.' > > is the scalar product (x1*x2+y1*y2+z1*z2). n-hat is the unit-vector stored > > at the beginning of each plane entry in the BSP, it is followed by `d'. > > > > It is hard to help without knowing just what information you do have about > > your plane. > > I couldn't quite follow that, so maybe I can be of help... > > You've got an equation for the plane > > a*x+b*y+c*z+d=0 > > The distance from any point (x',y',z') to the plane should be given by > > sqrt(a*x'+b*y'+c*z'+d) Err, I'm not certain (or uncertain) about that, as with x',y',z'=0,0,0, you will get the distance as being sqrt(d), when it should be d, yes? (Conversion from my notation) r . n-hat = d ( x ) ( a ) ( y ) . ( b ) = d (where a*a+b*b+c*c=1) ( z ) ( c ) ax + by + cz = d or ax+by+cz-d=0 The change in sign of d doesn't matter, as it is a distance, not displacement. For the distance to (0,0,0), I have the following: ax+by+cz=d; d dist = ----------------- sqrt(a*a+b*b+c*c) Again, for the vectors defining the planes in the Quake bsp files, the denominator is, handily, 1. .splitbung -- * TQ 1.0 * 101 New Names for Quake! 76. Greedy angels From quake-editing-owner@nvg.unit.no Thu Mar 28 09:03 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id JAA11882 for ; Thu, 28 Mar 1996 09:03:12 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id JAA29279 for quake-editing-outgoing; Thu, 28 Mar 1996 09:00:17 +0100 Received: from odin.diku.dk (root@odin.diku.dk [130.225.96.221]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id JAA29271 for ; Thu, 28 Mar 1996 09:00:13 +0100 Received: from vidar.diku.dk (root@vidar.diku.dk [130.225.96.249]) by odin.diku.dk (8.6.12/8.6.12) with ESMTP id JAA15266 for ; Thu, 28 Mar 1996 09:00:08 +0100 Received: from ask.diku.dk (madsdyd@ask.diku.dk [130.225.96.225]) by vidar.diku.dk (8.7.5/8.6.12) with ESMTP id JAA08402 for ; Thu, 28 Mar 1996 09:00:05 +0100 (MET) Received: (madsdyd@localhost) by ask.diku.dk (8.6.12/8.6.12) id JAA17936; Thu, 28 Mar 1996 09:00:02 +0100 Date: Thu, 28 Mar 1996 09:00:01 +0100 (MET) From: Mads Dydensborg To: quake-editing@nvg.unit.no Subject: Re: Distance from plane to point In-Reply-To: Message-ID: MIME-Version: 1.0 Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Status: RO X-Lines: 45 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Length: 1638 On Tue, 26 Mar 1996, Uffe Friis Lichtenberg wrote: > On Tue, 26 Mar 1996, Tom Wheeley wrote: > > > In article <01BB1A6C.CBC201A0@ppp001.free.org> you write: > > > > > BTW, I'm having a little trouble understanding how to figure the = > > > distance between (0,0,0) and a plane. If anyone could enlighten me on = > > > this subject I be really grateful. > > > > Eh? How is your plane definition stored? id store their planes: > > > > r.n-hat = d (n-hat is an `n' with a `^' circonflex (sp?) on top.) > > > > Where `d' _is_ the distance from (0,0,0) and `r' is a general point, and `.' > > is the scalar product (x1*x2+y1*y2+z1*z2). n-hat is the unit-vector stored > > at the beginning of each plane entry in the BSP, it is followed by `d'. > > > > It is hard to help without knowing just what information you do have about > > your plane. > > I couldn't quite follow that, so maybe I can be of help... > > You've got an equation for the plane > > a*x+b*y+c*z+d=0 > > The distance from any point (x',y',z') to the plane should be given by > > sqrt(a*x'+b*y'+c*z'+d) No. The distance is given as a*x' + b*y' + c*z' + d dist =------------------------ (+/-) sqrt(a*a+b*b+c*c) where the sign is chosen, so that dist is positive. This formula is from Schaum's outline series, 'Solid analytic geometry'. (12.13) Mads +---------------------------------------------------------------------+ | Mads Bondo Dydensborg. Student at DIKU, Copenhagen - Denmark. | | Email: madsdyd@diku.dk www: http://www.diku.dk/students/madsdyd | +---------------------------------------------------------------------+ From quake-editing-owner@nvg.unit.no Thu Mar 28 10:14 MET 1996 Received: from sabre-wulf.nvg.unit.no (root@sabre-wulf.nvg.unit.no [129.241.161.9]) by marvin.nero.uni-bonn.de (8.7.4/8.7.1) with SMTP id KAA12845 for ; Thu, 28 Mar 1996 10:14:38 +0100 (MET) Received: (from bin@localhost) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) id KAA30366 for quake-editing-outgoing; Thu, 28 Mar 1996 10:06:22 +0100 Received: from pelican.lannion.cnet.fr (pelican.lannion.cnet.fr [192.44.58.25]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with SMTP id KAA30359 for ; Thu, 28 Mar 1996 10:06:14 +0100 Relayed; 28 Mar 96 10:05:49+0100 X400-Received: by /PRMD=cnet/ADMD=atlas/C=fr/; Relayed; 28 Mar 96 10:05:49+0100 Date: 28 Mar 96 10:05:49+0100 From: Olivier Montanuy To: quake-editing@nvg.unit.no Subject: Please refrain from posting trivialities Message-ID: <9603280905.0828B8@lat1192.lannion.cnet.fr> X-Mailer: E-Mail 1.6 Sender: owner-quake-editing@nvg.unit.no Precedence: bulk Reply-To: quake-editing@nvg.unit.no Content-Type: text Content-Length: 653 Status: RO X-Lines: 22 Oh, my god. I've never seen so many messages on quake editing, and the subject is ... calculation of distance to a plane. What you need is a basic course in analytic geometry. That's not on-topic here I'm afraid, because most of us already know all this. Hopefully that's rather simple maths. We're lucky Quake doesn't run in non-euclidian space... err... well, xcept the water of course :-))) Now the real info: I'm finishing the UQS 3.1. It will be reviewed today by co-authors, and posted tomorrow. If it's good enough :( Almost everything is clarified, though. Olivier Montanuy These are my views, not those of my company.