Creating transparent spaces

I'm working on my first wad, so I'm a total newbie. It's a total conversion, maybe a bit ambitious for a first wad, but it will keep me busy. Anyway, I think I'm getting the basics down. However, I see in a lot of resources (mostly the wad designers handbook and a book, "Tricks of the DOOM programming gurus") that say to have transparent spots in textures, they need to be patched textures, but none say how this is accomplished. Actually, I'm not worried about textures yet, I'm working on the title menu logo (M_DOOM in doom2.wad). I'm completely changing the logo, but I can't figure out how to make the negative space transparent. Any help?

One can't believe everything one reads<g> Perhaps it was a matter of interpretation>

A "transparent" area in a graphic is an area where no pixels are drawn by the engine. A texture can have ONE patch and that patch can have "transparent" areas.

The way you make an area transparent is to use a specified color, that either DeePsea or Wintex will recognize as "transparent" and convert to the Doom format appropriately.

For a quick overiew of how this works using DeePsea (just a bit easier to explain, since it works with DOOM graphic lumps directly):

1. press F7, Export a "patch" graphic as a WAD (let's use RW1_4 and save as RW1_4.WAD)
2. read RW1_4.WAD back into DeePsea (file open)
4. Now on the same F7 menu, select Graphics Editor.
5. Then select drawing mode. The RW1_4 patch should be in the list shown.
6. Press Edit.
7. Press the "eraser" icon on the top right.
8. Go to the texture and "erase".

Everywhere you "erase" is now a transparent area.

9. Press "save as" and choose a different name.

Combine this new PWAD with your WAD and now the texture called BRICK2 has "transparent" areas. Here's why the names are different.

Textures are made up from "patches". The texture names are stored in something called TEXTURE1 and the patch names are stored in PNAMES. If you keep the patch name the same (also called lump name), then whatever texture used that patch will now be "transparent".

You can also export the texture as BMP, then use some graphics editor to modify, choose exactly the same "transparent color" as before and reimport it back.

Btw, M_DOOM already has transparent areas, but is just a graphics lump (not used in any texture). Sprites and numbers are examples of other graphics that are not textures.

Hopes that's a start to giving you an idea of what to do.

The pixels colored cyan (the bright-blue-ish color, like in M_DOOM) translates to transparent. The engine doesn't draw cyan. Same goes for sprites.

If you're importing using Wintex, you may see the imported lump with cyan turned to yellow. The problem here is you're trying to import a graphic that's 16bit color, instead of using the DOOM palette which is 256 colors. So Wintex tries to remap your colors to 256 and does so very poorly.

Use a real graphic editor to use the correct palette, like Paint Shop Pro or Photoshop.

That is not correct.

See what I wrote before - since I wrote the code that does exactly what I wrote:) It is a common misconception that resulted from "seeing" a color that became transparent, but in fact, there is no such thing as a "transparent" color in DOOM.

DOOM does NOT look for a "transparent" color. DUKE3D does. The "transparent" color is merely a convenience for DeePsea or Wintex to be able to detect areas not to create "columns" for. The actual color can actually be anything, so long as it does not conflict with an actual color you want.

The palette to use to be sure of always matching the "transparent" RGB is the DOOM palette (has nothing to do with what editor to use - DeePsea automatically uses the correct palette). The drawing tool can export a PSP format palette or any BMP exported automatically has the correct palette.

DeePsea will "probably" match even from 16 or 24 bit color BMPs, but you have see use the same relative RGB value. It is true that Wintex does a crappy job of matching > 256. In addition, Wintex actually uses a default RBG color that does not exist in the actual DOOM palette, which is another confusing issue.

You can actually believe what you read this time:)

Cyan color in sprites is only seen by editors? That doesn't make any sense. I always though the cyan was simply not drawn by the engine (hence it's transparent).

So what you're saying is the editor converts those cyan pixels to something else that predefines to the engine that it's transparent? and by transparent I mean it's a pixel color that is not drawn by the engine.

