Copy Link
Add to Bookmark
Report
Doom Editing Digest Vol. 01 Nr. 135
From: owner-doom-editing-digest
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #135
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk
doom-editing-digest Wednesday, 25 January 1995 Volume 01 : Number 135
Distance formula
Re: Another DEU feature suggestions
Re: Another DEU feature suggestions
Re: Another DEU feature suggestions
Re: Distance formula
Re: Another DEU feature suggestions
More on Things collisions
Re: Another DEU feature suggestions
Re: More on Things collisions
RE: Another DEU Feature Suggestion
RE: Another DEU Feature Suggestion
RE: Another DEU Feature Suggestion
RE: Another DEU Feature Suggestion
----------------------------------------------------------------------
From: matt.tagliaferri@pcohio.com (Matt Tagliaferri)
Date: Mon, 23 Jan 1995 12:12:00 -0500
Subject: Distance formula
Would anyone have the formula for the distance of point <x,y> to
LineSegment <x1,y1>,<x2,y2>? I'm trying to code the Integrity Checker
in dCAD 6.0 for thing distance to lDefs. Can't seem to find it in any
of my home references.
matt tag
PS: We're getting pretty close on making dCAD 6.0 100% BOB Compliant for
consistency checking.
- ---------------------------------------------------------------
PC-Ohio PCBoard pcohio.com
The Best BBS in America Cleveland, OH
DATA: 216-381-3320 FAX: 216-291-2685
- ---------------------------------------------------------------
------------------------------
From: "Kram Llens" <MSNELL@kitsune.art.rmit.edu.au>
Date: Tue, 24 Jan 1995 13:58:29 EST-10
Subject: Re: Another DEU feature suggestions
Hi all,
>
> I have a real small batch file (RUN.BAT) that looks like this:
>
> :A
> DEU -file %1.WAD
> PUTKBD \r <-- clears the annoying "DOOM modified;
> DOOM -file %1.WAD press return to go on" message
> GOTO A
>
instead of the putkbd \r, why not just make the next line:
doom -file %1.wad <run.bat
This also gets rid of the message,and it saves loading a tsr, and
works fine (for me). :)
Kram
Kram_Llens@rmit.edu.au RMIT, Melbourne, Australia
Ph (03) 660 5378 Fax (03) 660 5342
"I bought some dehydrated water, but I don't
know what to add to it" -Steven Wright
------------------------------
From: <jdh15@po.cwru.edu>
Date: 24 Jan 1995 06:23:12 GMT
Subject: Re: Another DEU feature suggestions
> Hi all,
> >
> > I have a real small batch file (RUN.BAT) that looks like this:
> >
> > :A
> > DEU -file %1.WAD
> > PUTKBD \r <-- clears the annoying "DOOM modified;
> > DOOM -file %1.WAD press return to go on" message
> > GOTO A
> >
> instead of the putkbd \r, why not just make the next line:
> doom -file %1.wad <run.bat
> This also gets rid of the message,and it saves loading a tsr, and
> works fine (for me). :)
As one gut said, this really has little to do with DOOM editing,
but let me just clear one thing up: PUTKBD isn't a TSR, it just
stuffs keys (in this case, a single <ENTER> keypress) into the
keyboard buffer, thus clearing the annoying press enter message.
As you may recall, I originally posted this because I though a /RUN
paramater for DEU would be nice to bring extra keystrokes to 0.
If anyone is interested in getting PUTKBD.COM (it's very small) I
doubt my friend who wrote it would mind. Reply via private email,
though, because this rally doesn't belong on DOOM-editing anymore.
- -j :)
==============================================================================
I went into the store the other day, to buy myself a loaf of bread.
But when I got there, I couldn't find any, no matter how hard I looked.
So I asked the store manager about it, and he said,
I'm sorry, but we don't carry bread anymore....
==============================================================================
Jeremy Holland Case Western Reserve University
(216) 754-1343 jdh15@po.cwru.edu
Sherman House #316
==============================================================================
------------------------------
From: Ian Springer <ips@eden.rutgers.edu>
Date: Tue, 24 Jan 95 3:10:25 EST
Subject: Re: Another DEU feature suggestions
plz mail me PUTKBD...thanx.
- ------------------------< Ian Springer (RC '98) >----------------------------
ips@eden.rutgers.edu (general) ips@remus.rutgers.edu (computer science)
ips@usacs.rutgers.edu (USACS) ips@gandalf.rutgers.edu (honors program)
- -----------------------------------------------------------------------------
------------------------------
From: eedraq@chapelle.eed.ericsson.se (Raphael Quinet)
Date: Tue, 24 Jan 95 11:19:38 +0100
Subject: Re: Distance formula
> Would anyone have the formula for the distance of point <x,y> to
> LineSegment <x1,y1>,<x2,y2>? I'm trying to code the Integrity Checker
> in dCAD 6.0 for thing distance to lDefs. Can't seem to find it in any
> of my home references.
>
Well, you don't need it. :-) I suppose that you want to use this formula
to see check if a Thing is stuck in a wall. Given the way Doom checks for
collisions, testing the distance is not the good solution.
In Doom, things are not circular, they are square! The Doom engine does not
calculate the real distance, but compares the coordinates instead (X and Y
separately). So, instead of checking if the circle enclosing a Thing (i.e.
real distance) intersects with a LineDef, you have to do the test with a
square (separate coords).
Here is some ASCII art to show you what to look for:
* (x1,y1) * LineDef
\ \
+-----+ \ +---\-+
| | \ LineDef | \|
| * | \ | * \
|(x,y)| \ | |\
+-----+ \ +-----+ \
Thing * (x2,y2) Thing *
Fortunately, there is already an algorithm to do that: in DEU, I have a
function called "IsLineDefInside", which checks if a LineDef intersects a
given box. You will find this function in OBJECTS.C, in the DEU 5.21
source code (or M_OBJECT.C in the forthcoming DEU 5.3 source code). It
should be easy to include this routine in your program.
> PS: We're getting pretty close on making dCAD 6.0 100% BOB Compliant for
> consistency checking.
>
You are not alone. :-) For the moment, DEU 5.3 should be around 80%. But
I'm trying to do more than 100%...
By the way, thanks to all who are posting suggestions for DEU on this list.
Even if I don't reply, I add them to my list of things to do, and sometimes
I add them directly in the code.
- -Raphael
------------------------------
From: bmetz@gcr.com (Brent Metz)
Date: Tue, 24 Jan 1995 05:37:12 -0500 (EST)
Subject: Re: Another DEU feature suggestions
By far the easiest way to skip the WAD prompt in doom is to type
ECHO . | DOOM -file %1
See, isn't that easy? (Works fine for me)
- --
Brent Metz -- bmetz@gcr.com & bmetz@tjhsst.edu
WWW : http://www.tjhsst.edu/home/earth/bmetz/
------------------------------
From: eedraq@chapelle.eed.ericsson.se (Raphael Quinet)
Date: Tue, 24 Jan 95 13:05:46 +0100
Subject: More on Things collisions
As I wrote in my previous message, the Doom engine uses "square" Things
instead or "round" Things. This saves several computations. Computing the
distance between a circle and a line segment is not trivial: one might be
tempted to calculate the distance between the center of the circle (the
Thing coordinates) and the line, then to check if the distance is greater
than the radius of the circle, for example. This would not work, because
we have a line segment, not a whole line.
Warning: ASCII art ahead (I know my circle sucks)...
* (x1,y1) In this example, you see that the distance from the
| line (":") to the point (x0,y0) is shorter than the
| distance from the line segment (in this case, it's
| the distance from (x2,y2)).
* (x2,y2)
: _____ If the radius of the circle was a bit larger, it could
: / \ be greater than the distance from the center to the
: /(x0,y0)\ line, while still being smaller than the distance from
:...|....* | the center to the segment. You would then detect a
: \ / "false" collision.
\_____/
Fortunately, Doom uses a simpler approach with "square" Things, so you only
have to compare the coordinates of a box surrounding the Thing with the
line segment. This is what I do in the function "IsLineDefInside", in the
DEU source code.
Here is the function, taken from the DEU 5.3 source code:
- ----- cut here ----- cut here ----- cut here ----- cut here -----
Bool IsLineDefInside(LevelPtr level, Int16 ldnum, Int16 x0, Int16 y0,
Int16 x1, Int16 y1)
{
Int16 lx0 = level->vertexes[level->linedefs[ldnum].start].x;
Int16 ly0 = level->vertexes[level->linedefs[ldnum].start].y;
Int16 lx1 = level->vertexes[level->linedefs[ldnum].end].x;
Int16 ly1 = level->vertexes[level->linedefs[ldnum].end].y;
Int16 i;
if (lx0 >= x0 && lx0 <= x1 && ly0 >= y0 && ly0 <= y1)
return TRUE; /* the LineDef start is entirely inside the square */
if (lx1 >= x0 && lx1 <= x1 && ly1 >= y0 && ly1 <= y1)
return TRUE; /* the LineDef end is entirely inside the square */
if ((ly0 > y0) != (ly1 > y0))
{
i = lx0 + (Int16) ((Int32) (y0 - ly0) * (Int32) (lx1 - lx0)
/ (Int32) (ly1 - ly0));
if (i >= x0 && i <= x1)
return TRUE; /* the LineDef crosses the y0 side (left) */
}
if ((ly0 > y1) != (ly1 > y1))
{
i = lx0 + (Int16) ((Int32) (y1 - ly0) * (Int32) (lx1 - lx0)
/ (Int32) (ly1 - ly0));
if (i >= x0 && i <= x1)
return TRUE; /* the LineDef crosses the y1 side (right) */
}
if ((lx0 > x0) != (lx1 > x0))
{
i = ly0 + (Int16) ((Int32) (x0 - lx0) * (Int32) (ly1 - ly0)
/ (Int32) (lx1 - lx0));
if (i >= y0 && i <= y1)
return TRUE; /* the LineDef crosses the x0 side (down) */
}
if ((lx0 > x1) != (lx1 > x1))
{
i = ly0 + (Int16) ((Int32) (x1 - lx0) * (Int32) (ly1 - ly0)
/ (Int32) (lx1 - lx0));
if (i >= y0 && i <= y1)
return TRUE; /* the LineDef crosses the x1 side (up) */
}
return FALSE;
}
- ----- cut here ----- cut here ----- cut here ----- cut here -----
This function could be optimized, but it should at least show you how to
do the comparisons. I hope this helps...
- -Raphael
------------------------------
From: Ian Springer <ips@eden.rutgers.edu>
Date: Tue, 24 Jan 95 11:24:50 EST
Subject: Re: Another DEU feature suggestions
> By far the easiest way to skip the WAD prompt in doom is to type
> ECHO . | DOOM -file %1
> See, isn't that easy? (Works fine for me)
> --
> Brent Metz -- bmetz@gcr.com & bmetz@tjhsst.edu
> WWW : http://www.tjhsst.edu/home/earth/bmetz/
>
nope, it is even easier to type ECHO | DOOM -file %1 :)
- ------------------------< Ian Springer (RC '98) >----------------------------
ips@eden.rutgers.edu (general) ips@remus.rutgers.edu (computer science)
ips@usacs.rutgers.edu (USACS) ips@gandalf.rutgers.edu (honors program)
- -----------------------------------------------------------------------------
------------------------------
From: David Damerell <djsd100@hermes.cam.ac.uk>
Date: Tue, 24 Jan 1995 18:13:46 +0000 (GMT)
Subject: Re: More on Things collisions
On Tue, 24 Jan 1995, Raphael Quinet wrote:
> As I wrote in my previous message, the Doom engine uses "square" Things
> instead or "round" Things. This saves several computations. Computing the
> distance between a circle and a line segment is not trivial: one might be
> tempted to calculate the distance between the center of the circle (the
> Thing coordinates) and the line, then to check if the distance is greater
> than the radius of the circle, for example. This would not work, because
> we have a line segment, not a whole line.
It's still fairly trivial: you find the general equation of the
perpendicular (one inversion), find the specific line with that gradient
intersecting the circle centre (more trivial numbers), and then find
where that perpendicular intersects the line (also pappy) and then a
final test to see if the point you get is on the segment: if not, you
test range (Pythagoras, only don't take the square root because you have
the square of the object size stored, right?) to the nearer vertex.
But that's all irrelevant, I suppose.
David Damerell, GCV Sauricon. djsd100@hermes.cam.ac.uk Trinity, Cambridge
WOODHAL2.WAD ftpable. CUWoCS President. METLMAZE.WAD sometime soonish.
|___| Loneliness pours over you: Emptiness can pull you through. |___|
| | | Your mother's eyes, from your eyes, cry to me... Queen, '39. | | |
------------------------------
From: l-sieben@MEMPHIS.EDU (ulasieben)
Date: Tue, 24 Jan 1995 16:27:16 -0500 (CDT)
Subject: RE: Another DEU Feature Suggestion
I didn't have anything to quote, but it falls under this category, so here
goes...
I had the idea recently that maybe DEU (or any other editor for that matter)
could allow users to write functions in C, compile them somehow, and run them
from DEU. These routines could do things like create a certain type of stairs,
make a series of special rooms, etc... This could be very useful if possible.
The idea is that DEU would pass its information along to the new C functiom
and the function would do its thing. This could allow people to write DOOM
editing libraries of code that inserts objects. It would be very useful. But,
the only problem is finding a way to link compiled C functions to an existing
program. The only way I can think of is to use a DLL, but that would probably
be very hard to port. Still, if this could be done, I think it would make for
a very good editor. Any ideas on how to write this?
-- Evil Genius (Jimmy Sieben)
------------------------------
From: l-sieben@MEMPHIS.EDU (ulasieben)
Date: Tue, 24 Jan 1995 16:27:13 -0500 (CDT)
Subject: RE: Another DEU Feature Suggestion
I didn't have anything to quote, but it falls under this category, so here
goes...
I had the idea recently that maybe DEU (or any other editor for that matter)
could allow users to write functions in C, compile them somehow, and run them
from DEU. These routines could do things like create a certain type of stairs,
make a series of special rooms, etc... This could be very useful if possible.
The idea is that DEU would pass its information along to the new C functiom
and the function would do its thing. This could allow people to write DOOM
editing libraries of code that inserts objects. It would be very useful. But,
the only problem is finding a way to link compiled C functions to an existing
program. The only way I can think of is to use a DLL, but that would probably
be very hard to port. Still, if this could be done, I think it would make for
a very good editor. Any ideas on how to write this?
-- Evil Genius (Jimmy Sieben)
------------------------------
From: dubois@quark.geoworks.com (Paul DuBois)
Date: Tue, 24 Jan 95 15:52:58 PST
Subject: RE: Another DEU Feature Suggestion
>>>>> ulasieben writes:
> I had the idea recently that maybe DEU (or any other editor for that matter)
> could allow users to write functions in C, compile them somehow, and run them
> from DEU. These routines could do things like create a certain type of stairs,
> make a series of special rooms, etc...
Embed an interpreter (such as TCL) instead.
------------------------------
From: Anthony Spataro <ads@netcom.com>
Date: Tue, 24 Jan 1995 16:13:47 -0800 (PST)
Subject: RE: Another DEU Feature Suggestion
This has limited use for a game like Doom where the only thing you can do
is change linedefs; and Quake should be along presently with its own
built-in Tcl-like (or was it Forth-like?) interpreter. But, hey, who
knows, it may be worth doing.
I've seen something similar to this before. TADS, an text-advanture
system, lets you link C-compiled .OBJ files into games it compiles, and
you can make function calls to the main() in each .OBJ from your TADS
source. The problem is, TADS itself is a compiler, and DEU isn't. I'm
not sure if it can be done easily with a precompiled executable. Also,
the TADS support for it is very buggy and tends to crash if you call I/O
interrupts (which is really the only reason why you'd want to link in
your own code anyway, in a TADS game).
In any case, it would ruin DEU's portability without some major work.
But I see what you're getting that, it could come in handy.
Alternatives are a DEU macro system, a simple DEU interpreter, and a
small, well-documented library of C functions that C programmers can use
to write a "skeleton" WAD (i.e. only information about vertices, linedefs
and sectors relative position is stored) which DEU can then load and
flesh out, asking the user to supply values when necessary.
/ads@netcom.com
[LC/Cardy/Kilwren/Cardenyl
\PASO/Paradigm/Storm
---------------------------->
Non-Reciprocal Laws of Expectations:
Negative expectations yield negative results.
Positive expectations yield negative results.
On Tue, 24 Jan 1995, ulasieben wrote:
> I had the idea recently that maybe DEU (or any other editor for that matter)
> could allow users to write functions in C, compile them somehow, and run them
> from DEU. These routines could do things like create a certain type of stairs,
> make a series of special rooms, etc... This could be very useful if possible.
> The idea is that DEU would pass its information along to the new C functiom
> and the function would do its thing. This could allow people to write DOOM
> editing libraries of code that inserts objects. It would be very useful. But,
> the only problem is finding a way to link compiled C functions to an existing
> program. The only way I can think of is to use a DLL, but that would probably
> be very hard to port. Still, if this could be done, I think it would make for
> a very good editor. Any ideas on how to write this?
> -- Evil Genius (Jimmy Sieben)
>
>
------------------------------
End of doom-editing-digest V1 #135
**********************************
