Fixed Flats with cyan pixels do not render properly with alpha value #255

I'm changing the topic so that it discusses not merely a specific instance of a larger glitch, but the larger glitch itself.

Anyway, it seems that when flats which contain cyan pixels are assigned to a translucent FOF with alpha value #255, which is supposed to make the cyan pixels invisible, it produces a nasty side effect: it only renders the first 32 fracunits of the flat, and loops it indefinitely.

It's supposed to be used as a middle texture, which does remove the cyan. All textures with that shade of cyan work that way.

Not the texture, the FLAT.

For the record, cyan (color 247) isn't really transparent, most wad editors just interpret it as such.

There are two formats of graphics SRB2 (and Doom) uses. One is used for flats. The other is used for everything else.

Flats are defined very specifically. They have to be square, their dimensions have to be powers of two, and every pixel is opaque. This is why SRB2's transparent flats aren't really transparent: there's a specific routine that skips drawing cyan pixels on translucent FOFs.

The other graphics format is a bit more dynamic. The dimensions can be whatever you want, but with a maximum of 255 pixels vertically. The best part, though, there can be transparent pixels.

Since Doom already uses a full 256 color palette, there's no room left to add a "transparent" color to image files in order to allow image editing programs to emulate the "transparent pixel" aspect of Doom graphic lumps. So what people decided to do was replace color 247 with transparent. Color 247 just so happens to be a duplicate color (pure black), so every possible Doom graphic can be represented with this color palette.

The problem arises when WAD editor programmers start hardcoding color 247 to be converted to transparent. Knowledge among users is lost and people begin to not know how stuff actually works. In reality, you CAN have a texture/sprite use the cyan color in SRB2, but most WAD editors either won't let you or make it obscenely hard. DeePsea is an example of an editor where you can just go into the options menu and set the working transparent color. You could set it to something which isn't in SRB2 at all (like a violet tone), and then import true-color bitmaps with the violet color in place of transparent pixels and DeePsea will do everything correctly and keep cyan where cyan's supposed to be.

I'm thinking that the cyan in the texture is the wrong cyan.

But that wouldn't explain the core problem I'm reporting. The issue is that when the alpha value is #255, nothing is rendered, even the non-cyan parts. And when the alpha value is anything else, it's all rendered, cyan included.

I ran into the same issue the other day when mapping. Fawfulfan is correct, nothing renders at all. It's completely invisible!

This glitch is really driving me insane. Those fan flats would be very useful for Fume Shaft Zone, and because of it I can't use them. What the heck could be causing this?

You know, I wish you guys would at least try to delve deeper into what's causing the problem instead of just whining about it.

It appears that, for whatever reason, when you have a translucent FOF at full opacity (any level higher than #241), and the FOF is using a flat larger than 64x64, only the top 32 rows of pixels will be drawn, over and over:



It just so happens that the top 32 rows of the fan textures are all cyan, so the entire FOF's flats become cyan -- and thusly invisible in this case.

Wow...that would explain it.

I'll adjust the topic name accordingly.

Sorry, I have a feeling this is my fault.

Neo Chaotikal said:

...when you have a translucent FOF at full opacity (any level higher than #241)...

Click to expand...

Excuse me, hold up, but WHY would someone make a transparent FOF with an OPAUGE level? I seriously don't see the logic in that.

To force the game to use a different drawing function that handles transparent flats but is, IIRC, a fraction slower at doing its job because of such.

If a FOF is opaque, the game doesn't draw the stuff behind it, usually. By using a translucent FOF, you avoid this issue since parts will be see-through.

Fixed this bug in private trunk.