Pallette Mishaps

[Sporku]

Okay, I feel stupid asking this, but.. uh.. yeah. I made a *barely* modified pallette for my megawad (here it is), to modify the shades of blue, so they look better. When testing it, I noticed something on one of the textures. A few pixels of bluish color that would change as you walked to/away from it.

Here's a shot.

Did I do something stupid?

[Fredrik]

You failed to realize that you can't change #247 to cyan, since it's used as black by some textures (including those tekwalls).

[Sporku]

ack! I don't even remember changing that index. Anyway.. fixed :P

stupid me

[Fletcher`]

Why is there transparency on those patches anyway?

[Fredrik]

ravage said:

Why is there transparency on those patches anyway?

There isn't.

[Fletcher`]

Fredrik said:

There isn't.

what

[Fredrik]

Palette index #247 is a regular index, just like every other color in the palette. Textures use it.

There's no index that represents transparency.

[Fletcher`]

Yes, but doom uses that specific index to determine what parts of a graphic are transparent or not. That's how I see it.

[Fredrik]

ravage said:

Yes, but doom uses that specific index to determine what parts of a graphic are transparent or not. That's how I see it.

Certain editors use that index, but Doom itself doesn't.

[Cyb]

editors should really use index 255 since doom can't display that index on regular graphics anyway

[Fletcher`]

Fredrik said:

Certain editors use that index, but Doom itself doesn't.

Then what does Doom use then?

[Cyb]

first you have to understand that while doom graphics have a length and a width, they aren't necessarily a square. for instance look at a regular imp sprite. all the cyan areas don't actually appear there in game because they don't exist. it's extracted this way because it's not possible to make a 8bit bmp with transparency (afaik) and even then it would still have x by y dimensions.

so anyway, doom graphics are stored in columns (of pixels) and each column is made up of 0 or more posts. Posts are simply smaller columns, usually there because there's some transparency between them. for instance (this is from memory so don't hold me to it) the first frame of the player, PLAYA1, the column where his leg starts also has a post above that containing part of his arm or gun, but there are a couple pixels of transparency between them. Rather than store excess pixels (and then have the engine not draw them) doom simply stores the offsets of each post with respect to the top of the column. So if column 3 has 2 posts and one starts at offset 0 with a length of 5 and the second starts at offset 25 with a length of 10 there will be five pixels of color at the top of the column (going down) then 20 pixels of nothing and then 10 pixels of color. The remaining length of the column (if there is any left) will be transparent.

cyan is only used to indicate transparency for images outside of a wad, but in reality you can set any color to represent transparency, and you can use cyan in doom graphics, though there are very few lump editors that will allow such a thing (deepsea and omgifol (I assume) are the only two I can think of offhand).

actually, the color you can't use in a doom image is palette index 255 (last color, sort of pinkish) since in hex that's 0xFF which indicates the end of a post in doom gfx format, so using that color would confuse most converters I imagine.

[fraggle]

Cyb said:

actually, the color you can't use in a doom image is palette index 255 (last color, sort of pinkish) since in hex that's 0xFF which indicates the end of a post in doom gfx format, so using that color would confuse most converters I imagine.

This is incorrect. The posts store the number of pixels in them, the end is not marked by an ending 0xFF. 0xFF is used to mark the end of a column, not the end of a post. Doom graphics can store the full 0-255 range.

For those who dont understand Cybs (rather technical) explanation, the doom graphic format essentially works by cutting up the graphic into lots of bits. Transparent parts are just where there is nothing drawn in that area. Obviously this is difficult to work with from an editing point of view, as you need some way of marking those parts of the image which are transparent. The way practically all doom editing tools have approached this problem is to treat Cyan colored areas as transparent when importing images.

[Fredrik]

fraggle said:

This is incorrect. The posts store the number of pixels in them, the end is not marked by an ending 0xFF. 0xFF is used to mark the end of a column, not the end of a post. Doom graphics can store the full 0-255 range.

Ah, I thought there was something suspicious about that myself, but I was too lazy to check. You fail it Cyb :P

[FireBastard]

Fredrik said:

Ah, I thought there was something suspicious about that myself, but I was too lazy to check. You fail it Cyb :P

Sorry I didn't post this sooner, although I bet from an outsider it would have been ignored.

After our discussion earlier a few weeks ago where I questioned your statement about FF - I created a graphic with xFF as data pixels and it worked in ZDOOM. As Fraggle noted, I too was aware of the actual format spec, but thought maybe DOOM had a quirk here.

