Copy Link
Add to Bookmark
Report

Doom Editing Digest Vol. 01 Nr. 137

eZine's profile picture
Published in 
Doom editing
 · 7 months ago

From:      owner-doom-editing-digest 
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #137
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk


doom-editing-digest Friday, 27 January 1995 Volume 01 : Number 137

HERETIC EDITING
Re: RE: Another DEU Feature S...
Windows Node building
Re: Doom-Heretic wad Converter
Re: Windows Node building
Re: Windows Node building
Re: RE: Another DEU Feature S...

----------------------------------------------------------------------

From: chall@tcpet.uscg.mil
Date: Wed, 25 Jan 95 18:14:23 -0800
Subject: HERETIC EDITING

1) Once in a while, when I try to give a sector the "light-flicker" or
"light-glow" properties, the sector will not flicker or glow. I am using
the editor HEU, a similiar bug can be found in any HEU or DEU type editor...
Can someone tell me if I am doing something wrong or if the editor is messed up?

2) Does anyone have a complete listing of decimal numbers for HEU?

3) How do I make an "underwater" sector?

If anyone can help... I appreciate it ; )


------------------------------

From: l-sieben@MEMPHIS.EDU (ulasieben)
Date: Wed, 25 Jan 1995 22:58:18 -0500 (CDT)
Subject: Re: RE: Another DEU Feature S...

>
>> As opposed to haveing DEU jump to external C routines (which would be
>> fiendishly difficult to implement), why not have DEU support a 'script' file
>> of some sort, with the commands listed in a format that even non-programmers
>> could use? would be smaller and more portable; and EVERYONE could use it!
>
>I wholeheartedly agree. Although I should go ahead and learn C, I
>haven't yet. I would, however, like some kind of macro language to
>use with DEU for completing repetitive tasks which are too specific
>to my levels to warrant inclusion in the actual DEU code. It could
>be relatively simple, as long as it supported basic DEU operations
>like select, move, delete, insert, and edit attributes. It would
>also be nice if you could pass it parameters in the form of selected
>item(s) and be able to enter data. (Like have a command that calls
>up the choose wall texture dialog)
>
>If you guys working on DEU decide to definitely add this feature,
>I'm sure people will have specific suggestions on what to include
>and what's superfluous.
That's what I intended when I suggested this feature. Have a scripting
language like many DOS applications have: dbase, etc... The script files
would be able to somehow call DEU functions, like those that create message
boxes, etc... This could be useule if written. I would like to get a start
on writing it for DEU 6.0. This would be a very nice feature, I think,
because it would make level design *so* easy. If anyone would like to help
me, or have any ideas, I would appreciate them.
-- Evil Genius (Jimmy Sieben)

------------------------------

From: matt.tagliaferri@pcohio.com (Matt Tagliaferri)
Date: Wed, 25 Jan 1995 19:41:00 -0500
Subject: Windows Node building

I was wondering if any of the Windows editor authors out there
(or Raphael) would be interested in compiling the node building
routines as a DLL. My node builder is still a bit buggy and I
really don't have the time (or inkling) to debug it.

Another routine I'm looking for is what sector is point <x,y> in,
as many of Bob's Consistency Checker rules need such a routine.

I have one written, but it's DOG slow.

matt tag
- ---
þ OLX 2.1 TD þ Intel Inside: Smoke on the outside

- ---------------------------------------------------------------
PC-Ohio PCBoard pcohio.com
The Best BBS in America Cleveland, OH
DATA: 216-381-3320 FAX: 216-291-2685
- ---------------------------------------------------------------

------------------------------

From: David Shoemaker (B.E.S.T.) <a-bds@microsoft.com>
Date: Thu, 26 Jan 95 09:32:23 PST
Subject: Re: Doom-Heretic wad Converter

I am pretty good with C :)

If you want to send me the code and a description on where the problem
is I can take a look.

David
- ----------
From: "Jason Hoffoss" <hoffo002@gold.tc.umn.edu>
To: <doom-editing@nvg.unit.no>
Subject: Re: Doom-Heretic wad Converter
Date: Wednesday, January 25, 1995 6:30PM

On Wed, 25 Jan 95 00:40:27 -0800,
chall@tcpet.uscg.mil <chall@tcpet.uscg.mil> wrote:

