Copy Link
Add to Bookmark
Report

Doom Editing Digest Vol. 01 Nr. 023

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 #23
Reply-To: doom-editing
Errors-To: owner-doom-editing-digest
Precedence: bulk


doom-editing-digest Wednesday, 26 October 1994 Volume 01 : Number 023

Re: Vid Capture into Doom
sublevel .wads? WAS: Re: Wierd Line texture errors
Re: What sector is thing #NN in?
Transparent switches?
Re: things, sectors, blockmap
Re: What sector is thing #NN in?
Re: What sector is thing #NN in?
Re: Transparent switches?
Re: Transparent switches?
Re: What sector is thing #NN
DeuTex 2.5 soon out!
Re: Vid Capture into Doom
Re: Vid Capture into Doom
Re: Transparent switches?
Re: Transparent switches?
Re: DUL/DEL license
Re: Transparent switches?
Re: DeuTex 2.5 soon out!
Transparency color?

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

From: IJOHNSON@kuhub.cc.ukans.edu
Date: Tue, 25 Oct 1994 23:20:58 -0500 (CDT)
Subject: Re: 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.
>
> 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.

I imagine that Doom changes all the colors of green to corresponding
shades of indigo/brown/red, so if my images don't have green, everyone
would be the same color. Also, all the other players would look
like the same person, negating the point of creating our own personal
player sprites. That's why I'm just thinking of MoDoom for this. It
would also be fun to record our own die, wound, and push sounds to go
along with these.

If this works, I think I might make some for public use. For
instance, I have a suit of armor that I wear to fight in the
Society for Creative Anachronism (a medieval recreation group). I
might pose in that with a real sword, and wear something green that
Doom can change to player colors (if that is the way it works). That
way editors could have the players be knights in their
medieval/fantasy/castle themed wads. Or, we could dress as John
Woo Killer types shooting up demons with a gun in each hand.


> 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.

Are these someplace where I could get a look at them? I always
thought anti-aliasing mainly smoothed out edges, i.e. outlines. Does
it help with interior detail as well?

Thanks
Ian


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

From: Stanley Stasiak <stasiak@iinet.com.au>
Date: Wed, 26 Oct 1994 12:22:28 +0800 (WST)
Subject: sublevel .wads? WAS: Re: Wierd 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.
Ugh... duh forgot to change subject on that one... apologies.

Stan.

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

From: fenske@rocke.electro.swri.edu (Robert Fenske Jr)
Date: Wed, 26 Oct 94 08:25:29 CDT
Subject: Re: What sector is thing #NN in?

>WADED has this algorithm to determine which SECTOR the user is clicking
>within. WADED's algorithm first looks upward on the map, and then downward.
>Depending on the direction of the first LINEDEF it hits in each direction,
>it determines which SIDEDEF to pick from each. The SECTOR value of each
>SIDEDEF should be the same, and if they are, you've found what you're looking
>for. If they're different, then the SECTORS haven't been built properly.

This isn't necessarily true. If you are trying for some special
effects like elevated invisible areas or what I call the swimming pool
effect, then you can hit a different sector going up from the sector you
hit going down. In these cases though it's a bit ambiguous as to which
sector you are really in.


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: Gregory Alan Lewis <gregl@umich.edu>
Date: Wed, 26 Oct 1994 10:26:53 -0400 (EDT)
Subject: Transparent switches?

Does anyone know how to create a transparent switch, ie, the switch can
be seen (and activated like normal), but it's on a transparent 2S
linedef? Someone asked me this question and I wasn't able to come up
with anything offhand. Anyone know a solution?

Greg ("Tree")
Author, bunch o' stuff


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

From: Robert Forsman <thoth@cis.ufl.edu>
Date: Wed, 26 Oct 1994 11:11:00 EDT
Subject: Re: things, sectors, blockmap

MSFell@aol.com ,in message <9410251731542505102@aol.com>, wrote:

> 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.

Actually, I've been running around in the void and found myself popping
up and down and getting hurt by nasty floors. It may very well be the
BSP tree as someone else suggested.

> modified question that was asked of me by Frans deVries, he's the
> one who started it...)

Now we know who to egg :)

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

From: Robert Forsman <thoth@cis.ufl.edu>
Date: Wed, 26 Oct 1994 11:21:04 EDT
Subject: Re: What sector is thing #NN in?