Lesson: It pays to actually verify the advice given here. Several times I've noticed erroneous statements, but it appears it never occurs to actually verify information:)

[FireBastard]

fraggle said:

The way practically all doom editing tools have approached this problem is to treat Cyan colored areas as transparent when importing images.

Doesn't have to be Cyan, can be any user color for some editors. Posted by somebody above, but I'm too damn lazy to reread.

[Cyb]

whoops, I indeed do fail it

doom specs:
255 (0xFF) ends the column, so a column that starts this way is a null
column, all "transparent". Draw the next column.

but still, without a very specalized tool it wouldn't be a very easy task to make an image with all 256 colors AND transparency, so you're still sort of limited to 255 colors anyway, but not limited to leaving out index 255.

also it's worth mentioning that with the new zdoom texture system if you put a graphic with transparency on the wall (a sprite or something) index 255 is used to fill in the transparency.

[fraggle]

The other obvious way to do it would be to have a separate "mask" graphic to mark the parts of the image which are transparent. Obviously thats less convenient though as when editing graphics you have to make sure the mask is up to date with the image itself.

[Fredrik]

Or you could convert from true color images...

[FireBastard]

Cyb said:

255 (0xFF) ends the column, so a column that starts this way is a null column, all "transparent". Draw the next column.

This appears to be true if it goes over 254 long (you can check the original DOOM code and tell us exactly what's going on). I tested stock DOOM using a graphic of 16x128 all FF and it works fine. Does NOT work with a graphic of 1x256 (made into a 16x256 texture). ZDOOM works with both of those.

also it's worth mentioning that with the new zdoom texture system if you put a graphic with transparency on the wall (a sprite or something) index 255 is used to fill in the transparency.

Probably not sprite transparency since Sprites are exactly the same format as textures - so that doesn't make sense at first glance. Seems I remember something about 255 though - umm damn can't remember.

[Cyb]

http://cyb.vect.org:8080/pics/DOOM0138.png

the width of graphics is pretty much unlimited (stored in an unsigned short, so 65536 is the limit, much wider than anyone will ever need)

height however, while it is stored in a short as well, is limited by the columns and posts. Posts store the number of pixels downward in a single byte, limiting the number of pixels per post to 256. On top of that the very last pixel in a post isn't drawn (nor the first one, but the post offset starts at the second pixel I think) so it's really 255 pixels (which is where the engine texture height limit comes from).

HOWEVER, and I believe we talked about this in another thread, with the stock doom format graphics up to 509 pixels tall should work, though I think there is a hard coded limit to texture heights of 255, but sprites up to 509 should work, unless there's a limit to them as well

[Sporku]

Woah.. What a conversation my stupidity sparked.

[FireBastard]

Where are we discussing widths?

limiting the number of pixels per post to 256.

As you said, the max offset is 254 otherwise it's FF and would terminate. So that leaves 255 for a length (the unused stuff is not important here). But if you use 255 then the NEXT offset is 255 so that won't work, meaning the maximum length = 254 for the first post.

HOWEVER, and I believe we talked about this in another thread, with the stock doom format graphics up to 509 pixels tall should work, though I think there is a hard coded limit to texture heights of 255, but sprites up to 509 should work, unless there's a limit to them as well

Yes we did. I got confused on hi-res vs stock DOOM format. The limit is 509 = 254+255 (2nd one can be 255 for stock DOOM, but not for ZDOOM when going past 509). I'm pretty sure tall sprites worked for stock DOOM.

Did some more testing and am getting a bit confused (or I just frughed up). I put one "bad" texture (16x128 with a patch 256 tall) and one "good" texture (16x128 patch 128 tall) one of them works but not the other - and it's the opposite of the one that work before, the tall one. This is after I added some more test textures (to see how tall they can be). I tried over 128 using tall patches and that locked up. But if I make it 256 using regular patches (128 tall) it works as a tiled 128. Man talk about weird sheit.

Texture height limit and patch height limit are 2 different things though. I tested texture size up to 512, locked up again at 1024. Tiling is fixed at 128.

You can test more. Thank god for XP or I'd be booting my ass off.

[Kaiser]

AgentSpork said:

Woah.. What a conversation my stupidity sparked.

actually, there hasn't been much discussions about editing the Doom palette.

[Cyb]

FireBastard said:

Where are we discussing widths?

you said 'over 254 long' which I took as width, but apparently you meant, height?

FireBastard said:

Did some more testing and am getting a bit confused (or I just frughed up). I put one "bad" texture (16x128 with a patch 256 tall) and one "good" texture (16x128 patch 128 tall) one of them works but not the other - and it's the opposite of the one that work before, the tall one. This is after I added some more test textures (to see how tall they can be). I tried over 128 using tall patches and that locked up. But if I make it 256 using regular patches (128 tall) it works as a tiled 128. Man talk about weird sheit.

odd. actually, I don't see why a tall patch in a shorter texture wouldn't work since doom only displays the area within the texture height, but I'm not too familiar with how textures work right now.

FireBastard said:

Texture height limit and patch height limit are 2 different things though. I tested texture size up to 512, locked up again at 1024. Tiling is fixed at 128.
[/b]]

