Copy Link
Add to Bookmark
Report
Doom Editing Digest Vol. 01 Nr. 286
From: owner-doom-editing-digest
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #286
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk
doom-editing-digest Saturday, 20 May 1995 Volume 01 : Number 286
Re: Floor drawing issues (off topic?)
Re: BSP *bulding* details: Optimisation issues
BSP *bulding*: Optimisation issues
More intelligent editors
Re: Floor drawing issues (off topic?)
Re: Another WAD Error
Re: More intelligent editors
----------------------------------------------------------------------
From: fenske@rocke.electro.swri.edu (Robert Fenske Jr)
Date: Fri, 19 May 95 09:22:38 CDT
Subject: Re: Floor drawing issues (off topic?)
> Doom does NOT redraw anything. You don't really need to
>when you implement the floor drawing properly. It's basically
>just a consequence of drawing the wall. You draw the walls in a front
>to back order (using the bsp) and as you draw the walls/segs or whatever
>you want to call them you draw the floor attached to that wall piece
>down to the lowest updating clipping coordinate for each column, doing
>this horizontally of course. e.g. fill in the stiff below each wall
>with floor to either the bottom of the screen or to the next highest
>floor wall and the same with the ceiling.
This seems right. Because, for example, if you have no upper
texture on a door you would expect to see any stuff on the other side of
the door if a back-to-front draw is done. But since the missing texture
area is not filled with anything (or has leftover junk), DooM has to know
that it doesn't have to draw anything behind the texture. A front-to-back
approach would give you that knowledge. It also explains why DooM slows
down when you are viewing through a grated texture: there are lots of small
see-throught areas that have to be examined and drawn.
Robert Fenske, Jr. rfenske@swri.edu Sw | The Taming the C*sm*s series:
Electromagnetics Division /R---\ |
Southwest Research Institute | I | | "The Martian canals were the
San Antonio, Texas USA \----/ | Martians' last ditch effort."
------------------------------
From: fenske@rocke.electro.swri.edu (Robert Fenske Jr)
Date: Fri, 19 May 95 09:50:18 CDT
Subject: Re: BSP *bulding* details: Optimisation issues
>You'll save some memory (less SEGs). You might
>speed up BSP building time. How much depends on
>the number of such "invisible" or "no wall" LineDefs.
>You might even save some SEGs (those containing only
>LineSegs from such LineDefs). As far as walls are
>concerned, "no wall" LineDefs might even create
>a non-convex SECTOR in which all the real walls
>can't obscure each other. Yeah, you won't gain that
I think the "no all" LINEDEFS would have to separate regions where
there are not only no height changes but not ceiling/floor texture changes.
(Or is that what you meant originally anyway? I don't remember now.) In which
case both sides of the LINEDEF would probably--but not necessarily--refer to
the same sector. In which case this particular LINEDEF (with its two SEGS)
could be ignored. But these kinds of LINEDEFS are used to generate special
effects and removing these from the BSP would destroy the effects. So you
would want a node builder that would remove these lines except when told not
to.
>Besides some (perhaps negligible) shrinking of the
>BSP, I don't expect any speed up for DOOM. It
>depends on the details of the rendering loop (read;
>how much computation is wasted on each SEG, until
>the renderer recognizes it hasn't got upper/lower
>and middle), but that overhead probably doesn't
>matter that much anyway.
Hey, a SEG saved is a SEG earned ...
Robert Fenske, Jr. rfenske@swri.edu Sw | The Taming the C*sm*s series:
Electromagnetics Division /R---\ |
Southwest Research Institute | I | | "The Martian canals were the
San Antonio, Texas USA \----/ | Martians' last ditch effort."
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Fri, 19 May 1995 17:39:13 +0200
Subject: BSP *bulding*: Optimisation issues
> Robert Fenske wrote:
> I think the "no all" LINEDEFS would have to separate regions where
>there are not only no height changes but not ceiling/floor texture changes.
>(Or is that what you meant originally anyway? I don't remember now.)
Nope. Well, depends on your favorite guess on how DOOM rendering works.
My (current :) reasoning is:
a) SSECTORS are not complete, edges are missing
b) there's no fast way to create convex polygons
from SSECTOR SEGs and NODES partition lines
c) conclusion: floors/ceilings are done per SECTOR
d) conclusion: BSP data is only used for walls
(well, the order of SECTORS might be determined from SSECTORS)
Thus, for wall rendering you don't need to care about differences
in sector floor/ceiling texture or lighting. You *do* have to
care about floors/ceiling height changes - they indicate lowers/uppers.
You do have to care about middle textures on those lines. Anything
else might change. Not many LineDefs, perhaps - seems we should to
some statistics first, on both LineDefs and LineSegs that are "no wall".
B.
------------------------------
From: "David A.R. Wallace" <dwallace@ccs.neu.edu>
Date: Fri, 19 May 1995 11:39:42 -0400 (EDT)
Subject: More intelligent editors
I have been using DCK and Warm1.1 on a huge wad I call the HIVE. My need
to snap stuff to grid changed my six-sided rooms to 8, but the overall
plan of many medium sized rooms connected to each other and a multi-layered
outer rim remained intact.
I have some construction and texture problems that I ran into while
making this wad that I would like the next editor or editor version to
address. The first is simple and texture alignment-based: When a texture
stands out on its own, like a door, it should be automatically centered on
its linedef. Just calculate the linedef's length (int ll) and use the
texture's width (int tw):
xoffset = (ll-tw)/2;
If the texture is wider than the door, only its center will show through.
The next part is more complicated and involves a new construction I call a
string, which is a set of vertices which describe a path:
A-------------B
\ / E
\ / |\
\ / | \
\ C-----D \
I \
| F
| _/
| _/
H----------G
J------K--------L-----------M----------N-------O
A-B-C-D-E-F-G-H-I-A and J-K-L-M-N-O are both strings. A string which
begins and ends with the same vertex is a circular string (the first
example, while hardly circular in shape, is a circular string). Under NO
circumstances should any line segments connecting any consecutive pair of
points cross one another--the resulting curve should be simple, and closed
for curcular strings. If any later manipulation invalidates these
properties, the string must be destroyed unless the user cancels the
change. Merging non-consecutive points in the string should also destroy
it.
I want to be able to use these structures to create staircases as follows:
String 0:
1--------2---------3------------4-----------5----------6---------7
String a:
a--------b---------c-----------d----------e-------f---------g
The strings must be valid, have the same number of points, and don't cross
each other. A level consistency check should be made before this is
attempted, and might be carried out upon calling this function.
1. If possible, create and isolate a new sector with new lines 1-a and
7-g, if needed:
1--------2---------3------------4-----------5---------6---------7
| | | | | | | /
|- -/
| | | | | | | /
a--------b---------c-----------d----------e-------f---------g
All 1st sidedefs MUST point into this new sector (flip if necessary). If
the new area supplanted some of an earlier sector (existing linedefs in
the strings will tell if this is so) then all new linedefs will need a 2nd
sidedef which points to the sector which formerly occupied the space. If
not, then the new lines will be one-sided.
Any conflict regarding what, if anything, the new sector supplants should
cancel the operation. Only the sidedefs which pointed into the new space
at the time the function was called need be checked. The space is new if
the sidedefs don't exist, and the supplanted sector is identified by the
sector tag of these sidedefs.
2. Divide the new sector into stairs using the intermediate points of
each string in succession:
1--------2---------3------------4-----------5---------6---------7
| | | | | | | | | | / | /
|- |- |- /- /- /- -/
| | | | | | | | | | / | /
a--------b---------c-----------d----------e-------f---------g
Check that no interior stair lines cross the sector boundary or each
other. Offer to undo if such conflict occurs.
Now you have the standard stair set which can be handled by any
run-of-the-mill staircase-maker.
While DCK's stairmaker has its merits, it can only generate straight
staircases. The technique showed above can make spirals and zig-zags and
what-have-yous into awesome staircases.
Circular strings can be used for this also, with the same restrictions.
Nice hidden spirals can made with these also. Strings may share
verticies as long as the stair lines to not cross each other, with spiral
applications abounding here as well.
------------------------------
From: Olivier <montanuy@lsun75.lannion.cnet.fr>
Date: 19 May 95 18:24:00+0200
Subject: Re: Floor drawing issues (off topic?)
> Doom does NOT redraw anything. You don't really need to
>when you implement the floor drawing properly. It's basically
>just a consequence of drawing the wall.
That's basically what I said in my last message. I was starting to doubt,
but now there are two of use that agree :-)
> You draw the walls in a front to back order (using the bsp) and as you
> draw the walls/segs or whatever you want to call them you draw the floor
> attached to that wall piece
I'd bet so, but where did you get the info? ID?
and you must draw by taking distance into account, so as to skip some pixels
when going through the flats. whose size is 64x64 so that you can line
through them indefinitely by applying a 0x3F mask.
Now, anyone to rewrite the DOOM engine?
hey, all this process doesn't *require* vertical walls on screen. you could
have the playing flying in 3D like in Descent, but the map would still look
kind of flat.
Now starting a new thread: The-Descent-engine-sux-because-it-makes-use-of-
a-prioiri-convex-polygons-instead-of-using-BSPs-how-slow-it-goes-as-polynoms-
-get-more-and-more-numerous.
Which doesn't mean Descent sux, BTW. Except for the impression fighting through
some squarish intestines.
------------------------------
From: l-sieben@MEMPHIS.EDU (ulasieben)
Date: Fri, 19 May 1995 15:57:57 -0500 (CDT)
Subject: Re: Another WAD Error
>At 4:08 pm 18/5/95, afn03713@freenet.ufl.edu wrote concerning the Not a
>Sausage problem:
>Almost certainly: I find some missions of the the regular DOOM.WAD do this
>quite regularly on my machine. (v1.2, that is--DOOM II seems fine) My own
>(flawless!) WADs also crash a lot if I've been in and out of DOOM a lot of
>times since the last reboot. I'm convinced it's mostly poor memory
>management on the part of the DOS extender (or id's use of it). I can
>improve things by running in a clean machine (which I can rarely be
>bothered to do, not having DOS 6), or by regularly rebooting the machine
>and by keeping away from Windows in between times.
>
>You might try converting the WAD to DOOM II (or is it DOOM II already? I
>lost track, way back) and seeing whether that copes differently. Not that
>it tells you very much if it does....
this error occurs on Doom II 1.9. I am gonna try to rebuild what I did again
(ie start over fromm last working point) and see what happens. This pisses
me off
that I got the not a sausage error. Anyone else have an idea as to what could
be wriong?
-- Evil Genius (Jimmy Sieben)
------------------------------
From: fenske@rocke.electro.swri.edu (Robert Fenske Jr)
Date: Fri, 19 May 95 17:01:35 CDT
Subject: Re: More intelligent editors
>I have some construction and texture problems that I ran into while
>making this wad that I would like the next editor or editor version to
>address. The first is simple and texture alignment-based: When a texture
>stands out on its own, like a door, it should be automatically centered on
>its linedef. Just calculate the linedef's length (int ll) and use the
>texture's width (int tw):
>
> xoffset = (ll-tw)/2;
>
>If the texture is wider than the door, only its center will show through.
Yes, this would be a useful feature. I think most of the time
for the short length lines that the texture alignment is either irrelevant
or you want it centered. For the irrelevant case the texture can be
centered anyway. Or if this centering isn't done automatically, having
a command to center all short length lines would be sufficient.
Robert Fenske, Jr. rfenske@swri.edu Sw | The Taming the C*sm*s series:
Electromagnetics Division /R---\ |
Southwest Research Institute | I | | "The Martian canals were the
San Antonio, Texas USA \----/ | Martians' last ditch effort."
------------------------------
End of doom-editing-digest V1 #286
**********************************
