argent
argent copied to clipboard
XaserAcheron
Palette Issues
Need to include some versions of paletted graphics to avoid stuff like this in Linux.
I'm a bit surprised the crosshairs are misbehaving since those are treated specially anyway, but I may have forgotten to greyscale the graphics. Will check that first.
@Pink-Silver, are the HAR/Gauss crosshairs any better in Linux-land? I pushed a thing but I'm not quite sure if it's what we needed.
Reminder to self to test with vid_forceddraw later when I get home-ish. I forgot to because I'm a derpface.
@XaserAcheron Negative, it's still rendering the translucency as solid, so it's still going through the conversion routine.
Not a surprise, Greyscale isn't an indexed color type in the PNG specification, so it may be necessary to explicitly create a greyscale palette and apply that instead.
Hmm, I was afraid of that. The trick, then, is figuring out exactly how to convert a PNG into an actual proper greyscaled rather than one that happens to have a grey palette (the latter is what the images probably are now). Or otherwise figure out what image type is that works. D:
It's weird though because the D3D renderer is totally fine with it. I wonder if it's a legit ZDoom bug?
It's the other way around, dudebro. ZDoom wants a greyscale indexed palette, because it uses the index as an alpha value, but your images are actual greyscale, which means the palette renderer needs to apply a palette to it but winds up mistaking 0 as fully opaque because it swaps it with 247 due to the way the rendering works, as it claims a duplicate palette slot to represent transparency.
For reference, the D3D method uses a shader and does the smart thing by taking the red channel and that as the alpha value, which is the sensible way of doing it, because it removes palette indexes from play all together, but it likely wasn't done that way because the DOOM palette has all of 80 greys in it, not really as much as a full greyscale palette could represent.
Well, that's wacky as all hell. How the fook is someone supposed to figure that out? D:
It's probably worth documenting some of this on the wiki, since it mentions nothing of the sort (and, in fact, seems to suggest proper-greyscale if the language is taken literally).
Will try another fix here in a second.
Well, that didn't work. Indexed-palette PNG shows the same issues as greyscale PNG. Tried Truecolor too just to be goofy; still no dice.
Welp. Between this and the fact that PALVERS doesn't work on HUD graphics (WTF), I'm going to "officially" put this on hold. Not closing it outright, but removing it from the v0.3.0 milestone.
I reeeeeally hate to tell non-Windows folk "use GZDoom" (or QZDoom now? :P), but it's still all technically in alpha, so... D:
I'll fix the crosshair issue once a sane solution comes forth.
Yeah I don't really have the tools to properly fix this right now either, so I apologize. It requires an editor with strict control over PNG chunks and palette-editing capabilities.
No worries -- thanks for the help there!
I'll open a question on the ZDoom Editing forum for now. Better than doing nothing at least.
[EDIT] For future reference, here's the thread. I'm fairly convinced at this point that PNG support for crosshairs is broken, so I'll probably just end up converting the crosshairs to IMGZ.