Copy Link
Add to Bookmark
Report
Doom Editing Digest Vol. 01 Nr. 021
From: owner-doom-editing-digest
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #21
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk
doom-editing-digest Tuesday, 25 October 1994 Volume 01 : Number 021
Re: What sector is thing #NN in?
What sector is thing #NN
DUL/DEL license
Weird Line texture errors
Re: What sector is thing #NN in?
Which SECTOR Contains My THING?
Re: Weird Line texture errors
Re: Which SECTOR Contains My THING?
Re: Weird Line texture errors
Re: Weird Line texture errors
Re: Weird Line texture errors
Re: Weird Line texture errors
Vid Capture into Doom
Re: Weird Line texture errors
Re: What sector is thing #NN in?
Re: Vid Capture into Doom
Re: things, sectors, blockmap
Re: What sector is thing #NN in?
----------------------------------------------------------------------
From: Rich Derr <rhd@interaccess.com>
Date: Mon, 24 Oct 1994 22:12:29 -0500 (CDT)
Subject: Re: What sector is thing #NN in?
> Here's an example: If there's, say, some armor on top of a pillar, then
> fine, if you try and get it, the engine already won't let you go on top of
> the pillar. So say that a switch will lower the pillar... well, then fine:
> you find the switch, flick it, and the pillar lowers. Now if you try and get
> the armor, you'll be able to have the same coordinates of it, and thus can
> pick it up. I don't think that a check as to whether or not the thing is
> "gettable" would be necessary at all, then. I hope I've made what I'm trying
> to say pretty clear; it's kind of hard to explain...
>
What if the pillar is 32 (34? I don't remember what the height is) units
tall? I'm thinking of the green armour at the start of E1M2 right now; there
are other examples. In that case the player cannot stand in the same sector
that the thing is in and cannot acheive the same co-ords. However, he can
get the object if (I'm guessing) his radius intersects the thing's radius.
What if the thing is close to the edge of a 100-unit tall pillar? Or in a
100-unit deep pit that the player can run/jump across? Is the DOOM engine
smart enough not to award the object in these cases?
Of course, if I really cared to know I'd drop everything, shut down Linux,
boot Novell DOS, create a level, and run it before mailing this. I don't :-).
Just playing antagonist.
- --RD
------------------------------
From: matt.tagliaferri@pcohio.com (Matt Tagliaferri)
Date: Mon, 24 Oct 94 18:37:00 -0500
Subject: What sector is thing #NN
DO>Does anyone have a simple, efficient algorithm to determine what
DO>sector a given thing is in? Any clues as to how id does it?
I just wrote this algorithm last week for another project: It goes like this:
To find out what sector point <x,y> is in: (pseudo-Basic syntax)
Create an imaginary horizontal Line from <x,y> to <BigNumber,y>, call this line
(Bignumber is larger than the largest value on the map)
For i=0 to numsectors-1
For j=0 to numldefs-1
if LDef(j).SideDef0 = i or LDef(j).SideDef1 = i
if LDef(j) crosses segment L
numcross = numcross + 1
endif
endif
next
if numcross is odd then x,y in sector!
(see below)
if Leftmostx < previousLeftMostx then
This sector inside previoussector
else
ignore this sector
endif
next
This routine will return TRUE for point x,y in multiple sectors if
sectors are within each other. So then, the last part is to determine
given sectors a and b, which is inside the other?
I believe this question can be answered by looking at the LEFTMOST x
coordinate of sectors a and b. Whichever x is GREATER must be the
innermost coordinate (you can also choose the smallest rightmost
coordinate, or a likewise choice w/ y coordinates). Any one of the
four would do fine.
Full VB algorithm available upon request.
matt tag
- ---
þ OLX 2.1 TD þ Pee Wee's Cleaners: Drop your pants and jacket off!
------------------------------
From: matt.tagliaferri@pcohio.com (Matt Tagliaferri)
Date: Mon, 24 Oct 94 18:48:00 -0500
Subject: DUL/DEL license
DO>This is only remotely related to doom-editing, my apologies
DO>in advance.
DO>"In order to commercially distribute any such map editor or
DO>data utility you must first sign ID's Data Utility License
DO>and ID reserves the right to deny authorization to commercial
DO>distribute the any such map editor or data utility. You may
DO>request a copy of the Data Editor License from ID."
DO>Just for curiosity, has anybody already seen this DUL/DEL
DO>license document? It has been announced long ago (by Jay
DO>Wilbur?), AFAIRK. I asked Id about this (two times at least/
DO>two weeks ago ;-), but haven't received anything yet.
I have this license. It does state that id can terminate the
said agreement for 30 days for any reason whatever, (pretty much
killing the idea of commerical distribution: find a publisher willing to
front duplication/package money for a product that can legally vanish
in one month), as well as thou shalt not distribute the editor with
'any other product', thereby killing the idea of the "Official DEU
CD, comes compleat with 1,235 WAD files as examples".
BTW: I'm unfamiliar with the NetSpeak acronym AFAIRK. Anyone care
to enlighten?
matt tag
- ---
þ OLX 2.1 TD þ I am Locutus of Borg. Do you have any Grey Poupon?
------------------------------
From: rrward@netcom.com (Richard Ward)
Date: Mon, 24 Oct 1994 23:42:44 -0700 (PDT)
Subject: Weird Line texture errors
(Is this mail server still alive?)
Okay, I'm almost done with my next monsterously huge level and I am starting
to get some wierd side effects of some of my lines. A line will have it's
texture painded on normally upp to about 16 pixels from the edge and then the
remaining texture will be mapped from the end back to the anomily point, a of
a width of 16 pixels, and then map correctly after that. The only way I've
found to fix this is to break the linedef in question at the anomily point and
adjust the new section as normal. Any ideas as to why this is happening or
how to avoid it (the map is somewhere around 690 sectors and several thousand
linedefs).
Richard
------------------------------
From: "S. McCrea" <sm@eng.cam.ac.uk>
Date: Tue, 25 Oct 1994 13:00:14 GMT
Subject: Re: What sector is thing #NN in?
MSFell@aol.com ,in message <9410231854071217568@aol.com>, wrote:
> Does anyone have a simple, efficient algorithm to determine what
> sector a given thing is in? Any clues as to how id does it?
>
To answer Matt's question about how id does it, Elias said something
like:
id uses the BSP tree to determine the subsector. The sector is
immediately obvious. The BSP tree is much faster than looking for
nearest lines etc. as it only requires a small number of compares
and maybe a couple of multiplications if the subsector divisions
aren't horizontal/vertical.
Clearly this isn't much use for authors of editors since the BSP tree
isn't up to date.
Steve.
------------------------------
From: asre@uiuc.edu (Scott Coleman)
Date: Tue, 25 Oct 1994 08:50:17 -0500
Subject: Which SECTOR Contains My THING?
[Discussions of algorithms omitted.]
> Why not got to the nearest vertex straight off. That way once of the cases
> is avoided. Of course finding a nearest vertex is not trivial.
> Some sort of intelligent search-n-test algorithm has to be made
> for traversing the vertex list to find the closest to the thing cordinates.
>
> Once a vertex is found it can be used as a key for matching linedefs
> referencing it... blah blah.... some of which will be the nearest lines...
> etc.
RanDOOM undergoes a very similar procedure in order to place new THINGs
in old THINGs' positions. It has to know which LINEDEFs are closest to
the THING in question, as well as the shortest distance between the THING and
the LINEDEF (which may well be at one of the endpoints). It also has to
know what SECTOR the item is in to see if it will fit vertically (i.e. if
the THING is too tall for the SECTOR's height). The algorithm used by
RanDOOM takes advantage of several clever tricks from the first
Graphics Gems book to make this more efficient (and use only integer
math, which is a BIG help). Basically, I start from the BLOCKMAP to find
all LINEDEFs within the same block as the THING (as well as the surounding
blocks, since if the THING is near the edge of a block there may be
LINEDEFs in the adjacent block which are closer than those in the same
block). Of this set of LINEDEFs, find the closest LINEDEF to the THING.
If that LINEDEF has one SIDEDEF, then that SIDEDEF's SECTOR reference is
the one you want. If the LINEDEF is two-sided, then you have to
determine which side of the LINEDEF the THING is on, and use the
SIDEDEF from the appropriate side to get your SECTOR number. Not at all
difficult.
So, Matt, why do you want to know all this? ;-)
> It's probably easier just to use the blockmap to give you a subset of lines
> to see which one the THING's closest to and then get the sector number off
> that line's (appropriate) sidedef.
Uh, yeah. ;-)
> a------------b
> | Sector 2 |
> | | T2
> c------------d
> T3
> e---------------------------------------------f
> | |
> | T1 Sector 1 |
> | |
> g---------------------------------------------h
> The nearest vertex (d) can be completely unrelated to the sector containing
> the Thing, T1. In fact, if you do your test properly, you will find that
> the closest line from the closest vertex is c-d.
If you are measuring the distance from the point T1 to the LINE passing
through c-d, then you are performing the WRONG operation. What you WANT to
do is measure the ditance from T1 to the line SEGMENT c-d. Finding the
distance from a point to a line segment is slightly more complex than
the standard formula for finding the distance from a point to a line,
but there is a nice interger-math algorithm which does this very
quickly. RanDOOM finds the enclosing SECTOR without using raycasting.
- --
Scott Coleman, President ASRE (American Society of Reverse Engineers)
asre@uiuc.edu
Life is temporally limited - drive velocitously!
------------------------------
From: Gregory Alan Lewis <gregl@umich.edu>
Date: Tue, 25 Oct 1994 10:24:02 -0400 (EDT)
Subject: Re: Weird Line texture errors
> Okay, I'm almost done with my next monsterously huge level and I am starting
> to get some wierd side effects of some of my lines. A line will have it's
> texture painded on normally upp to about 16 pixels from the edge and then the
> remaining texture will be mapped from the end back to the anomily point, a of
> a width of 16 pixels, and then map correctly after that. The only way I've
> found to fix this is to break the linedef in question at the anomily point and
> adjust the new section as normal. Any ideas as to why this is happening or
> how to avoid it (the map is somewhere around 690 sectors and several thousand
> linedefs).
I think I've seen the same problem myself, on a much smaller WAD.
Matter of fact anyone who wants to see it can check out tree3.wad, level
3. It's in the room that you teleport to the "space room" from, there's
a box on the floor, and one side has that linedef problem. About 16
units from one side it suddenly draws the texture differently (it's a
texture with the brown planet on it). Anyone know a solution?
Tree
------------------------------
From: S.Benner@lancaster.ac.uk (Steve Benner)
Date: Tue, 25 Oct 94 14:36:25 GMT
Subject: Re: Which SECTOR Contains My THING?
Scott Coleman wrote:
>[Discussions of algorithms omitted.]
>
>
[CHOP]
> Basically, I start from the BLOCKMAP to find
>all LINEDEFs within the same block as the THING [snip]
> Of this set of LINEDEFs, find the closest LINEDEF to the THING.
>If that LINEDEF has one SIDEDEF, then that SIDEDEF's SECTOR reference is
>the one you want. If the LINEDEF is two-sided, then you have to
>determine which side of the LINEDEF the THING is on, and use the
>SIDEDEF from the appropriate side to get your SECTOR number. Not at all
>difficult.
>
>So, Matt, why do you want to know all this? ;-)
>
>> It's probably easier just to use the blockmap to give you a subset of lines
>> to see which one the THING's closest to and then get the sector number off
>> that line's (appropriate) sidedef.
>
>Uh, yeah. ;-)
I don't mean to carp on or anything, 'cos I think we're all getting a bit
sick of this, but isn't the two-and-a-half liner double-quoted above just
the same as the longer winded explanation above it? I meant it to be: I
just couldn't be bothered to type all those words! ;)
So, c'mon Matt, put us ALL out of our misery and tell us why you care?
- -Steve
------------------------------
From: Stanley Stasiak <stasiak@iinet.com.au>
Date: Tue, 25 Oct 1994 22:38:13 +0800 (WST)
Subject: Re: Weird Line texture errors
>
> (Is this mail server still alive?)
>
> Okay, I'm almost done with my next monsterously huge level and I am starting
> to get some wierd side effects of some of my lines. A line will have it's
> texture painded on normally upp to about 16 pixels from the edge and then the
> remaining texture will be mapped from the end back to the anomily point, a of
> a width of 16 pixels, and then map correctly after that. The only way I've
> found to fix this is to break the linedef in question at the anomily point and
> adjust the new section as normal. Any ideas as to why this is happening or
> how to avoid it (the map is somewhere around 690 sectors and several thousand
> linedefs).
>
> Richard
>
Well all I know is that shouldn't be related to the size of the map...
Although I heard somewhere mentioned that levels should be within +-8000
pixels or some wierd thing happen.... hmmm
I have a a level of around 1000 sectors... no problems there...
sounds like it could be a node build problem.
hmmm
Stan.
==============================================================================
.-_!\ | Stanley Stasiak
/ \ | (stasiak@iinet.com.au)
I am here! --->> P_.-._/ <<---- Australia| Perth, Western Australia
==============================================================================
------------------------------
From: Stanley Stasiak <stasiak@iinet.com.au>
Date: Wed, 26 Oct 1994 00:46:05 +0800 (WST)
Subject: Re: Weird Line texture errors
Hi,
Anyone know if it is possible to to have a wad patch that only changes one
subpart of a level direcory.
For example is it possible to make a patch that only replaces the
THING resource of say e1m1?
Why would I want to make one like so?
Well simply because then I could release a level with a small patch
for altdeath play etc... while the complete wad would have the normal
(non-altdeath) thing arrangement.
Stan.
==============================================================================
.-_!\ | Stanley Stasiak
/ \ | (stasiak@iinet.com.au)
I am here! --->> P_.-._/ <<---- Australia| Perth, Western Australia
==============================================================================
------------------------------
From: nabl@cybernetics.net (Rodney Wise)
Date: Tue, 25 Oct 94 12:46:29 EDT
Subject: Re: Weird Line texture errors
err, well not a line texture error, just a general error and i have
no clue what's wrong...it's with doom2, when i try to start the
level (new game-hurtme plenty)...it breaks out and says
Z_CheckHeap: block size does not touch the next block
I figured it might have been a sector problem so as a test I deleted all
the sectors then remade them and ran it...still had the error. i tried
removing the few things i had been working on at the time of the error
and i still got the error. so i dunno what to try now
------------------------------
From: S.Benner@lancaster.ac.uk (Steve Benner)
Date: Tue, 25 Oct 94 17:31:05 GMT
Subject: Re: Weird Line texture errors
>err, well not a line texture error, just a general error and i have
>no clue what's wrong...it's with doom2, when i try to start the
>level (new game-hurtme plenty)...it breaks out and says
>
>Z_CheckHeap: block size does not touch the next block
>
>I figured it might have been a sector problem so as a test I deleted all
>the sectors then remade them and ran it...still had the error. i tried
>removing the few things i had been working on at the time of the error
>and i still got the error. so i dunno what to try now
Sectors like this ---+---------o
| |
---+---------o produce that error.
Sounds like you have an open sector somewhere - check you haven't clobbered
an existing sector with your new stuff, or left a gap somewhere: you need a
decent consistency checker in your editor! (Or to use the one yours has ;)
btw - does any-one have (or know where there is) a list of the crash-to-DOS
error messages that DOOM produces, with known causes? Sorry if this is
common knowledge: we can't all know everything and many [most? :) ] of us
are still learning....
- -Steve
------------------------------
From: IJOHNSON@kuhub.cc.ukans.edu
Date: Tue, 25 Oct 1994 13:27:25 -0500 (CDT)
Subject: Vid Capture into Doom
I've been working on a project with a couple friends to replace the
player sprites with images of ourselves for use in modem games. We
shot video of ourselves in poses corresponding to the player's against
a white cyclorama and captured frames as bitmaps using the doom
palette. After changing the background to cyan, we resize the image
to fit and plug it in with dmgraph.
Naturally, it looks like crap mostly because of the resize from
160x120 to something that fits within 64x64. There also seems to be one
more resolution change from this resized image when it goes into doom.
I thought that what I see in this resized bitmap magnified 4x or 8x in
the editor should be what I see when the image fills a similar portion
of the screen in doom. However, when in doom, it appears that my image
has been squeezed into even fewer pixels. I never realized before
just how low res this game is; it's just not that noticeable from a
distance.
So, has anyone else tried creating graphics for doom with video
capture, or some form of scanning that must be degraded in some way to
fit? What I mainly want to know is, what should I do to get the best
image with the least amount of touch-up (two players means about 100
frames).
Has anyone else made any new player sprites?
Thanks,
Ian
------------------------------
From: Gregory Alan Lewis <gregl@umich.edu>
Date: Tue, 25 Oct 1994 16:15:26 -0400 (EDT)
Subject: Re: Weird Line texture errors
> Anyone know if it is possible to to have a wad patch that only changes one
> subpart of a level direcory.
> For example is it possible to make a patch that only replaces the
> THING resource of say e1m1?
I've tried (with my limited WAD structure knowledge) to do basically
the same thing, and it ended up not working. I tried to do this for a
deathmatch WAD I created, which had to work for Doom I and Doom ][. The
only lumps that were different were the THINGS and SIDEDEFS resources, so
I tried to weed out the other duplicates and mess around with the WAD
directory pointers etc. Unfortuantely I couldn't get it to work, so I
don't think it's possible. I may be wrong however, and if someone knows
otherwise please point it out.
Greg ("Tree")
Author, TREE*.WAD
------------------------------
From: Salporin@aol.com
Date: Tue, 25 Oct 1994 17:29:01 -0400
Subject: Re: What sector is thing #NN in?
>> What if the pillar is 32 (34? I don't remember what the height is) units
tall? I'm thinking of the green armour at the start of E1M2 right now; there
are other examples. In that case the player cannot stand in the same sector
that the thing is in and cannot acheive the same co-ords. However, he can
get the object if (I'm guessing) his radius intersects the thing's radius.
What if the thing is close to the edge of a 100-unit tall pillar? Or in a
100-unit deep pit that the player can run/jump across? Is the DOOM engine
smart enough not to award the object in these cases? <<
Good questions... I didn't think of those special cases, to tell you the
truth, but I don't think that it would matter what sector the thing is in..
I'm not sure, but I think the engine could figure that out... Anyone else
know?
------------------------------
From: johnsond@std.teradyne.com (Dean Johnson)
Date: Tue, 25 Oct 94 14:33:10 PDT
Subject: Re: Vid Capture into Doom
> From: IJOHNSON@kuhub.cc.ukans.edu
>
> I've been working on a project with a couple friends to replace the
> player sprites with images of ourselves for use in modem games.
Is this gonna work for more than two player games? I thought all
players used the same sprites and the Doom engine simply tweaks the
color of the uniform.
> So, has anyone else tried creating graphics for doom with video
> capture, or some form of scanning that must be degraded in some way to
> fit? What I mainly want to know is, what should I do to get the best
> image with the least amount of touch-up (two players means about 100
> frames).
I generated some sprites using a raytracer. I designed the creatures
using colors that would fit closely with Doom's palette and anti-aliased
the hell out the pictures (to get as much info as possible into the
low-res images). This was all fairly simple since I could tell the
raytracer the dimensions that I wanted and adjust the anti-aliasing at
will.
I believe that the equivalent for you would be:
Dress in an outfit that matches well with Doom's colors. You
can just trust that you have it right or check the images first
by viewing them in a graphics program using the Doom palette.
When you're squashing the images. Do everything you can to
preserve the image data. That is, leaving out every other
pixel will look like shit. Different graphics editors will do
this differently so try a variety of them.
Of course Id generated their creature sprites using scans taken from
models so you might investigate what software and techniques they used.
- -Dean
------------------------------
From: MSFell@aol.com
Date: Tue, 25 Oct 1994 17:38:17 -0400
Subject: Re: things, sectors, blockmap
Thanks for all the discussion on this topic.
I suggested east simply because the blocks' numbers increment by 1 when
heading that direction. I know it makes no speed difference, even a
sloppy algorithm will not take a significant amount of time, but I
always prefer to spot optimizations ahead of time.
The blockmap itself provides the boundary to void space, as
Robert Forsman suggested. If your ray-cast exits the blockmap, your
thing is in the void.
As Greg said/hinted, the first number in each blocklist is "0", this
is a space reserved for a pointer to an internal "thing list", which
the engine does calculate at level-initialize time. The dynamic thing
list for a block contains the numbers (index in THINGS lump) of all
things currently in that block, for light/height purposes, and of
course the REAL main benefit of the blockmap, which is collision
detection (btw picking-up is determined by using "collision" combined
with "height difference")
As Steve Benner said, keeping track of linedef-crossing to alter sector
seems the best and quickest way for the engine to maintain accurate
sector numbers for moving monsters/players/barrels. (And projectiles!
Turn off the "always lit" bit for a bfg shot, and shoot it through a
dark/light/dark room like on original Maverick, and watch it strobe.
Neat.) No-clip into the void. You remain in the departure sector for
height and monster-reject purposes (I think). Now re-enter a sector
with a different height. Pop!, you go up. Does this evidence support
the line-crossing theory? The line-crossing is obviously the method
used for triggering lines, zoom in REALLY far on the automap and watch
your arrow (in follow mode) as you trigger a line.
Robert Forsman said:
> If you hit a vertex, then just find all other linedefs that share that
>vertex, pick the one with the numerically greatest cosine (trivially
>computable from the dot product with the west vector) and you
>have a good linedef.
I like this, also the plug for affine transforms :-)
Matthew Ayres wrote that his algorithm...
>doesn't use the BLOCKMAP (having the BLOCKMAP loaded just wastes
>more memory)
Good point, something I failed to consider, since I'm not writing
routines (then why'd I ask?...actually I'm just passing along a
modified question that was asked of me by Frans deVries, he's the
one who started it...)
**************************
Matt Fell (msfell@aol.com)
------------------------------
From: quinet@stud.montefiore.ulg.ac.be (Raphael Quinet)
Date: Tue, 25 Oct 1994 23:14:46 +0100
Subject: Re: What sector is thing #NN in?
I just want to add my pinch of salt to the discussion (and prove
that I am still reading this list from time to time):
I don't know exactly how Id gets the sector number for each thing,
but it would be possible to use the BSP tree for that (go down the
tree, find the ssector, get a seg, then the corresponding linedef
and the sector). That should be pretty fast. Of course, it would
also be possible to use only the list of linedefs and cast a ray
in a random direction, but this is slower.
If you want the source code for doing this, look at the source
code for DEU. There is a routine in DEU which selects the
sector in which the mouse pointer is. It has been there since
version 4.x, which is very old...
- -Raphael
P.S.: *please* don't ask any questions about DEU 5.3. It will be
released as soon as I have received all contributions from
the other developpers. That's all I can say about it.
------------------------------
End of doom-editing-digest V1 #21
*********************************
