Copy Link
Add to Bookmark
Report
Doom Editing Digest Vol. 01 Nr. 285
From: owner-doom-editing-digest
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #285
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk
doom-editing-digest Friday, 19 May 1995 Volume 01 : Number 285
BSP *bulding* details: Optimisation issues
Re: visplanes error
Re: BLOCKMAP special effects?
Wad Expiration?
Floor drawing issues (off topic?)
Re: Another WAD Error
Re: light problem
Re: BLOCKMAP special effects?
Re: Another WAD Error
Re: Floor drawing issues (off topic?)
Re: [Q] BLOCKMAP packing?
Re: BLOCKMAP special effects?
Re: LMP in PWAD
Re: BSP *bulding* details: Optimisation issues
Re: LMP in PWAD
Re: BSP *bulding* details: Optimisation issues
Re: Floor drawing issues (off topic)
Re: [Q] BLOCKMAP packing?
----------------------------------------------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Fri, 19 May 1995 10:33:31 +0200
Subject: BSP *bulding* details: Optimisation issues
I'd like to ask again :-)
All LineDefs end up as LineSegs. There are LineDefs that are only
trigger or lighting related: no upper, no lower (floor and ceiling
heights of left/right SideDef's sector identical) and no middle on
one or both sides. There's nothign to draw for this Seg.
Is this an opportunity for further improvement of BSP building - or this
the "unecessary feature" of DEU/BSP mentioned before?
Another one (quoting myself):
>Another question: if partition line crossings create single SEG subsectors,
>and creating a larger tree (maybe not very balanced, too) is there a way
>to check for the number of such crossings within the bounding box, and
>reject splits during BSP building?
The second one is a lot more complicated, but the first one sounds
promising. Anybody tried this already?
B.
------------------------------
From: S.Benner@lancaster.ac.uk (Steve Benner)
Date: Fri, 19 May 95 09:52:53 +0100
Subject: Re: visplanes error
At 3:38 pm 17/5/95, Bernd Kreimeier wrote:
>
>I don't think will ever get to any definite solution. BTW, no Id employees
>are currently on this list (have they ever been ?), thus they won't
>(haven't) read anything on "visplanes".
Sorry to argue with a fellow caretaker but you forgot to look on the
doom-editing-digest list, Bernd. There you will find one
johnr@idcube.idsoftware.com. However, I share your doubts that the mighty
ones such as he will enlighten us further on the visplanes problem. Hell,
that'd be like them telling us the location of all the secrets in DOOM II!
;)
- -Steve
------------------------------
From: S.Benner@lancaster.ac.uk (Steve Benner)
Date: Fri, 19 May 95 09:45:41 +0100
Subject: Re: BLOCKMAP special effects?
>From doom-editing-owner@nvg.unit.no Wed May 17 20:32:32 1995
Received: from rocke (rocke.electro.swri.edu [129.162.160.19]) by
sabre-wulf.nvg.unit.no (8.6.10/8.6.9) with SMTP id UAA00316 for
<doom-editing@nvg.unit.no>; Wed, 17 May 1995 20:32:29 +0200
Received: from dfsun1.swri.edu (dfsun1.electro.swri.edu) by rocke (4.1/SMI-4.1)
id AA05283; Wed, 17 May 95 13:32:20 CDT
Date: Wed, 17 May 95 13:32:20 CDT
From: fenske@rocke.electro.swri.edu (Robert Fenske Jr)
Message-Id: <9505171832.AA05283@rocke>
To: doom-editing@nvg.unit.no
Subject: Re: BLOCKMAP special effects?
>I've just finished the descending stairs part, and I have forgotten
>who it was that posted the DNSTAIRS wad. Can you help me?
>I'm very grateful for all the help I received from this list so far.
I have that a Sean Malloy (malloy@crash.cts.com) posted the
DNSTAIRS.WAD.
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."
===============================================================================
MAIL HAD TO BE APPROVED BY CARETAKER (bounced for some reason - dunno myself)
===============================================================================
------------------------------
From: TWM2029@AOL.COM
Date: Fri, 19 May 1995 05:30:39 -0400
Subject: Wad Expiration?
Mabye this is an event specific to myself, but I have been running into
somewhat of a problem recently. Every once in a while I drop back into my
"In-Development WADS" Directory from months ago to see the sorry attempts at
wads created in the past by myself to see if there is any ideas I can salvage
from those old things. Now here is the problem, All of the wads in that
directory were BSPed before I moved them in there, now about a month or two
later, I go to play em' and it would seem that the Blockmap and other
necessary things have been Destroyed! The game gives me a REAL big HOM with
each one of em. Myself and my close firends have deemed this the "Wad
Expiration Date" Which we use to refer to the wads not used within a certian
timeframe. I had this problem with some of my old Doom I wads that I hadn't
played in a while either. I was just wondering if anybody else out there is
having a similar situation (Can't really call it a problem, just gotta RE-BSP
em' before I play again.)
Clock Paradox
Herby DE-Throned of the Fastest H2Hmud01.wad Title - Soon to win it back.....
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Fri, 19 May 1995 10:55:08 +0200
Subject: Floor drawing issues (off topic?)
Robert Fenske wrote:
> DooM uses the lowest # SEG in an SSECTOR to determine the sector to
>draw for the node leaf.
Yeah, I'd do the same. Now there might be >1 SSECTORs from one sector. Each
will have a first SEG, pointing to a LineDef, which (taking SEGs direction
into account) gives the sector. They have to check if the sector is already
in the list of "sectors to draw"?
Olivier Montanuy wrote:
> floors not vertical scans
Right. You have to texture map slices along constant z, to get rid of
any division in the inner texture mapping loop. Floors are slower
than walls, because you have to go through the flat at any angle,
while walls are always done vertically in both screen and texture
space.
>I would bet that the Floor/ceiling drawing is just a consequence
>of drawing the walls. in a column, all the part that isn't wall is
>a floor or ceiling. above a wall is ceiling, below a wall is floor.
Right. You have to exploit this fact, one way or the other.
There are two ways I know of:
a) a "floodfill" approach. You put the floor to draw, and (say) the
leftmost pixel of each slice into a buffer. As soon as walls
are drawn front-to-back and there's nothing more to consider
(remember, top == bottom for each column), you start drawing
horizontal slices from left to right.
Disadvantage one: you have to initialize the framebuffer with
a pixel color that says : NO WALL. This slows you down (you
don't get a HOM, though :-).
Disadvantage two: you have to check for this NO WALL color
for each floor pixel you draw into the framebuffer. The horizontal
slices is done when you find a NO WALL pixel. Slows you down again.
Disadvantage three: you can't use NO WALL colors in walls. 255 left.
This is not done by DOOM. It has been done, e.g. by Chris Laurel.
b) a back-to-front painter algorithm approach. You do not draw
the walls, you just put them into another buffer (each visible
slice, already clipped). You maintain a buffer for floors/ceilings
(on a per-sector basis). Parly transparent walls/sprites as above
(might be merged into the wall buffer).
As soon as top == bottom for each column, you start drawing - the
floors.
You draw each floor as a non-convex polygone (I think, Michael
Abrash's first Dr. Dodds' articles dealt with this), starting with
the ones far away, and drawing nearby ones afterwards.
When you are finished drawing floors, you draw the wall slices
from the buffer. As Olivier pointed out, everything that's not
wall is floor. Thus (as Richard Matthias pointed out to me a few
months ago) the floors will shine through the walls. Done.
Disadvantage: depending on the "range of view", you'll draw
a lot of floors you won't see in the finished frame. Read: you're
drawing a lot of pixels *often*, instead of once. Slows you down.
But it works ;-) - is done by DOOM, it seems.
c) dunno. There are other ways to think of, but I don't know if they've
been done. Note that for some 3D stuff (QUAKE?) you'll have to use
painters algo for everything, or do somethign completey different.
>except for 2s lines where it gets a bit perverted.
That's right. 2s lines are handled like sprites, read: drawn back-to-front
with painters algorithm.
Aside: this is far from "advanced doom-editing" (although understanding
of how the renderer/engine works might ease tracking down errors). If
some of you object and wdo not want threads on this subject, please
let me know via private mail. As soon as my mailbox explodes, I'll
dump the subject, and my apologies in advance.
B.
------------------------------
From: S.Benner@lancaster.ac.uk (Steve Benner)
Date: Fri, 19 May 95 11:16:47 +0100
Subject: Re: Another WAD Error
At 5:52 pm 18/5/95, Dean Johnson wrote:
[Snip]
>> I scoured the WAD for errors (much as you have) and found
>> none. Not a sausage.
> ^^^^^^^^^^^^^
>
>I move that we hereby dub this, the Sausage error. =)
>
The No Sausage error, surely? ;)
- -Steve
------------------------------
From: S.Benner@lancaster.ac.uk (Steve Benner)
Date: Fri, 19 May 95 11:16:39 +0100
Subject: Re: light problem
>In my latest version of vivaldi.wad I tried to play a little bit
>with light effects. I tried to use the "WR switch light to dimmest neighbour"
>and "WR switch light to brightest neighbour", but the only thing
>worked was the switching of light level to 0 or 255. I tried to take care
>that there are neighbour sectors with higher and lower light levels
>but walking over the line had no effects.
>Any idea what's wrong ??
>
Do you have more than one sector tagged to the trigger line? If you do,
DOOM examines only the lowest numbered sector of the group to determine
what the "dimmest neighbour" might be. And if that dimmest neighbour just
happens to be another sector of the group, nothing will happen.
- -Steve
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Fri, 19 May 1995 12:02:16 +0200
Subject: Re: BLOCKMAP special effects?
> Special manipulation of the BLOCKMAP is an interesting idea, but
> right now I can't think of anything you could do that you can't already
> do with LINEDEF flags.
Me too ...
I think that DOOM uses BLOCKMAP to determine when a thing crosses
a 2S linedef, and determines the new ThingIsInSector return. In this
case, removing a (part of a LineDef) allows for entering another
sector while keeping the current sector's # and all attributes.
Imagine a "tweaked" border to a large area covered with nukage/acid. If
the player enters the area crossing any other linedef, he'll get damage
and health loss. If he uses the "magic" entrance, he'll be
invulnerable to the acid. Hmmm - might as well use a suit. Keeping
the viewpoint height has been done, too.
But there might be some use of inheriting the former sector's attributes
(including reject?) while entering another sector, using only special
paths. Probably isn't worth the trouble.
B.
------------------------------
From: S.Benner@lancaster.ac.uk (Steve Benner)
Date: Fri, 19 May 95 11:16:52 +0100
Subject: Re: Another WAD Error
At 4:08 pm 18/5/95, afn03713@freenet.ufl.edu wrote concerning the Not a
Sausage problem:
>>
>Hi guys. This is just a guess from a list lurker, but it is possible that
>this comes from a bug in the doom exe or eve in DOS4GW itself. It appears
>that system memory is being overlaid, which would point to a bug in the
>program or dos extender. Just something to think about, it mat not be you
>wads at all.
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....
- -Steve
------------------------------
From: ah289@freenet.carleton.ca (Jonathan Mavor)
Date: Fri, 19 May 1995 06:21:40 -0400
Subject: Re: Floor drawing issues (off topic?)
>
>There are two ways I know of:
>
> a) a "floodfill" approach. You put the floor to draw, and (say) the
> leftmost pixel of each slice into a buffer. As soon as walls
> are drawn front-to-back and there's nothing more to consider
> (remember, top == bottom for each column), you start drawing
> horizontal slices from left to right.
> Disadvantage one: you have to initialize the framebuffer with
> a pixel color that says : NO WALL. This slows you down (you
> don't get a HOM, though :-).
> Disadvantage two: you have to check for this NO WALL color
> for each floor pixel you draw into the framebuffer. The horizontal
> slices is done when you find a NO WALL pixel. Slows you down again.
> Disadvantage three: you can't use NO WALL colors in walls. 255 left.
>
> This is not done by DOOM. It has been done, e.g. by Chris Laurel.
>
> b) a back-to-front painter algorithm approach. You do not draw
> the walls, you just put them into another buffer (each visible
> slice, already clipped). You maintain a buffer for floors/ceilings
> (on a per-sector basis). Parly transparent walls/sprites as above
> (might be merged into the wall buffer).
> As soon as top == bottom for each column, you start drawing - the
> floors.
> You draw each floor as a non-convex polygone (I think, Michael
> Abrash's first Dr. Dodds' articles dealt with this), starting with
> the ones far away, and drawing nearby ones afterwards.
> When you are finished drawing floors, you draw the wall slices
> from the buffer. As Olivier pointed out, everything that's not
> wall is floor. Thus (as Richard Matthias pointed out to me a few
> months ago) the floors will shine through the walls. Done.
> Disadvantage: depending on the "range of view", you'll draw
> a lot of floors you won't see in the finished frame. Read: you're
> drawing a lot of pixels *often*, instead of once. Slows you down.
>
> But it works ;-) - is done by DOOM, it seems.
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.
L8r,
Jon
- --
Gleb McFlabberWHO? oki-doki whatever you say buddy.
\ /----\ / < [X] /-------------\
\______/ <--- What the hell is that? [X] | N E U R A L \---|
/ \----/ \ < [X] | S T O R M KFA |
------------------------------
From: Steve McCrea <sm@eng.cam.ac.uk>
Date: Fri, 19 May 1995 13:13:03 BST
Subject: Re: [Q] BLOCKMAP packing?
About BLOCKMAP packing:
Is the 64K word limit only for loading the BLOCKMAP? Because objects
are put in at runtime, aren't they? So the BLOCKMAP will expand,
especially a packed BLOCKMAP.
Correct me if I'm wrong...
Steve.
------------------------------
From: S.Benner@lancaster.ac.uk (Steve Benner)
Date: Fri, 19 May 95 12:59:46 +0100
Subject: Re: BLOCKMAP special effects?
At 10:02 am 19/5/95, Bernd Kreimeier wrote:
>
>
>I think that DOOM uses BLOCKMAP to determine when a thing crosses
>a 2S linedef, and determines the new ThingIsInSector return.
I'm not 100percent convinced of this: I remember messing about with an
early version of WADED that had a BLOCKMAP build error (it used the faulty
algorithm given in the old DOOM Specs) that resulted in some line sections
being lost from the BLOCKMAP. My recollection was that the only noticeable
effect was the ability to wander through single-sided walls into the void.
Of course, I was only looking for what was wrong with the blockmap so that
I could suggest a way of fixing it, not to try to make use o it, so I could
well be wrong here...
>
>Imagine a "tweaked" border to a large area covered with nukage/acid. If
>the player enters the area crossing any other linedef, he'll get damage
>and health loss. If he uses the "magic" entrance, he'll be
>invulnerable to the acid. Hmmm - might as well use a suit.
Except that suits are limited in supply...
>. Probably isn't worth the trouble.
Yes and no, maybe! It would be fun to try out, but I'd hate to try to
devise way of specifying which section of a line was to be omitted from the
blockmap. And are blockmap divisions normalised to map coordinates or are
they a function of X-Min, Y-Min? (Can't remember: sorry) If the latter, it
would really screw things up!
- -Steve
------------------------------
From: fenske@rocke.electro.swri.edu (Robert Fenske Jr)
Date: Fri, 19 May 95 07:39:09 CDT
Subject: Re: LMP in PWAD
>>Download DeuTex, dismantle your PWAD, put your LMP into the right DIR, edit
>>the DeuteX control file, build the new PWAD and ... Whooooosh ... finished.
>Oh my god. Get NWT, load your WAD, create a resource at a position you
>want and insert your lmp.
>
>It can't be easier, sorry Olivier, but for those little things DeuTex
>is too awkward and involved. Maybe WinTex...
>NO, I don't want to start another war about programs... :)
You could use the command line of DEU to get an LMP into a WAD.
Basically you insert the raw LMP data into it's own WAD and then merge
that WAD with your target WAD.
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 07:46:47 CDT
Subject: Re: BSP *bulding* details: Optimisation issues
>All LineDefs end up as LineSegs. There are LineDefs that are only
>trigger or lighting related: no upper, no lower (floor and ceiling
>heights of left/right SideDef's sector identical) and no middle on
>one or both sides. There's nothign to draw for this Seg.
>
>Is this an opportunity for further improvement of BSP building - or this
>the "unecessary feature" of DEU/BSP mentioned before?
Yes, but the SEG still needs to be accounted for since it forms
part of the closed convex polygon (the SSECTOR). These polygons are formed
from SEGS and partition lines, so by dropping out SEGS as described above
you end up with an unclosed polygon. Now perhaps DooM would draw such
SSECTORS correctly anyway--I have no idea. But I don't think the extra
work to remove these SEGS is worth the trouble.
Another one (quoting myself):
>Another question: if partition line crossings create single SEG subsectors,
>and creating a larger tree (maybe not very balanced, too) is there a way
>to check for the number of such crossings within the bounding box, and
>reject splits during BSP building?
I'm not sure what you mean here. All the node builders test
candidate partition lines for the number of splits they would create. They
pick partition lines that more or less have the least number of splits,
with some consideration for balancing the left and right subtrees.
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."
B.
------------------------------
From: tbone@proex.com (Bill Ballmaier)
Date: Fri, 19 May 1995 08:04:27 -0400
Subject: Re: LMP in PWAD
>>Download DeuTex, dismantle your PWAD, put your LMP into the right DIR, edit
>>the DeuteX control file, build the new PWAD and ... Whooooosh ... finished.
>Oh my god. Get NWT, load your WAD, create a resource at a position you
>want and insert your lmp.
>
>It can't be easier, sorry Olivier, but for those little things DeuTex
>is too awkward and involved. Maybe WinTex...
>NO, I don't want to start another war about programs... :)
>
Why the hell am I still on the damn list! I did the unsubscribe command.
Please take me off before I get really obnoxious.
T-Bone
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Fri, 19 May 1995 15:27:55 +0200
Subject: Re: BSP *bulding* details: Optimisation issues
> Robert Fenkse wrote:
> Now perhaps DooM would draw such
>SSECTORS correctly anyway--I have no idea.
Guessing, I think it won't make a difference. The
SSECTORS aren't properly closed anyway, as the
partition lines isn't very useful to create a
closed SSECTOR (sigh). To draw all the walls,
you'll need just the list of SEGS that actually
have at elast an upper or lower or middle on
one side.
>But I don't think the extra
>work to remove these SEGS is worth the trouble.
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
much. On the other hand, at least some post-processing
of the BSP tree might be done w/o much trouble : just
scan the SEGS for "no wall" LineDef SEGs. If you
are determined, scan SSECTORS for now empty
subsectors, and NODES for nodes w/o any leaves. If
I get around to try this, I'll let you know.
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.
B.
------------------------------
From: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Fri, 19 May 1995 14:33:07 +0200
Subject: Re: Floor drawing issues (off topic)
Jon Mavor wrote:
>Doom does NOT redraw anything.
Quoting Ted Vessenes again (march 29th or earlier, on this list):
>It [DOOM] had drawn some of the
>walls farther back and was in the middle of-- get this-- drawing the green
>slime pit surrounding the rocket launcher. Only when it's done repainting,
>the green slime pit is overpainted.
I haven't confirmed his observation. I don't think I need to ;-).
Jon Mavor wrote:
>then 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.
I don't think it's that easy (or fast). Perhaps you should elaborate
(***private mail***, as most people on this list probably aren't
interested, ok?).
As I understand your proposal, you'll be forced to create a list of
(xstart, xend, y) in screen space for each SEG, from the current
top/bottom clipping. Note that a wall (e.g. of a pillar) might split
your floor in two from certain points of view. But, even with looking
up top/bottom for every pixel along every horizontal slice up to the
rightmost column index of the whole sector, and avoid "leak out"
into other free areas, perhaps it won't be much slower compared to
redrawing lots of floor pixels... can't say. I still think DOOM does
it back-to-front for floors, nevertheless there might be other
(even better) ways.
OK, let's move this to private mail.
B.
------------------------------
From: fenske@rocke.electro.swri.edu (Robert Fenske Jr)
Date: Fri, 19 May 95 09:31:48 CDT
Subject: Re: [Q] BLOCKMAP packing?
>About BLOCKMAP packing:
>
>Is the 64K word limit only for loading the BLOCKMAP? Because objects
>are put in at runtime, aren't they? So the BLOCKMAP will expand,
>especially a packed BLOCKMAP.
In a post some time ago, someone said he thought that the zero word
in each block was replaced at runtime with a pointer to the things that are in
the block. Since the BLOCKMAP packing works, I don't think this is the case.
(So I have no idea what the zero word is for.) So I believe no expansion
is done to the BLOCKMAP.
I think the BLOCKMAP is only used for efficient collision detection.
This is speculation, but the BSP tree would be more appropriate to use for
thing positioning, since things have to be drawn in the same manner as the
level itself.
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 #285
**********************************