fenske@rocke.electro.swri.edu (Robert Fenske Jr) ,in message <9410261325.AA2804
2@rocke.electro.swri.edu>, wrote:

> This isn't necessarily true. If you are trying for some special
> effects like elevated invisible areas or what I call the swimming pool
> effect, then you can hit a different sector going up from the sector you
> hit going down. In these cases though it's a bit ambiguous as to which
> sector you are really in.

Dude, all this talk of BSP trees gives me an idea...

What happens if you generate a BSP tree for a two-level swimming pool,
then go in and edit the linedefs so that instead of pointing to the upper
level outside and the lower level inside, that they point to the upper
level on both sides? Would it eliminate the floor anomolies?

I think you would have to leave a few linedefs outside the map that
referred to the lower sector (I use rooms like this all the time to
control the behavior of visible sectors to achieve effects not normally
doable with the ID linedefs).

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

From: S.Benner@lancaster.ac.uk (Steve Benner)
Date: Wed, 26 Oct 94 15:29:23 GMT
Subject: Re: What sector is thing #NN in?

>Date: Wed, 26 Oct 94 08:25:29 CDT
>From: fenske@rocke.electro.swri.edu (Robert Fenske Jr)
>To: doom-editing@nvg.unit.no
>>WADED has this algorithm to determine which SECTOR the user is clicking
>>within. WADED's algorithm first looks upward on the map, and then downward.
>>Depending on the direction of the first LINEDEF it hits in each direction,
>>it determines which SIDEDEF to pick from each. The SECTOR value of each
>>SIDEDEF should be the same, and if they are, you've found what you're looking
>>for. If they're different, then the SECTORS haven't been built properly.
>
> This isn't necessarily true. If you are trying for some special
>effects like elevated invisible areas or what I call the swimming pool
>effect, then you can hit a different sector going up from the sector you
>hit going down. In these cases though it's a bit ambiguous as to which
>sector you are really in.
>
>

yeh, and if you use WADED's automatic MAKESECTOR feature to build the
sectors for you, and then use Flip to flip a linedef, it flips the sector
info on the line and this is precisely what you get! ooops 8-)

- -Steve



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

From: Robert Forsman <thoth@cis.ufl.edu>
Date: Wed, 26 Oct 1994 11:49:53 EDT
Subject: Re: Transparent switches?

Gregory Alan Lewis <gregl@umich.edu> ,in message <Pine.SOL.3.90a.941026102521.1
4258C-100000@defender.rs.itd.umich.edu>, wrote:

> Does anyone know how to create a transparent switch, ie, the switch can
> be seen (and activated like normal), but it's on a transparent 2S
> linedef? Someone asked me this question and I wasn't able to come up
> with anything offhand. Anyone know a solution?

The "survey of techniques" document about the trinity wad had a
couple of suggestions that I have taken to heart. The one applicable
to this is:

Double the size of a switch and put your switch on the new half.

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

From: "D.J.S. Damerell" <djsd100@cus.cam.ac.uk>
Date: Wed, 26 Oct 1994 16:10:52 +0000 (GMT)
Subject: Re: Transparent switches?

On Wed, 26 Oct 1994, Gregory Alan Lewis wrote:

> Does anyone know how to create a transparent switch, ie, the switch can
> be seen (and activated like normal), but it's on a transparent 2S
> linedef? Someone asked me this question and I wasn't able to come up
> with anything offhand. Anyone know a solution?

Seesm to me you'd need to create a new texture with just the switch on,
and put that on a 2s line.

David Damerell, GCV Sauricon. djsd100@cus.cam.ac.uk RL: Trinity, Cambridge
WOODHAL2.WAD on infant2. CUWoCS President. METLMAZE.WAD sometime soonish.
|___| All people's aims are unreachable, and their struggles futile. |___|
| | | When you see this true of your own aims, life becomes a vacuum. | | |

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

From: mneves@triton.rdc.puc-rio.br (Marcus Vinicius de A.B. Neves)
Date: Wed, 26 Oct 1994 15:08:08 +22295807 (BDB)
Subject: Re: What sector is thing #NN

> I just wrote this algorithm last week for another project: It goes like this:
>
> 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.
>
Hello Matt Tag!

