HQNX turns crisscrossing diagonals into blackness

[Gez]

It seems that the check for transparency in FGLTexture::CreateTexBuffer() made for the purpose of using ScaleX instead of hqx does not work. No texture is ever transparent... Somehow, it works anyway with most textures... But not all.

In Epic 2 MAP28, with any level of hqx, the texture TBAR20 becomes opaque. What's odd is that the nearly identical texture TBAR04 is scaled (by hqx) without loss of transparency, but TBAR20 loses it. The exact position of the pixels may be responsible (in TBAR20, the first diagonal line starts in the corner, in TBAR04 it starts just below the corner, so in 20 the top-left pixel is opaque while in 04 it's transparent), but here you go.

I've added a little debugging message and ran through a few maps:

Code: Select all

        bIsTransparent = 0;
    }

    if (bIsTransparent)
        Printf("Texture %s is transparent\n", tex->Name);

    if (warp != 0)
    {

I have not seen this message anywhere, it's just never printed...

[wtg62]

Is 'Printf' even a function?

[wtg62]

I'm not sure really how that rendering option could mess up the transparency. Maybe it's because of how the texture is rendered. Have you tried a different texture or tried to change the texture?

[NeuralStunner]

Uh yes, Gez actually does know what he's doing, he even helps program this port... Just a quick heads up.

[Graf Zahl]

The message only gets printed for textures containing a real alpha channel so that part is no surprise at all with a mod for classic ports.

Concerning HQnX, not my code and not my problem. If the algorithm screws up it's broken. But since I don't understand the code at all I can't fix it. All GZDoom does is to pass the original texture buffer into the function and receive the upscaled one. The input buffer is the same for all scaling algorithms so if only one makes problems I suspect the fault there. Especially since HQnX is known to create corner artifacts.

[Gez]

Concerning HQnX, not my code and not my problem.

Okay, there is now a ticket for that so Torr can look into it.

[Gez]

There is an odd interaction between this and dynamic light actors, so the problem may actually be outside of HQnX. This test map shows it. Load GZDoom with dynamic lights and this map, and look at the opaque grid. Fire to spawn a dynlight actor at your position, notice how the texture is now transparent from your side and still opaque from the other.

What seems to matter is the presence of a dynlight rather than the light it may or may not emit. When a player attacks, the bound light remains on the player's position until the next attack, so you can leave it behind you and watch what happens. (This, in itself, may be a bug as well but is not the topic here.)

[DaniJ]

This sounds like a GL texture state issue rather than a problem in the HQnX algorithm. I'm going to go out on a limb and suggest experimenting with the sprite draw style options.

As for the algorithm itself I recall that the standard implementation doesn't handle alpha data at all. Is GZDoom upscaling the alpha channel itself or has the algorithm been changed? Skyjake updated the version we use in Doomsday to handle the alpha also, so it might be worth a look.

[DaniJ]

First apologies for the double post but an edit wouldn't bring this new information to attention. Over the past day or two I've been investigating the workings of the HQ2x algorithm and specifically the implementation in Doomsday.

In the above post I mentioned that Skyjake amended the version we use in Doomsday to handle alpha also. However I now know that the way this was done is not algorithmically correct, so don't use our implementation for reference. Just a heads-up.

If you want any specific info on the problem just ask. I'm presently working on a solution.

[Gez]

Do you have the same issue with the Doomsday renderer?

I have found out (as explained on the Skulltag ticket) that the presence of dynamic lights on the viewer's side will restore transparency to the texture. This shouldn't have an effect on the hqx algorithms since they process the texture the same way regardless of the scene rendered, so I'm not sure anymore where the opacity issue is.

[DaniJ]

No we do not have the same issue in Doomsday. I just happened to be working on our hq2x implementation and remembered this bug report and my recommending it as a reference.

[Gez]

Looking back into the test map, the thing with the dynamic lights no longer happens. The texture remains opaque.

Interestingly, it is transparent during the first few tics while the first image is being displayed; but becomes opaque once the screen melt effect is finished.

[Sam]

I'm having the same problem. Does anyone know of a fix?

http://img21.imageshack.us/img21/151/sc ... 206251.png

Image tags converted to a link because the image is very big. - Enjay

[herrecito]

Hi! First of all, thanks to all of you for your work.

I'm having trouble with every transparent texture.
Some will always be black, and some will go black everytime a fireball / rocket goes through them or a gun is fired standing JUST beside them.
I've made a bunch of screenshots:



The rest: http://imgur.com/a/b3aAU

I've tried every combination of settings I could think of and only got one result: when High quality resize mode is OFF, they only go black when shooting beside them or a rocket / fireball goes through.

Tried with different Catalyst drivers and settings (clean installs), no effect. Tried several GZdoom versions and I get this problem in everyone of them. Happens in Vanilla and in every PWAD.

Specs:
XFX ATI Radeon HD 5870 1 GB Core Edition (Catalyst 13.12)
Intel i5 2500k
ASRock P67 Pro 3

I just tried gzdoom in a PC with an nvidia graphics card (8500 GT) and the problem doesnt ocurr, so I'm sorry if it's not a bug and some weird thing going on in my computer that im not aware of.

[Gez]

It's an old issue, which has yet to be understood.