STYLE_Shaded is malfunctioning

[Xaser]

I apologize a bit for the re-post, but I'm sure this is easily missed in a Closed forum. ;P

STYLE_Shaded still does not seem to work at all like Graf's description, and unless I'm doing something terribly wrong, I'm at a loss.

It appears that index 0 shows up as fully-opaque instead of fully-transparent. Now I have two full-opaque colors, which is not good.

I'm using this image:


And the end result is this:



Am I allowed to define .png transpacency with this renderstyle, at least? That could provide a temporary solution though judging from Graf's description on how the renderstyle should work, something's definitely wrong here. Oversight, perhaps?

[randi]

I suspect this is a case where you're doing it wrong, but I'd like to see how you've got it set up in a wad to be sure.

[Xaser]

Can do, sir.

Here's a quick test wad. Summon 'TestProject' and note the coloring errors.

vortest.wad

For reference, I'm running SVN build R967. That could make a difference -- would be quite ironic if this was fixed accidentally while I wasn't looking. ;P

[randi]

As I suspected, the image wasn't set up correctly. You need to use setpng to indicate that the grayscale image data is actually an alpha channel and not a color channel. Unfortunately, the PNG spec doesn't allow for alpha channels without any color information, so I needed to use an ancillary chunk to indicate images like this and still allow them to be editable by normal applications. All the decals in zdoom.pk3 have been processed in this manner.

The command line to use looks like this:

Code: Select all

setpng -alph vorta0.png vorta0.png

Attached is the fixed wad for comparison. (Note that I recompressed the image with pngout to check that the color type was grayscale. Setpng is the only thing needed to make it work.)

[randi]

And right after I posted this, I realized that it doesn't seem to work for any color other than black. I'll check more later, since it's getting late here.

[Xaser]

Ah, thanks for your help! It's working now.

I honestly have no knowledge of PNG structure or how palettes are stored, but would it simply be fundamentally wrong to, in this case, have the engine treat the color channel as alpha regardless of the extra .PNG bits? Obviously there's no desirable reason to have the image treated the way it was in my borked wad, so wouldn't it be safe for the Shaded renderstyle to always 'assume' the palette is alpha? Since it probably needs to be set up that way always, I don't see much potential for harm.

Sorry, I'm just babbling on. It just seems like an 'extra step' in my eyes but I'm sure you have better reasons for the way it's done. Silly me and my non-coding nature. ;P

Also, I don't think anyone else has tried to use this renderstyle just yet and I'm using black anyway, so no rush on the newest issue.

[randi]

It's done like this to avoid remapping the image data to the game palette. If just left as a normal grayscale image, those grays will be mapped onto the grays in the game palette, totally ruining the alpha effect.

[Xaser]

Ah, I see now. Thanks. ;P

*scratches his head, wondering about his own logic*

[Gez]

I honestly have no knowledge of PNG structure

The [wiki=SetPNG]SetPNG wiki page[/wiki] contains a very quick summary.

[Grimm]

So uh, I'm having a similar problem.

http://forum.zdoom.org/viewtopic.php?f=3&t=17317

imageshack won't host my damn png, but rest assured it looks very much like Xasers. I used SetPNG as well.