Copy Link
Add to Bookmark
Report
Quake Editing Digest Volume 1 : Number 16
quake-editing-digest Sunday, 24 March 1996 Volume 01 : Number 016
Re: Legal issues (was: WAD conversion sketch)
just another brick in the wall.. [RANDOM TITLE]
Re: WAD Conversion sketch
Rendering Quake surfaces
Re: WAD Conversion sketch
----------------------------------------------------------------------
From: Shawn Green <shawng@idsoftware.com>
Date: Sat, 16 Mar 1996 18:03:13 -0600
Subject: Re: Legal issues (was: WAD conversion sketch)
At 07:45 AM 3/19/96 -0600, you wrote:
>However, there is another factor in this equation: Exactly WHY did id release
>the test in the form they did? (monsters, etc.) It's not as if they are
>stupid enough to believe that no one would try to implement them or that
>they could care less what we could do with it. Of course, I don't explain
>a candid answer to this from them, but it is an interesting question and
>the possibilities might shed some light on id's plans concerning editors,
>utilities, etc.
We didn't release it for any other reason than testing the technology. Had
we thought about it, we would have removed the models and other items that
were not in the game from the pak file.
- -Shawn Green
Project Manager
id Software
Official release date for everything - "When it's done!"
That's the only one you'll ever get.
------------------------------
From: "Muad'Dib" <root@sietch.bloomington.in.us>
Date: Wed, 20 Mar 1996 14:01:00 -0700
Subject: just another brick in the wall.. [RANDOM TITLE]
Responding :* One EXE for all? (was Re: Legal stuff)
************
> It could be made sufficently hard to remove if it was a key that was
> spread throughout the WAD and was used to construct some weird
> checkdigit at the end. It could remain undocumented, so nobody could
> remove it and the EXE would be the only thing that had to know how to
> look for it.
>
> That way everyone could make whatever editor they wanted, and if you
> didn't have the registered WAD, then you would not be able to play
> the add-on levels. In fact, the editor-designers wouldn't have to worry
> about checking for registered versions of the game at all, because the
> EXE would handle it.
This is a thingy for ID to do. They will figure out how they wanna do that.
I don't think we need to worry. As EvilGenius or someone said, we're not
making something Shareware compatable, we're making something test compatable.
It will almost definitely not work with shareware, so when there is a
registered out, it'll be updated for that.
Muad'Dib <root@sietch.bloomington.in.us>
The Mouse a.k.a. Greg Alexander
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Date: Mon, 18 Mar 1996 14:35:18 +0100 (MET)
Subject: Re: WAD Conversion sketch
>From: Uffe Friis Lichtenberg <uffefl@diku.dk>
>additional info need, namely convex hulls
Has anybody verified that a Slab BSP tree is needed, or might
it be easily omitted with a zero length entry? If there is
only one Slab, does it have to be a convex hull, or is a
bounding box sufficient?
>we do need a 3D BSP tree
If I am not mistaken, you could simply copy the 2D BSP into
a matching 3D BSP, and convert the information from the old
NODES and SSECTORS. Think about it.
>the floors and ceilings are planes and have to be partitioned
You are perfectly right. In fact, this might be the most
difficult task to solve. It breaks down to creating closed
polygons from SECTORS and LINEDEFS for each floor (ceilings
will have the same partitions), and using the 2D BSP NODES
info (namely the partition lines) to split the SECTORS'
polygon into the Leaf2D surfaces. I already added this
to the proposal.
>misc. remarks on conversion, DXF, intermediate file formats
All very true. However, I am skeptical that any file format
not done by id will ever be agreed upon. Anybody remember the
porposal by Tom Neff (WAD Interchange Format)?
>>The WAD will have to have only one floor/ceiling per xy plane,
>>i.e. the DOOM world geometry restrictions
>But where do you find wads that fulfil this requirement?
Hmmm? Any WAD that can be used with DOOM does :-).
b.
------------------------------
From: etherton@netcom.com (David Etherton)
Date: Sun, 17 Mar 1996 20:47:17 -0800
Subject: Rendering Quake surfaces
[Please forgive me if this is asked a lot, I can't get through to
the mail archives on http://www.nero.uni-bonn.de/~dn/qd/qd_welcome.html
right now]
Like just about everybody else around here, I've been playing around
with trying to render the Quake levels. The Quake specs (3.0) have
proved invaluable.
First, in the List of Edges, if the sign bit of the edge is set, are
we supposed to look at edge ~i or -i? (Nodes use ~i to mark leaves
according to both the spec and my own experience). For the List of
Edges, though, neither ~i nor -i seem to work particularly well,
although -i seems to work slightly better.
I can traverse the BSP tree and find the leaf containing my camera
position correctly, so I know I've got the basics right. However,
when I try to render, I find that the list of surfaces often
tells me to (say) render surface 7 three times in a row, and that
it's got 30 edges in the surface.
Surfaces with small numbers of edges seem to "connect" together well
(ie the end vertex of one edge is the start vertex of the next, and
it forms a closed figure). Some surfaces with larger numbers of
edges seem to form closed figures if you sort the edges after
reading them in, but surfaces with 16 or more edges seem to not
form closed figures.
I can't imagine a fast renderer wanting to deal with anything larger
than a tri or a quad, so I'm suspicious of anything with more than
four edges. Combined with my experience with surfaces with large
numbers of edges having nonsensical edge lists, I wonder if we're
supposed to interpret the edge count differently if it's above
a certain value.
Also, why would the list of surfaces explicitly tell me to render
the same surface two or three times in a row? I haven't done an
exhaustive check, but it appears that every time a surface is
supposed to render several times in a row, it usually also has
a large number of edges.
Am I totally off in the weeds here or is anybody else fighting
the same things I am?
- -David Etherton
ps. For what it's worth, I have been able to parse and render the
models perfectly; either a Z-buffer or a bucket Z-sort seems
to produce good results; the latter has some slight defects
(ever seen a PlayStation?) but is *much* faster on both my
PC and my SparcStation
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Date: Mon, 18 Mar 1996 14:35:18 +0100 (MET)
Subject: Re: WAD Conversion sketch
>From: Uffe Friis Lichtenberg <uffefl@diku.dk>
>additional info need, namely convex hulls
Has anybody verified that a Slab BSP tree is needed, or might
it be easily omitted with a zero length entry? If there is
only one Slab, does it have to be a convex hull, or is a
bounding box sufficient?
>we do need a 3D BSP tree
If I am not mistaken, you could simply copy the 2D BSP into
a matching 3D BSP, and convert the information from the old
NODES and SSECTORS. Think about it.
>the floors and ceilings are planes and have to be partitioned
You are perfectly right. In fact, this might be the most
difficult task to solve. It breaks down to creating closed
polygons from SECTORS and LINEDEFS for each floor (ceilings
will have the same partitions), and using the 2D BSP NODES
info (namely the partition lines) to split the SECTORS'
polygon into the Leaf2D surfaces. I already added this
to the proposal.
>misc. remarks on conversion, DXF, intermediate file formats
All very true. However, I am skeptical that any file format
not done by id will ever be agreed upon. Anybody remember the
porposal by Tom Neff (WAD Interchange Format)?
>>The WAD will have to have only one floor/ceiling per xy plane,
>>i.e. the DOOM world geometry restrictions
>But where do you find wads that fulfil this requirement?
Hmmm? Any WAD that can be used with DOOM does :-).
b.
------------------------------
End of quake-editing-digest V1 #16
**********************************