The palette thing with Wintex is pretty much what I said. Your explanation wasn't exactly in the simplest form for a newbie, which is why I said what I did.

No need to get snippy now. :P

deepteam said:

well, thanks for the help, I was using wintex, and editing with mspaint, and it wasn't working. then I tried deepsea and did the erase thing like you said, but now when I load the wad it crashes doom.

Are we talking DOOM or ZDOOM? ZDOOM code actually has a mistake when he displays standalone (non-texture) graphics. I just found this out about a month ago. It doesn't follow the technical graphic expansion specs. DOOM works fine. I changed it in the next release to eliminate the '0' length columns for ZDOOM standalone graphics.

If you aren't using ZDOOM, then there are lots of things that crash DOOM. Too many things that can be done wrong. The easiest thing is to send me the graphic and the level and I'll send it back fixed telling you what was wrong.

Fanatic said:

Cyan color in sprites is only seen by editors? That doesn't make any sense. I always though the cyan was simply not drawn by the engine (hence it's transparent).

So what you're saying is the editor converts those cyan pixels to something else that predefines to the engine that it's transparent? and by transparent I mean it's a pixel color that is not drawn by the engine.

The palette thing with Wintex is pretty much what I said. Your explanation wasn't exactly in the simplest form for a newbie, which is why I said what I did.

No need to get snippy now. :P

Not exactly. There is NO color in sprites, etc. A Doom graphic is not a bitmap at all. Rather, it's a custom data form where each vertical columns is drawn by offset and length. So everytime there is "nothing" to be drawn there is absolutely NO column data for that area.

So the way that works in DeePsea (or Wintex)is as follows: An empty rectangle is created in the color choosen to be transparent. Then each "column" is drawn on top of the rectangle. Any areas that are not drawn over show the "transparent" color.

An image "imported" to be converted to the DOOM format has a series of "column" data created. Everytime the "transparent" color is encountered, it's just skipped over and nothing is done - except of course to keep track of the y offset for the x column. So what you end up with is a series of "x" columns with "y" data offsets for a length of "n".

There is no color conversion of any kind.

The better one understands the constructs, the easier it is to work with Doom graphics. Remember, he asked about "textures", yet that graphic is not a texture per se. So TEXTURE1 and PNAMES are pretty easy to explain, since most beginners don't realize there is any difference at all.

(just explaining, interpretation is up to the receiver -i.e. no snippy intended<g>)

I had always thought it did something like what happens when you have a transparent gif89a - it just let's all the background colors show though areas painted with the transparent color.

They outta make a doom mod that allows you to use plain ol' gif, bmp, and wav files as well as wads so that some images can ahve their own freaking palettes (this would, of course be a 16-bit colored engine).

And when are people going to get it straight that you dont make sprites like the bfg blast and plasma shots translucent! you make them additive, which is an effect that makes brighter colors more solid (and maybe brighter as well), and makes darker colors more translucent against the background. Right now, making an object with a bright center as a trasnlucnet object makes it look abit "muddy" instead of crisp like quake3's plasma blasts look.

General guidelines for making sprites for doom:

*Must be in 256 colors (or you get weird color shifts like fanatic said).

*Palette need not be doom's, but stay away from teal objects (like alot of hexen and heretic's are), because they will have some of those colors turned into transparency (a bad thing in this case).

*All the areas that are supposed to be transparent need to be painted with the color "red: 0,green: 255,blue: 255" (ie, bright blue-green). this is for things like the outside of a guy's body (like the areas under his legs and arms), and any holes they develop as they die from injuries (blows a hole through em', transparency allows you to see to the other side).

*There are some other colors which dont behave well in addition to teal. Yellow to orange transitions tend to be really sharply cutoff (yellow stops and a darker orange starts without a smooth transition) - mostly found with muzzleflashes. Blue to purple also cuts off.