[r1432] Patch blend alpha inconsistency

[MaxED]

Looks like alpha value of a Blend effect applied to TEXTURES path is inverted compared to ZDoom. Here are some examples:

Using this TEXTURES definition:

Code: Select all

Texture ATEX, 256, 256
{
	XScale 2.0
	YScale 2.0
	Patch ATEX, 0, 0
	{
		Blend "#00FF00", 0.1
	}
}

GZDoom:

ZDoom:



And using this TEXTURES definition:

Code: Select all

Texture ATEX, 256, 256
{
	XScale 2.0
	YScale 2.0
	Patch ATEX, 0, 0
	{
		Blend "#00FF00", 0.9
	}
}

GZDoom:

ZDoom:

[Gez]

Mmmh... What happens if you display that texture with DirectX by making it a full-screen graphics or a HUD weapon sprite?

[MaxED]

Fullscreen graphics seem to be consistent. Here I replaced HELP graphic with this:

Code: Select all

Graphic HELP, 320, 240
{
	Patch ATEX, 0, 0
	{
		Blend "#50E94B", 0.9
	}
}

[Gez]

As I thought. The texture manager is common to both (contrarily to the renderer), so it's the same logic that is used for compositing. The discrepancy is actually in the truecolor-to-paletted conversion code, so it's a ZDoom bug.

[MaxED]

I don't know the way (G)Zdoom's patch compositing logic works, but when I used one of Doom 2's patches (SLIME11), the problem was still there:

Code: Select all

Texture ATEX, 64, 64
{
	Patch SLIME11, 0, 0
	{
		Blend "#50E94B", 0.9
	}
}

[Gez]

I tell you, it's a ZDoom bug, not a GZDoom one. If ZDoom's renderer was in truecolor it would behave like GZDoom. There is no difference in the way the textures themselves are composited, the only discrepancy is in the way a blended texture get converted to paletted colors.

[MaxED]

OK. Should I repost this at zdoom.org (or perhaps you can do it, because you have better understanding about what's going wrong here)?

[Gez]

"Moved" to ZDoom, so closing this as duplicate.