Copy Link
Add to Bookmark
Report
Doom Editing Digest Vol. 01 Nr. 377
From: owner-doom-editing-digest
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #377
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk
doom-editing-digest Sunday, 13 August 1995 Volume 01 : Number 377
Re: Quake specs
Re: Quake specs
Re: Quake specs
Doom Texture (Patches)
Re: Quake specs
Revenant's missiles
Re: Revenant's missiles
The 1st Quake Unofficial Technical specs!!!!
----------------------------------------------------------------------
From: Peter Webb <pwebb@audio.apana.org.au>
Date: Sat, 12 Aug 1995 13:01:14 +1000 (EST)
Subject: Re: Quake specs
Hi,
On Fri, 11 Aug 1995 mmathews@genesis.nred.ma.us wrote:
> > Are you going to have Quake specs so we can start on QUE (Quake Utility Editor).
>
> I mean QEU (Quake Editor Utility).
>
>
> Mark Mathews mmathews@genesis.nred.ma.us TEAM OS/2, TEAM DEU
> Are you using DEU, WARM or DEUTEX for DOOM? WHY NOT??
>
From what I have been told a Quake Editor will be released with the game
and the specs may even be included with it.
------------------------------
From: Denis.Moeller@kiel.netsurf.de (Denis)
Date: Sat, 12 Aug 95 02:48 GMT
Subject: Re: Quake specs
Hi!
>> Of course, we're using UNIVBE for all the hi-res VESA modes.
>> Mark Matthews was correct in his assumption (?) that Quake's 3-D editors
will
>> be a top-view and a side-view. Our QuakeEd World Builder uses both of
those >> as well as a 3-D Camera View so we can see what we're drawing. I
placed a GIF
>> of a typical QuakeEd work screen on our ftp site in
>> /idstuff/quake/qe_dev.gif. The colors looked a little off after i
converted it
>> from TIFF to GIF, but hey - it's the content that matters, right?
>> The game is coming along better than expected. Goodbye DOOM.
>Wow! I'm right I can't beleive it!
>Are you going to have Quake specs so we can start on QUE (Quake Utility
Editor).
>This name is reserved for Raphael Quinet.
No - Raphael has to name it: Quied. :)
Come on, who wants to try to do an editor without any testing-capabilities???
Though, someone may start to do the graphical/drawing stuff...
I wonder if it is possible to mirror a level of Quake and walk at
what was thought to be the ceiling?!? Like I understand the big Quake
enhancement, that there are no fixed walls (floors or ceilings) anymore...
Just a bunch of walls around the player. Mmmhhh...
The Romeromeister, uh? Der Meister Romero sounds better I think... :)
However - pretty cool from you guys releasing the source of Wolfenstein! :)
cya
Denis
[] Denis Moeller, author of NWT v1.3 and TiC's WAD Reviews. []
[] Just play our Doom (2) Add-Ons: Sudtic, Teutic, Obtic. Thanks. []
------------------------------
From: Alden Bates <abates@central.co.nz>
Date: Sat, 12 Aug 1995 21:33:39 +1200 (NZST)
Subject: Re: Quake specs
On Sat, 12 Aug 1995, Denis wrote:
> I wonder if it is possible to mirror a level of Quake and walk at
> what was thought to be the ceiling?!?
What about reverse gravity. Or even an item (antigrav spell) so just one
player could be affected. Imagine playing deathmatch and looking up to
see a guy hanging upsidedown from the ceiling aiming a large crossbow at
the top of your head... :-)
> However - pretty cool from you guys releasing the source of Wolfenstein! :)
Which I'll get around to understanding one day... Heck someone could
engineer multiplayer Wolf. :-)
BTW, was releasing the code an easy way to get copyright to apply?
Alden Bates.
------------------------------
From: Denis.Moeller@kiel.netsurf.de (Denis)
Date: Sat, 12 Aug 95 11:33 GMT
Subject: Doom Texture (Patches)
Hi!
Wow, this is a real Advanced-Doom-Editing question! :-)
Refering to the Doom Specs, a texture is composed of patches. Every
patch is saved in a so called patch-descriptor of TEXTUREx.
They got x and y coords and the number of the PName to use.
After that values there are two additional ints [in the specs d) and e)]:
d) is called 'stepdir' -> what is it? Does anyone got that deep into it?
How to use this value (seems to be mostly 1)? What is the effect of it?
I never used it in NWT, but I'm currently reprogramming the whole part,
maybe it can be used some way...?!?
id?
Thanks...
cya
Denis
[] Denis Moeller, author of NWT v1.3 and TiC's WAD Reviews. []
[] Just play our Doom (2) Add-Ons: Sudtic, Teutic, Obtic. Thanks. []
------------------------------
From: mmathews@genesis.nred.ma.us
Date: Sat, 12 Aug 95 11:22:43 -0500
Subject: Re: Quake specs
> However - pretty cool from you guys releasing the source of Wolfenstein! :)
I just checked the Wolfie code. Yuch! If I have time I'll have a field day on this!
Reminds me of some other code I've seen. (wink, wink. nudge, nudge.) ;)
Mark Mathews mmathews@genesis.nred.ma.us TEAM OS/2, TEAM DEU
Are you using DEU, WARM or DEUTEX for DOOM? WHY NOT??
------------------------------
From: "Erwen L. Tang" <etang@pen.k12.va.us>
Date: Sat, 12 Aug 95 15:20:06 EDT
Subject: Revenant's missiles
Hello,
Am I allowed to discuss hacking the DOOM2.EXE in this list?
If so, I would like to ask, what makes the Revenant's missiles
"home"? I would like to reproduce the effect if possible.
Also, if this is possible, can the degree to which missile
homes be set? Ex: A missile that you can lose easily vs. one
that will perform a u-turn and stay on your tail.
Ps. If this type of discussion is not allowed, forgive me.
- --
- ------------------------------------------------------------------------
| Erwen Tang | Tel: (703) 803-8940 | \|/ ____ \|/ |
| Class of 1997 | Add: etang@pen.k12.va.us | @~/ ,. \~@ |
| Thomas Jefferson | etang@capaccess.org | /_( \__/ )_\ |
| High School For | etang@lan.tjhsst.edu | \__U_/ |
| Science & Technology | | |
- ------------------------------------------------------------------------
------------------------------
From: LummoxJR@AOL.COM
Date: Sat, 12 Aug 1995 17:25:43 -0400
Subject: Re: Revenant's missiles
I imagine Doom II is acceptable discussion. :)
I almost hate to reply publicly (everyone else is, and it's driving me nuts),
but this makes good public discussion.
I *believe* code pointers have something to do with what makes a missile home
in on someone, though I can't say for sure. Believe it or not, I've never
played Doom II.
Greg Lewis's DeHackEd will edit frames and stuff, and soon he will release
DHE 2.5, which will include code pointer support. So maybe you can get some
things to act like a missle by editing the EXE.
It's just a guess. Hope it helps.
Lummox JR
------------------------------
From: Olivier Montanuy <Olivier.Montanuy@ens.fr>
Date: Sat, 12 Aug 95 23:55:07 MET DST
Subject: The 1st Quake Unofficial Technical specs!!!!
Here is for your enjoyement!
==================================================================== # 0.1 ==
_ ///// ///// ////// ///// /////
__ _ _ _ ___ | | _____ // // // // // //
/ _` | | | |/ || |/ / _ \ ///// ///// ////// // /////
| (_| | |_| | * || < __/ // // // // //
\__, |\__,_|\___||_|\_\___| ///// // ////// ///// /////
|_|
=============================================================================
The Most Sacred and Most Unofficial Qu*ke Technical Specification.
As derived by Nezu the Unworthy
From the holy Long Words of the True Gods
found in an Ancient Scroll retrieved by the Vandals
============================================================================
"Oh no! it happened again! We're definitly damned."
- Jay W*lbur (Id Soft)
"So what? that's waaay beyond their understanding!"
- John C*rmack (Id God)
"I started training on Quake 6 months ago, so I'll beat them anyway..."
- The RomeroMiser
=============================================================================
Legal Warning
Quake is a Trademark of ID software, inc, hereby acknowledged.
This document was not provided by ID software, and has not been approved
by them. All the descriptions below are pure fantasy. All similarities
with any Quake related material would be entirely coincidental.
Note that ID has been working hard on the best game ever, and it would be
a serious offense to deprive them of their customarily two years advance
on all their competitors. So don't expect too many details.
===================
Introduction
===================
Before you ask:
It doesn't exist, I have never played it, I don't have it,
I don't know who has it, I don't know where to get it,
I don't know how he/she got it, and who did that,
If questionned, I will deny, If tortured, I will strongly protest,
and I'm NOT sending copies anyway, This ain't #warez+
=======================
Organisation of Files
=======================
Chances are that the Gods themselves don't know yet what will be
the organisation of files in the first release of Qu*ke.
*.qp Qu*ke Programming Language files.
This is an interpreted code, similar to C, but
easier to handle.
*.key Object class description files.
These are text files, see format below.
*.wad WAD-2 format files, for various kind of data
like levels, sprite models, levels, sounds, status bar.
*.cfg Config files (no surprise...)
These are text files.
*.rc Ressource configuration files
These are text files, a bit like batch commands
*.exe DOS extended executables, running with GO32, and
probably compiled by the GCC port to DOS, DJGPP.
*.o None... Anyway, I would have prefered .h or .c :)
=================
Command Line
=================
Probably the less relevant info. All this will change.
- -dedicated Probably a server-only game.
- -host UDP/IP host
- -port UDP/IP port
- -rc
- -map Good old -file revisited I guess...
- -kmem
- -animate Frankeistein mode?
- -compile Quake as C Compiler? :-)
- -trace Is it meant as an help for the *.QP?
- -step
- -cache
- -debugfile
- -nosound Note there is no '-nomusic' :-(
- -sound
- -bit
====================
The new WAD2 format
====================
The trusted WAD files are still used to carry most of the Holy Bytes.
Unfortunately the format has changed, current tools need to be redesigned.
However, there isn't much to see in the WADs, for the moment.
// WAD Header
struct QKHEADER
{ char Magic[4]= "WAD2"; // Name of the new WAD format... original, no?
long NbOfDirEntries; // Number of entries
long DirPosition; // Position of WAD directory (offset from start of file)
};
// Directory
struct QKENTRY
{ long Start; // Position of the entry in WAD (offset from start of file)
long Extra; // Size of the entry
long Size; // Size of the entry
long Tag; // Entry identification (cool!)
char Name[16]; // 1 to 16 characters, '\0'-padded
} Dir[NbOfDirEntries]; // like in DOOM
======================
Entry identification
======================
The field 'Tag' in the directory above is presumed to be the
identification of the entry. First because it feels so. Second because
it would be a good idea to put an explicit identification.
0x40 '@'= Raw bytes
Console, Color Palette
0x42 'B'= Pictures (for status bar)
Digits,Fonts
0x44 'D'= Textures (for 3D models)
Rooms,Walls,Floors,Sky,Sprites
======================
Picture Format
======================
This is essentially the same format as in D**M, except that the
picture is draw by row, not by columns, and that 16-bit numbers
are used, because a screen is 320 or 640 wide.
struct QKPIC
{ long Width; // Picture width
long Height; // Picture height
long Row[Height]; // Offset to the rows, from start of picture
}
// Each column is a set of lumps, placed one after the other.
// if for a lump Hpos=0xFFFF, then it's the end of the set.
struct PICLUMP
{ int Hpos; // Horizontal offset
int Count; // number of pixel
char Pixel[Count]; // pixels color index (in current palette)
char Dummy[Count&1]; // to align the structure PICLUMP on 16-bit boundary
}
It can be speculated that Qu*ke is Row-oriented, when D**M was entirely
Column-oriented. This would be fairly normal, because screen memory access
if much faster when Row-oriented than when Column-oriented.
======================
Texture Maps
======================
These are the entries that are used to represent the texture of wall,
things and such. Note: the structure of the texure entry is entirely
guessed from scratch.
That's why there are those 'Dum' entries at the begining. They contain
some apparent nonsense, in sequence of repeated bytes, 3 at the time.
It can't possibly be model coordinates. Maybe lighting?
struct TEXHEAD
{ char Dum0[3]; // purpose unknown
char Dum1[3]; // purpose unknown
char Dum2[3]; // purpose unknown
char Dum4[3]; // purpose unknown
char Dum5[3]; // purpose unknown
char Tag; // purpose unknown
long W; // Width
long H; // Heigth
long Scale1Pos; // pointer to Tex, scaled 1
long Scale2Pos; // pointer to Tex, scaled 1/2
long Scale4Pos; // pointer to Tex, scaled 1/4
long Scale8Pos; // pointer to Tex, scaled 1/8
}
// At offset Scale1Pos, from start of file
char Tex1[ W*H];
// At offset Scale2Pos, from start of file
char Tex2[ (W/2)*(H/2)];
// At offset Scale4Pos, from start of file
char Tex3[ (W/4)*(H/4)];
// At offset Scale8Pos, from start of file
char Tex4[ (W/8)*(H/8)];
All those Tex1, Tex2, Tex3, Tex4 represent color indexes, And the
picture is 256 colors. The picture palette is usually indicated in
the begining of the WAD that contain a set of textures.
The color palette index zero is used to represent transparency.
The remarkable structure above has one explanation: Anti-Aliasing!
We all know how in D**M the textures looked dirty and flashy when seen
from far away, and that the only way to prevent this effect was to
smooth the texture before putting it into the WAD.
Well, the Gods have decided that they had enough. Bare result is
that the size of the entry grows by an other 7/8th.
Warning: Unless you KNOW what Aliasing is, don't attempt to derive the
smaller pictures from the biggest one. You have to smooth and quantize.
The rule is that a picture at a given scale must not contain frequencies
above 1/4th of the sample frequency because this picture will be
scaled down up to 1/2. Normally, the rule is only 1/2th of the sample
frequency, but this isn't sound, and this is meant to be scaled down.
If you don't understand the above, don't fiddle with pictures.
======================
The 3D Model Format
======================
These are the Holy Bytes of the Gods. No mortal shall read them.
All I can say is: there is a 3D BSP, a bounding box, and some textures.
That's not much of a surprise, isn't it? Well, those bytes are hard to chew.
Acually, there are some powers from Ancient Greece that are gonna kick some
Bytes's butt, and it could be that the whole thing become somewhat more
clear.
====================
Level structures
====================
I have absolutely not the least idea on how the levels will be organised.
Never wandered through Qu*ke, actually. I just hope there aren't too many
restrictions (there must be some, to speed-up the engine)
================================
The Qu*ke Programming Language
================================
This language is very similar to C. It is loaded dynamically by
the server, read, and most probably transformed in an internal
representation.
The names of variables in the code are reminiscent of MUDs code,
and there is all reason to beleive Qu*ke will be MUD-like.
Of course, there isn't much code compared to even the simplest MUDs.
There is code that describe how the Qu*ke server should handle
the clients, as they join an existing world. BTW, they can join
dynamically, like in DESCENT. And they can join the level they wish.
The Things are all represented by C-like objects, with a
set of attributes whose name are fairly intuitive (frags, velocity,
health...) and the language provides a set of functions of the
basic stuff.
Vectors values are represented as character strings like "1 2 3", and
can be added, scaled and multiplicated.
The attribute think is used to tell or what code function the object
shall apply.
The attribute nextthink is used to tell when the next call to the
object's code shall happen.
Like in D**M, the Object/monsters will be implemented as finite state
automats, based on frames. But you won't need DeHacked to read them.
The Objects frame tables are provided in the code (with a special
macro structure, that expands trivialy into code)
Programmer's Corner:
The language seems syntaxicaly clean, but there seem to be no strict
type checking anywhere, so odds are that any complex code module
will be real difficult to debug. Not to mention the 'goto' lying around.
I wonder what happen when one mixup frames from different monsters...
Apparently the language is entirely event driven (not a surprise) and
timers can be set for certain events. Mind the event loops!
==================
List of Entities
==================
the *.key file contains object class definition, with
default parameters. These classes are written as a list,
in some LISP-like language, except that the ( ) are { }.
Attribute include the class name, the color, the 3D model,
the size of the object (a scaled cube, not a sphere), the
light, the style, the actions (use, touch, think) the
movt should change.
Note that there is no key that allow rotation on the X or Y axis.
==========================
The Language of the Gods
==========================
The language of the Gods, 0"}
{model "s_bestiole"}
}
=============
Light maps
=============
the way the light flickel be provided about anything related to the C code, because
they would give *much* too many hints on the way Quake actually works.
======fabcdefgmmmmaahijlkmmaamm 9 BOUGIE (third variety)
=================
Player Movements
=================
The poor chap can move (left, right, up, down), strafe,
look up and down, attack, use, and be thoroughly hammered down.
He can also change screen size, disable or enable dither.
He can neither jump nor climb yet, apparently. that should change.
Note that there is no key that allow rotation on the X or Y axis.
==========================
The Language of the Gods
==========================
The language of the Gods, countrary to common Tleilaxu beliefs, is C.
It wngine's 2D scanning.
The display would be horizontal-line oriented, and a scan would be made
for every horizontal line: the engine then has to determine the
intersection between a plane (defined by the eye and the horizontal line)
and the 3D structure ofpeed up the process. A local BSP of course
appears much more suitable than the single BSP of D**M's levels.
It can then be conjectured that horizontal splits in this BSP are almost
worth nothing to Qu*ke.
So it's no more than repeating 200 times (size of vertical pic) the
job that did the D**M engine. hopefully, it goes much faster that
1/200th of the D**M engine because only one line needs to be displayed
at the time, and whereas D**M had to write a full column every time.
Beeing line-oriented rather than column oriented would makes Qu*ke
much faster for screen access. All in all, it could comensate.
A possible consequence would be that, countrary to Descent, there would
be absolutely no way for the player to rotate on the X axis (though
rotation on the Z (left-right) and Y (up-down) would cause no trouble).
I'm not sure about this in fact. Turst the Gods. The Holy Bytes talked
of a Roll cont* be my poor Intel drawing all this marvelous stuff!"
===============
Final Word
===============
Let us recall that all the words above are completely derived from my
imagination, and bear no relation whatsoever with Qu*ke. Even ifl be like, in the
details. There could be major changes. Or complete rewrite. So don't
hope the above will help you make a game as good as Quake will be.
Enough dreaming!
Now back to D**M and H*r*tic!
it could comensate.
A possible consequence would be that, countrary to Descent, there would
be absolutely no way for the player to rotate on the X axis (though
rotation on the Z (left-right) and Y (up-down) would cause no trouble).
I'm not sure about this in fact. Turst the Gods. The Holy Bytes talked
of a Roll cont* be my poor Intel drawing all this marvelous stuff!"
===============
Final Word
===============
Let us recall that all the words above are completely derived from my
imagination, and bear no relatin whatsoever with Qu*ke. Even ifl be like, in the
details. There could be major changes. Or complete rewrite. So don't
hope the above will help you make a game as good as Quake will be.
Enough dreaming!
Now back to D**M and H*r*tic!
------------------------------
End of doom-editing-digest V1 #377
**********************************
