Copy Link
Add to Bookmark
Report
Doom Editing Digest Vol. 01 Nr. 309
From: owner-doom-editing-digest
To: doom-editing-digest@nvg.unit.no
Subject: doom-editing-digest V1 #309
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk
doom-editing-digest Friday, 9 June 1995 Volume 01 : Number 309
Considerations on 3D engi
Shoot-Walls
Re: Shoot-Walls
Re: Shoot-Walls
Re: Shoot-Walls
more on overlayed line-switches
New editing horizons
----------------------------------------------------------------------
From: matt.tagliaferri@pcohio.com (Matt Tagliaferri)
Date: Wed, 07 Jun 1995 18:50:00 -0500
Subject: Considerations on 3D engi
DO>Hello, Pals
DO> I'm about to release an unofficial Terminal Velocity
DO>spec 1.0, I have read the docs on editing Dark Forces
DO>and Descent, and of course I know a bit about DOOM/HERETIC.
I have a pretty complete TV Spec, as well as TRI's own
level editor, if there are any ?s here.
matt tagliaferri
author: DoomCAD
author (upcoming) TVCAD
- ---
þ OLX 2.1 TD þ Intel Inside: Smoke on the outside
_ _ --------------------------------------------------------------
|_|_| PC-Ohio PCBoard OLS pcohio.com HST 16.8: 216-381-3320
|_|_| The Best BBS in America Cleveland, OH V34 28.8: 216-691-3030
--------------------------------------------------------------
------------------------------
From: martin.rudolph@jrc.it (Martin Rudolph)
Date: Thu, 08 Jun 1995 09:39:37 +0200
Subject: Shoot-Walls
Hi, there
does anyone like the walls, which are in the 'Dark Forces' Game? They can
be opened by a Mine Explosion or something similar.
I liked them that much, that I wanted to make an implementation for DooM -
but there are some limitations by the available linedefs.
First there is no linedef switch to change the view of a sidedef by free
choice - but this can be circumvented by redefinition of a SW1_xxx and
the respective SW2_xxx texture. So you define the SW1_xxx texture as a
wall with a fraction and the SW2_xxx texture as a wall with a huge hole
as it would be caused by the rocket launcher (he, he !)
Both textures should be one patch textures, the big hole is cyan coloured
to make it transparent in the game.
I could only find a G1 Door, a G1 raising floor and a G1 lowering floor.
Forget the G1 Door, after 3 secs the wall texture switches back to SW1_xxx,
so what's left is the G1 raising floor and the G1 low. floor.
With the G1 r. Fl. you can make now a door which can be passed only after
it has been shot at:
__________________________________________
| | |
| _____ I |
| |_|_|< a>I |
|____________________|___________________|
Excuse my poor ASCII art.
The left big sector is at, let's say, floor height 0, the right one at
floor height 26. The linedef I is 'G1 raise floor', is passable and has the
newly designed sidedef SW1_xxx as first and SW2_xxx as second sidedef.
The left small sector is at floor height 2, the right small sector at fl.-
height 0 and can be raised by 2 by shooting at I. The distance a should be
just enough to jump, using our small 'ramp', from the left to the right
sector.
Now without shooting, you cannot reach the second sector because of the
height difference. If you shoot, the wall texture changes from 'fracture'
to 'big hole' and the second 'ramp' sector is raised -> now you can pass
from the left to the right sector.
Does anybody know - are there any other implementations ?
There is still a drawback - the wall opens, even if it's shot with
a pistol. There could be a way around this - is it possible to design
an invisible sprite (i.e. by redefining the exploding barrel) with
DeHacked, which blocks the linedef and has to be shot by a rocket launcher ?
Any suggestions welcome.
If someone is interested, I can post him my mini-wad to see how it looks
like
Ciao
Martin
|---> Martin P. W. Rudolph <---|"Live's a piece of shit, if you look at it"
|-----> rudolph@ei.jrc.it <----| The Monty Python Troup
------------------------------
From: S.Benner@lancaster.ac.uk (Steve Benner)
Date: Thu, 8 Jun 95 10:15:43 +0100
Subject: Re: Shoot-Walls
At 9:39 am 8/6/95, Martin Rudolph wrote:
[snip]
>With the G1 r. Fl. you can make now a door which can be passed only after
>it has been shot at:
[snip]
>Now without shooting, you cannot reach the second sector because of the
>height difference. If you shoot, the wall texture changes from 'fracture'
>to 'big hole' and the second 'ramp' sector is raised -> now you can pass
>from the left to the right sector.
>There is still a drawback - the wall opens, even if it's shot with
>a pistol.
And doesn't open if shot at with rockets or plasma: G1 lines are only
activated by bullets, fists and the chainsaw. Or does this not hold true
for the floor movers?
Think you mean "Life"--+
|
V
>|---> Martin P. W. Rudolph <---|"Live's a piece of shit, if you look at it"
>|-----> rudolph@ei.jrc.it <----| The Monty Python Troup
>
------------------------------
From: Denis.Moeller@kiel.netsurf.de (Denis)
Date: Thu, 8 Jun 95 16:53 GMT
Subject: Re: Shoot-Walls
>>There is still a drawback - the wall opens, even if it's shot with
>>a pistol.
>And doesn't open if shot at with rockets or plasma: G1 lines are only
>activated by bullets, fists and the chainsaw. Or does this not hold true
>for the floor movers?
Dunno, but I remember playing a level some months ago where a rocket
activated a lift. It just had to fly over the lindef. Is this still active
in Doom 2, or am I just ... ?
If it is, couldn't it be used some way for this trick?
cya
Denis
[] Denis Moeller, author of NWT v1.3 and TiC's WAD Reviews. []
[] Just play our Doom (2) Add-Ons: Sudtic, Teutic, Obtic. Thanks. []
------------------------------
From: mneves@venus.rdc.puc-rio.br (Marcus Vinicius de A.B. Neves)
Date: Thu, 8 Jun 1995 14:41:03 -0300 (BSC)
Subject: Re: Shoot-Walls
> does anyone like the walls, which are in the 'Dark Forces' Game? They can
> be opened by a Mine Explosion or something similar.
Yes, this is a great effect. But, it would be nice to have that grenades on hand
too... ;-)))
> If someone is interested, I can post him my mini-wad to see how it looks
> like
Yeah, I would like to see it. Could you mail it to me? :-)
*--------------------------------------*-------------------------------------*
| ()s, | |
| Marcus Vinicius Neves | "In the depths of a mind insane |
| Internet: mneves@eros.rdc.puc-rio.br | Fantasy and reality are the same." |
| | -Slayer |
*--------------------------------------*-------------------------------------*
------------------------------
From: a13231@mindlink.bc.ca (drake o'brien)
Date: Thu, 08 Jun 95 10:22:39 PST
Subject: more on overlayed line-switches
OK, for everyone who isn't totally sick of this topic I've got an
interesting variation.
I'll explain a simple case with no overlayed line-switches first.
Create a wall-switch with a SW1x texture and S1x linetype, and hide this
wall behind a dummy wall with a dummy switch. Nearby, create an
independent linedef on which a transparentable animation will run, and
give its right sidedef the identical sidedef # as the right sidedef of
the S1x linetype (WinDEU will allow you to do this). Now redefine the
SW1x texture as a mid-frame in a transparentable animation and sandwich
this new texture definition between the ANIMATION1 START and ANIMATION1
END textures. Redefine the SW2x texture as a mid-frame in a second
transparentable anim, and sandwich it between ANIMATION2 START and
ANIMATION2 END textures.
Now when you enter the area you see ANIMATION1 playing, then when you hit
the dummy switch and the main action (eg. door opens) occurs you also get
the secondary effect of ANIMATION1 flipping over to ANIMATION2.
You can make the action more interesting by using overlayed
line-switches. Again, hide the real line-switch behind a dummy wall with
dummy switch. In the case I'm thinking of, create a sequence of
independent linedefs 1 pixel apart, on which a sequence of
transparentable animations will run. Redefine a SW1x texture so it's,
say, 2048x128, where the first 128 of the x-axis is regular SW1x texture
and the rest of the x-axis is pure CYAN. Redefine the corresponding SW2x
texture so the first 128 of the x-axis is regular SW2x texture and the
rest of the x-axis consists of mid-frame patches of ANIM1 ANIM2 ANIM3
.... at appropriate x-offsets. Now give the right sidedefs of the
to-be-overlayed lineswitches SW1x textures with the appropriate x-offsets
- - that is, if you want the 3rd to-be-overlayed lineswitch to correspond
to ANIM3, give its right sidedef the offset of ANIM3. Overlay the
line-switches. Now when you enter the area you see no animation playing.
You hit the dummy wall switch and ANIM1 plays on the backmost of the
independent linedefs. Hit the dummy switch again and ANIM2 plays on the
next independent linedef, covering ANIM1 (or maybe just adding to ANIM1,
so by the time ANIM7 or so is playing you have a deep 3-d effect...).
I've only tested this idea in the most rudimentary way - but in my test
the idea worked.
------------------------------
From: Ed Phillips <flaregun@udel.edu>
Date: Thu, 8 Jun 1995 17:58:54 -0400 (EDT)
Subject: New editing horizons
For those of you who are subscribers, here's a nifty little
message that just came across the DJGPP newgroup / mailing list... I
really like the sound of this!
+-------------------------------------------------------------------------+
| Ed Phillips <flaregun@udel.edu> University of Delaware (302) 831-6082 |
| Jr Systems Programmer, Network and Systems Services, Info. Technologies |
| Public key footprint: 1C D4 AC C2 A3 D5 97 AA DB 3B D8 85 88 E7 40 B8 |
| Finger flaregun@udel.edu for PGP public key |
+-------------------------------------------------------------------------+
- ---------- Forwarded message ----------
Date: 8 Jun 1995 14:12:25 -0500
From: Dave Taylor <ddt@npc.ece.utexas.edu>
To: djgpp@sun.soe.clarkson.edu
Newgroups: comp.os.msdos.djgpp
Subject: Please help authors of Doom!
Hello, I'm one of the authors of Doom, and for a while we've been
developing our next game Quake using DJGPP V1. Our plans are to
release the game as a series of .o files and source code so that
programmers can write their own modules and plug them in during the
setup program which actually performs the final link. We will be
including DJGPP on our distribution CDROM to make this easier for
people. Note that we won't be releasing all the source code, just
enough so that people can write their own low-level modules to support
new devices.
The end result will probably be that DJGPP will find itself in the
spotlight this winter. I'm excited about this and have let DJ use our
T1 ftp site as a distribution base for the V2 beta.
However, I am having a problem I could use some help with. I want to
upgrade to DJGPP V2, but I am cross-compiling DJGPP V2 to OSF/1 for the
Alpha. I have never done this before or even mucked around with
compiling gcc. I have been keeping notes on how to do it properly. I
am really really close, and the cross-compiler works. However, the
linker (ld from binutils 2.5.2) chokes with:
/usr/local/i386-msdos-go32/bin/ld:djgpp.lnk:1: parse error
djgpp.lnk is the version that comes with V2, 950603, with the ^M's stripped.
The top line is OUTPUT_FORMAT("coff-go32"). I have tried replacing this with
"i386-coff" and "coff-i386" to no effect.
If someone could help me with this last step, I will post a DJGPP V2
Cross Compiling FAQ, as I found the process rather painful as someone
new to building a gcc cross-compiler.
Thank you for your help.
By the way, we really enjoy working with DJGPP. It's a great package.
However, we have similar beefs about the inability to get directly at
physical memory, and not through using another selector or wrapper
function. I would like very much to see CWSDPMI support fn 0x508, an
optional DPMI v1.0 function, but a terribly useful one because it will
allow you to elegantly map physical memory into your data segment as
though you're malloc'ing memory. This is the only thing keeping the
compiler from making real-time app programmers blissfully happy, and I
hear that it may go in soon. Just wanted to encourage that to happen.
It's so close to perfect!
=-ddt->
------------------------------
End of doom-editing-digest V1 #309
**********************************