Well, I would apreciate if you could pass yours VB algorithm to us... Could you ?
Another thing is, where can i find the unofficial DOOM specs, for DOOM I & ][ ?
Thanx!

Marcus Vinicius Neves


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

From: Olivier Montanuy <montanuy@LANNION.cnet.fr>
Date: Wed, 26 Oct 1994 19:22:41 +0100
Subject: DeuTex 2.5 soon out!

Hello, fellow PWAD editors!

News about DeuTex/DeuSF, my freeware PWAD composition tools.

To date, they were used on Alien-TC (new install, by me), pcbar10
(a lame sprite demo, still by me), compil1 (a compilation of some great
oldies, once again by me) and Quest12 (hey, this time not by me!)


Now I have the proof I'm not the only one to use it! (well, got some
support e-mail too...). Try it and you'll see it's worth the trouble!


DeuTex 2.5, an update to my tool DeuTex 2.1 should be out very soon.
should fix some of the bugs or limitations (not so many bugs
apparently) and above all it will come for MSDOS, Linux, Unix (SUN) and OS/2.

I say 'soon' because I'm in *very* bad terms with gcc, because of that stupid
long work alignement that never happen under a i486. Don't ask what happened between
version 2.1 and 2.5, I would go real angry. Let's say I found *some* bugs in the compiler!

Still no graphic user interface, because I can't seem to compile a windows
DLL correctly. any pointers, any one? Not to the win31 software Developpment Kit,
I have it, I read it, and it's real troll sh*t.
Windoze sux, we all know, I know for sure. But compare the windoze SDK to
my current DeuTex manual and I'll run away in shame!

Olivier Montanuy

Get deutex21.zip on infant2.sphs.indiana.edu and mirrors, pub/doom/NEWSTUFF
and also on Compuserve (ask Dr Sleep)!




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

From: johnsond@std.teradyne.com (Dean Johnson)
Date: Wed, 26 Oct 94 11:32:23 PDT
Subject: Re: Vid Capture into Doom

IJOHNSON@kuhub.cc.ukans.edu said...

> If this works, I think I might make some for public use. For
> instance, I have a suit of armor that I wear to fight in the
> Society for Creative Anachronism (a medieval recreation group).

Sounds cool. Tho' I'm picturing you in your medieval armor fighting
with a chainsaw!! =)

> > 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.
>
> Are these someplace where I could get a look at them? I always
> thought anti-aliasing mainly smoothed out edges, i.e. outlines. Does
> it help with interior detail as well?

I may be using the term, anti-aliasing, incorrectly (Does anyone here
know?) but the basic concept does apply. The idea is to tweak the
color of each pixel to allow for data that is otherwise lost. So a
smoothed out edge is simulated by replacing the pixels that straddle the
line (i.e. should be half black and half white) with 50% gray (all
white or all black gives you the "jaggies"). The same thing works for
any image, a face for example, maybe you're scaling a face down so much
that the eyes are smaller than your pixels. A pixel sized eye is too
big and will look very bizarre, but no eye will look even worse. If
you pick some color that is a blend of face color and eye color you've
preserved more of the original image. It is a compromise but it can be
fairly effective.

Does that make _any_ sense? For a good example look at the gun barrels
in the head on view of the Spider Boss. I believe each one is only 3x3
pixels but it still looks correct due to the colors selected.

I'm sorry if my long winded explanation isn't appropriate for this
forum. Please let me know if it's not.


If anyone wants to see my beasties, you'd be better off to wait a
little while until I formally release my patches. If you really can't
wait then you can try my initial playtest version for Doom 1.2. This
is playtest only so _please_ don't upload it or post it anywhere.

Find them at: ftp.netcom.com, in the directory: /pub/djohnson/doomshit/sbot.

- -Dean

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

From: Enigma <hsimpson@unixg.ubc.ca>
Date: Wed, 26 Oct 1994 11:46:50 -0700 (PDT)
Subject: Re: Vid Capture into Doom

> I may be using the term, anti-aliasing, incorrectly (Does anyone here
> know?) but the basic concept does apply. The idea is to tweak the
> color of each pixel to allow for data that is otherwise lost. So a
> smoothed out edge is simulated by replacing the pixels that straddle the
> line (i.e. should be half black and half white) with 50% gray (all
> white or all black gives you the "jaggies"). The same thing works for
> any image, a face for example, maybe you're scaling a face down so much
> that the eyes are smaller than your pixels. A pixel sized eye is too
> big and will look very bizarre, but no eye will look even worse. If
> you pick some color that is a blend of face color and eye color you've
> preserved more of the original image. It is a compromise but it can be
> fairly effective.