>Can someone recomend a good doom1 --> heretic pwad converter or a doom ][
>---> heretic pwad converter.
>
>-Thanks

I have written one, but I ran into a big bug I'm trying to track down. If
you are a C programmer or anything, I can send you a copy if you are
interested in trying to help find it. As far as I know, there aren't any
others out anywhere.

-Jason


------------------------------

From: Robert Forsman <thoth@cis.ufl.edu>
Date: Thu, 26 Jan 1995 12:57:52 EST
Subject: Re: Windows Node building

matt.tagliaferri@pcohio.com (Matt Tagliaferri) ,in message <24.105972.5@pcohio.
com>, wrote:

> Another routine I'm looking for is what sector is point <x,y> in,
> as many of Bob's Consistency Checker rules need such a routine.
>
> I have one written, but it's DOG slow.

This one doesn't seem to be dog slow, but I'm on a 486DX2 and using gcc.

/* find the first "sidedef" to the right of this vertex */
void mission::scan_for_sidedef_right
(const vertex &v, int *lno_ret, int *sd_ret) const
{
*lno_ret = -1;
*sd_ret = -1;
double best_ix=0; // x of best linedef\'s intersection
// double biggest_cos=-2;
double least_cos=2;
int i;
for (i=0; i<nlinedefs_(); i++) {
const linedef & curr = linedef_(i);
if (!curr.vertbounds(*this))
continue;
const vertex & v0 = vertex_(curr.v[0]);
const vertex & v1 = vertex_(curr.v[1]);

if (v0.y==v1.y)
continue; // we don\'t care about horizontal lines

int side;
if (v0.y<=v.y && v.y<=v1.y) {
side = 1; // left side
} else if (v1.y<=v.y && v.y<=v0.y) {
side = 0; // right side
} else {
// linedef does not cross our y
continue;
}
double ix;
ix = (v.y-v0.y)/double(v1.y-v0.y) * (v1.x-v0.x) + v0.x;
if (ix>v.x && ( *lno_ret==-1 ||
ix<=best_ix)) {
double curr_cos = (v1.x-v0.x) / curr.Dlength(*this);
if (v.y == v0.y) {
// curr_cos stays the same
} else if (v.y == v1.y) {
curr_cos = -curr_cos;
} else if (curr_cos>0) {
curr_cos = -curr_cos;
}
if (*lno_ret>=0 && best_ix==ix) {
#if 0
printf("cosine check on linedef %d results in %g <? %g\n",
i, curr_cos, least_cos);
#endif
if (curr_cos>least_cos)
continue; //
}
best_ix = ix;
least_cos = curr_cos;
*lno_ret = i;
*sd_ret = side;
}
}

}

------------------------------

From: eedraq@chapelle.eed.ericsson.se (Raphael Quinet)
Date: Thu, 26 Jan 95 21:14:49 +0100
Subject: Re: Windows Node building

Matt wrote:
> I was wondering if any of the Windows editor authors out there
> (or Raphael) would be interested in compiling the node building
> routines as a DLL. My node builder is still a bit buggy and I
> really don't have the time (or inkling) to debug it.
>
The new Nodes builder in DEU 5.3 is different from the one in the
previous versions of DEU, and will be suitable for that. But how
do you want to integrate this in a DLL? We need some sort of
common structures for the level data (Vertexes, LineDefs, ...).
In DEU 5.3, I only have to call the new Nodes builder with a
pointer to a structure containing all the data for the level (this
structure is a new feature of DEU 5.3). But I doubt that your
program will use the same structures, so what can we do?

> Another routine I'm looking for is what sector is point <x,y> in,
> as many of Bob's Consistency Checker rules need such a routine.
>
> I have one written, but it's DOG slow.
>
Here is the routine I use in M_CHECKS.C (the consistency checker of
DEU 5.3):

- ----- cut here ----- cut here ----- cut here ----- cut here -----
/*
Get the Sector in which a Thing is, or -1 if it is outside the map.
*/


Int16 GetSectorForThing(LevelPtr level, UInt16 thingnum)
{
TPtr tptr;
Int16 n, x, bestx;
Int16 lx0, ly0, lx1, ly1;
LDPtr ldptr, bestldptr;

tptr = &(level->things[thingnum]);
/* I look for the first LineDef crossing an horizontal half-line drawn */
/* from the thing */
bestx = level->map_maxX + 1;
bestldptr = NULL;
ldptr = level->linedefs;
for (n = 0; n < level->num_linedefs; n++)
{
if ((level->vertexes[ldptr->start].y > tptr->ypos)
!= (level->vertexes[ldptr->end].y > tptr->ypos))
{
lx0 = level->vertexes[ldptr->start].x;
ly0 = level->vertexes[ldptr->start].y;
lx1 = level->vertexes[ldptr->end].x;
ly1 = level->vertexes[ldptr->end].y;
x = lx0 + (Int16) ((Int32) (tptr->ypos - ly0) * (Int32) (lx1 - lx0)
/ (Int32) (ly1 - ly0));
if (x >= tptr->xpos && x < bestx)
{
bestx = x; /* lower X = closer */
bestldptr = ldptr; /* store the LineDef pointer */
}
}
ldptr++;
}
if (bestldptr == NULL)
return -1;
/* now look if this LineDef has a SideDef bound to one sector */
if (level->vertexes[bestldptr->start].y > level->vertexes[bestldptr->end].y)
n = bestldptr->sidedef1;
else
n = bestldptr->sidedef2;
if (n >= 0)
return level->sidedefs[n].sector;
else
return -1;
}

- ----- cut here ----- cut here ----- cut here ----- cut here -----

There is probably a better way to do it, but it works.

I think the best way is to use a dynamic blockmap in the editor. This
means that the map editor should always keep a structure like the blockmap
stored in the WAD, and update it when LineDefs are added, moved or deleted.

Even if this slows down the creation of new objects in the WAD and require
an increased amount of memory, this will have several advantages:
- - faster updates of the map display: you only have to draw the LineDefs
including in the visible blocks.
- - faster detection of when an object (or the mouse pointer) is inside a
sector.
- - can be written to the WAD file very easily, because it's already in
memory.

In most cases, the editor would only have to check 5 or 6 LineDefs instead
of 100 or 1000. Big speed increase! I am seriously considering this for
DEU 6.0.

- -Raphael

------------------------------

From: eedraq@chapelle.eed.ericsson.se (Raphael Quinet)
Date: Thu, 26 Jan 95 21:22:51 +0100
Subject: Re: RE: Another DEU Feature S...

[... adding a scripting language to DEU ...]
> >If you guys working on DEU decide to definitely add this feature,
> >I'm sure people will have specific suggestions on what to include
> >and what's superfluous.
> That's what I intended when I suggested this feature. Have a scripting
> language like many DOS applications have: dbase, etc... The script files
> would be able to somehow call DEU functions, like those that create message
> boxes, etc... This could be useule if written. I would like to get a start
> on writing it for DEU 6.0. This would be a very nice feature, I think,
> because it would make level design *so* easy. If anyone would like to help
> me, or have any ideas, I would appreciate them.

You are welcome to join the DEU team if you want to contribute. Actually,
I tought about adding a scripting language to DEU some time ago. I even
added some comments about it in the source code for 5.3. Since DEU is
moving towards an all-graphics interface, I didn't want to loose the ability
to use DEU from batch files (feeding input to the DEU text menu). So a kind
of scripting language would be useful. But, as I wrote previously, this is
for later...

I think it will be easier to use a WAD-oriented language rather than an
existing language. And if we use an existing language, I would prefer
Emacs-lisp or Perl rather than Tcl, because the former ones are more
powerful and flexible.

- -Raphael

------------------------------

End of doom-editing-digest V1 #137
**********************************

← previous
next →
loading
sending ...
New to Neperos ? Sign Up for free
download Neperos App from Google Play
install Neperos as PWA

Let's discover also

Recent Articles

Recent Comments

Neperos cookies
This website uses cookies to store your preferences and improve the service. Cookies authorization will allow me and / or my partners to process personal data such as browsing behaviour.

By pressing OK you agree to the Terms of Service and acknowledge the Privacy Policy

By pressing REJECT you will be able to continue to use Neperos (like read articles or write comments) but some important cookies will not be set. This may affect certain features and functions of the platform.
OK
REJECT