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