From my experience with ray tracing, that sounds about right.
>
> Does that make _any_ sense? For a good example look at the gun barrels
> in the head on view of the Spider Boss. I believe each one is only 3x3

I believe the way they did it at id was to paint (onto real paper!) all
of the frames for the spider demon. They then scanned it a high
resolution (relative), and shrank it using some sort of nearest neighbour
algorithm.

This gives the same effect as antialiasing because more pixels were
generated than were actually in the image. Using interpolation,
approximations of the higher resolution image were incorporated into the
low res one. There's one problem with this method, however. The edges of
the objects look more chunky than the interior because they are not
antialiased with the surrounding graphics.

I hope this makes sense and that it's not a futile waste of bandwidth...
but then again... isn't DOOM a waste of bandwidth anyway?? <g>

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

From: Gregory Alan Lewis <gregl@umich.edu>
Date: Wed, 26 Oct 1994 14:50:35 -0400 (EDT)
Subject: Re: Transparent switches?

[ Whoops, forgot the attribution for this one ... ]

> Seesm to me you'd need to create a new texture with just the switch on,
> and put that on a 2s line.

This solution wouldn't work well, because the switch wouldn't change
appearances or generate a switch sound when hit. That was my first
thought also.

And russ@issi.com said ...

> This is not to hard to do. Find the texture-patch for the switch
> graphic of the switch you want to use. (ie: the SW1GRAY texture
> uses SW2S0) Extract this graphic into a gif using DMGRAPH or
> similar extractor. Using a graphics editor, (neopaint, etc..)
> create a gif that's the size of the wall you want (ie: 128x128, 64x128),
> and fill it with cyan (r=min, g=max, b=max). Place the graphic you
> extracted onto the cyan wall and save it.
> The only draw-backs to this are:
> Original ID levels that are not replaced by your level may
> use this texture on a one-sided wall, causing pink-bug.
> Your switch will not change when activated, ie: using the
> same texture above, when you activate SW1GRAY, it changes
> to SW2GRAY (The red light turns on), You cannot replace
> these two textures with clear backgrounds, since they
> are multi-patch textures, and will cause MEDUSA effect.

Yes, those are two problems. I'm looking for a wall replacement that
won't affect Id levels (though that may not be possible, and probably
ultimately isn't too important). But, if what you say about the textures
is true, it may not even be possible to put ANY switch on a 2S linedef,
since all switches are multi-patch. Is this true? If so, there's NO way
to make this happen correctly.

And Robert Forsman suggests ...

> The "survey of techniques" document about the trinity wad had a
> couple of suggestions that I have taken to heart. The one applicable
> to this is:

> Double the size of a switch and put your switch on the new half.

This is the best solution, IF the above assumption is false. Can any
switches be placed on 2S linedefs, due to their multi-patch nature? If
someone can verify this one way or the other I'd much appreciate it. I
don't have Doom right available so I can't whip up a sample myself... :-/

Greg ("Tree")



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

From: Gordon_Mulcaster@mindlink.bc.ca (Gordon Mulcaster)
Date: Wed, 26 Oct 94 12:23:43 -0800
Subject: Re: Transparent switches?

Gregory Alan Lewis (gregl@umich.edu) writes:

> Does anyone know how to create a transparent switch, ie, the switch can be
> seen (and activated like normal), but it's on a transparent 2S linedef?
> Someone asked me this question and I wasn't able to come up with anything
> offhand. Anyone know a solution?

I'm unclear on what you are trying to accomplish? Do you want a switch hanging
in midair?

You could create a patch that is mostly/all transparent (B:255, G:255, R:0--I
think those are the colours), then make a texture using that patch and a
switch patch and stick it on a linedef. This would create a floating switch.
Note you will be able to walk right through it unless you set the impassable
bit. Check out the textures BRNBIGC, BRNBIGR, and BRNBIGL to see how
transparent textures work.

If you just want to create a small free standing switch, you'd be better off
just creating a small sector with a floor more than 24 units higher then the
surrounding sectors, and the same ceiling height and texture. Then stick a
switch texture on lower, and leave normal blank. All the linedefs should be
2-sided and passable. If you set the impassible bit then monsters won't be
able to float over it, and it may mess up the BFG and rocket blast zones--the
player also won't be able to jump onto it from another platform. For an
example see the switch that rises up out of the floor on E2M1.
- --
"How can I be wrong? I have a badge!" -- Groo
Gordon_Mulcaster@mindlink.BC.CA -or- a7902@mindlink.BC.CA


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