isn't it possible to have a tall sky in doom2.exe (not that you could see it all)? I can't recall if that's something added by ports, but I recall it being avaliable from the start... could be wrong tho

[Fredrik]

Cyb said:

isn't it possible to have a tall sky in doom2.exe (not that you could see it all)?

If it worked, you'd notice when standing in a room with an abnormal vertical sky view (floating in the sky-like), even without mlook. IIRC I once tried, but found the texture to tile at 128 pixels no matter the height.

[deep]

Fredrik said:

You failed to realize that you can't change #247 to cyan, since it's used as black by some textures (including those tekwalls).

That reminds me why I didn't use index 247 (as in Wintex - but he probably started with DOOM?). I wrote a little test thingy a long time ago to find all the colors used. I just reenabled it and here are the results for various games (stock textures - and it looks like I forgot to do this for the others or I made a mistake):

DOOM: Total Palette Pixels not used by any graphic = 19

168,192,195,196,197,208,224,228,229,230,231,247,248,249,250,251,
252,253,255,

DOOM2: Total Palette Pixels not used=12

168,192,195,196,197,208,249,250,251,252,253,255,

HERETIC: Total Palette Pixels not used by any graphic = 26

089,090,091,092,093,094,107,108,110,132,134,144,161,162,163,164,
165,166,167,168,223,224,239,249,254,255,

HEXEN: Total Palette Pixels not used by any graphic = 15

096,117,119,120,121,145,183,184,185,215,216,229,244,245,255,

STRIFE: only 1, index = 0.

(edit: I left this output enabled in DeePsea 11.82a - it's part of F7 - TEXTUREx name edit - Verify Graphics, so you can see for yourself )

(edit2: I should run this through all the graphics and see what pops out - trying to decide where I should put it, maybe in Export since that knows all the graphics already.

[Python_Junkie]

Deathman said:

actually, there hasn't been much discussions about editing the Doom palette.

Then allow me to start it:

Just how DO you change the palette so that it works with the colors of your custom graphics?

I tried inserting some sprites into a recent wad of mine that sadly never got off the ground due to color palette incompatibilities. I tried using error diffusion option in PaintShop Pro, and the result wasn't any better (there were pixel "specs" scattered throughout the image).

Only recently did the thought occur to me, "Hey, maybe if the color palette of the custom graphic could be changed into a data lump and inserted into the wad, maybe that could work!"

I haven't tried it yet, and if I'm thinking of a stupid idea, please tell me.

If not, well, then hold on to your seats because I may have a new project on the way!

[The Ultimate DooMer]

deep said:

DOOM: Total Palette Pixels not used by any graphic = 19

168,192,195,196,197,208,224,228,229,230,231,247,248,249,250,251,
252,253,255,

DOOM2: Total Palette Pixels not used=12

168,192,195,196,197,208,249,250,251,252,253,255,

But this doesn't include the sprites, some of which use the other colours.

[insertwackynamehere]

fraggle said:

This is incorrect. The posts store the number of pixels in them, the end is not marked by an ending 0xFF. 0xFF is used to mark the end of a column, not the end of a post. Doom graphics can store the full 0-255 range.

For those who dont understand Cybs (rather technical) explanation, the doom graphic format essentially works by cutting up the graphic into lots of bits. Transparent parts are just where there is nothing drawn in that area. Obviously this is difficult to work with from an editing point of view, as you need some way of marking those parts of the image which are transparent. The way practically all doom editing tools have approached this problem is to treat Cyan colored areas as transparent when importing images.

Do you mean it's sort of like 0 and 1, where 1 can be many things, and 0 is nothing?