From: allang@cuug.ab.ca (Geoff Allan)
Date: Wed, 26 Oct 1994 13:58:28 -0600 (MDT)
Subject: Re: DUL/DEL license

If you look carefully at your license, you will see that Id is not
allowing you to distribute their BSP builder (3, c) (the Utility).
You can distribute your editor as much as you like.

This also applies to paragraph 4. You cannot distribute maps made using
IDBSP, but that is the only restriction!

(my Lawyer pointed this out - I thought the same as you until then)

- --
+-------------------------------+----------------------------------------+
| Replies to allang@cuug.ab.ca |"So I open the door to my enemies, and |
+-------------------------------+ I ask 'could we wipe the slate clean', |
| finger allang@sun.cuug.ab.ca | But they ask me to please go fuck |
| for a status report on DoomEd | myself, You know you just can't win" |
+-------------------------------+--------------------------Pink Floyd----+

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

From: Gregory Alan Lewis <gregl@umich.edu>
Date: Wed, 26 Oct 1994 16:17:39 -0400 (EDT)
Subject: Re: Transparent switches?

> I'm unclear on what you are trying to accomplish? Do you want a switch hanging
> in midair?

Exactly.

> You could create a patch that is mostly/all transparent (B:255, G:255, R:0--I
> think those are the colours), then make a texture using that patch and a
> switch patch and stick it on a linedef. This would create a floating switch.
> Note you will be able to walk right through it unless you set the impassable
> bit. Check out the textures BRNBIGC, BRNBIGR, and BRNBIGL to see how
> transparent textures work.

This would work, except (I think) there would be a problem with having
a multi-patch switch texture on a 2S linedef. There would be the Medusa
effect. I'm still waiting for someone to confirm that though...

Greg ("Tree")


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

From: Robert Forsman <thoth@cis.ufl.edu>
Date: Wed, 26 Oct 1994 16:16:47 EDT
Subject: Re: DeuTex 2.5 soon out!

Olivier Montanuy <montanuy@LANNION.cnet.fr> ,in message <9410261925.211D3C@lat1
192>, wrote:

> I say 'soon' because I'm in *very* bad terms with gcc, because of that stupid
> long work alignement that never happen under a i486. Don't ask what happened
>> between
> version 2.1 and 2.5, I would go real angry. Let's say I found *some* bugs in
>> the compiler!

Structure alignment and member placement are not guaranteed by the C
language. However, it is customary for the compiler to give something that
isn't totally surprising to someone familiar with the native architecture.
Tell me what is surprising you and I'll explain it.

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

From: Bernd Kreimeier (++49-228-550-247) <Bernd.Kreimeier@nero.uni-bonn.de>
Date: Wed, 26 Oct 1994 22:10:19 +0100
Subject: Transparency color?

> You could create a patch that is mostly/all transparent
> (B:255, G:255, R:0--I think those are the colours)

I always got the impression that textures and sprites are
arranged in columns of non-transparent pixels. DMGRAPH
uses Cyan (as above) as transparent color in GIF
files (isn't there even a transparency color flag/index
in GIF89?). Somebody stated that this color has indeed been
used for transparent pixels in Wolfenstein. The DOOM
PLAYPAL has no "Cyan" color component, thus no cyan color
index.


To get this settled: is there any color index in the
PLAYPAL that is *not* visible in the rendered frame? I
don't think that DOOM internally uses posts AND checks for
( pixel_color == TRANSPARENT ) during texture mapping.
Right?


As for the transparent (Cyan GIF) textures: replacing sprites,
it is possible to use a zero length zero width picture
resource in the WAD (the _EMPTY lump the DMADDS Beta
uses). Haven't tried it for textures yet. But I'd expect
that DMGRAPH will convert any 1x1 or 128x128 monochrome
Cyan picture into precisely the same: a zero/zero picture
lump, size 8 bytes. No need to spread those tons of cyan on
the walls ;-).





B.


- ---------------------------------------------------------------
Bernd Kreimeier THIS SPACE INTENTIONALLY
bernd@nero.uni-bonn.de LEFT BLANK ...
- ---------------------------------------------------------------



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

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

← 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