Weapon "brightmaps" alignment error in OpenGL

[Not Jabba]

Hey all,

 

Spadger and I recently noticed that his Heretic weapon brightmaps are having some issues in OpenGL rendering. These aren't brightmaps in the GLDEFS sense, because The Wayfarer and Elf Gets Pissed were created for software rendering, not OpenGL. Instead, they're bright overlays that are spawned over the item pickups. GZDoom's GL sprite clipping is causing the overlays to be misaligned. Here are a couple of shots of the bug:

 

 

But another custom item that I created uses the same type of overlays, and it works perfectly for some reason:

 

 

I can't for the life of me figure out what the difference is, or what I could do to make the bugged item pickups display correctly in GL.

 

If you set the Adjust Sprite Clipping option to "never" in GZDoom, it fixes the problem, but that also causes a lot of other actors to clip into the floor, which of course is why GZDoom uses smart sprite clipping as its default in the first place. Does anyone have any idea what's going on here?

[Kappes Buur]

I am mapping for GZDoom UDMF, so this may not apply to your case,

When I want to highlight a weapon, ammopack or other actor I usually give them a dynamic light which will deactivate when the actor is picked up.

 

Spoiler

Spoiler

 

and what it looks like in action

 

Spoiler

 

 

On the other hand, why not use actual btightmaps, they are not difficult to construct.

Edited February 24, 2019 by Kappes Buur

[Da Spadger]

1 hour ago, Kappes Buur said:

On the other hand, why not use actual btightmaps, they are not difficult to construct.

Can't use them in Software mode. These are a substitute for the real thing.

 

I quite like how they turned out.

Edited February 24, 2019 by Da Spadger

[-TDRR-]

Just now, Da Spadger said:

Can't use them in Software mode. These are a substitute for the real thing.

 

I quite like how they turned out.

Why not use ACS to check the rendering mode (i can't remember which cvar was it though) and if it's OpenGL, replace the sprite with a true-brightmapped version of it.

 

If it's for Zandronum and GZD 1.8.6 then the CVAR is vid_renderer and 0 means software and 1 means GL.

 

EDIT: Actually, if you are aiming for recent versions of GZDoom, brightmaps work on the software truecolor mode, and maybe on classic software too.

Edited February 24, 2019 by -TDRR-

[Da Spadger]

15 hours ago, -TDRR- said:

EDIT: Actually, if you are aiming for recent versions of GZDoom, brightmaps work on the software truecolor mode, and maybe on classic software too.

 

This is news to me. So they pretty much just work like in Software like they do in OpenGL?

[-TDRR-]

1 hour ago, Da Spadger said:

 

This is news to me. So they pretty much just work like in Software like they do in OpenGL?

Yes, basically the same.

[Da Spadger]

I gave it a try using the standard brightmaps included with GZ. (3.6.0) Do I need a newer version or do something in addition? It didn't work in software, truecolor or otherwise.

[Gez]

On samedi 23 février 2019 at 6:34 PM, Not Jabba said:

If you set the Adjust Sprite Clipping option to "never" in GZDoom, it fixes the problem, but that also causes a lot of other actors to clip into the floor, which of course is why GZDoom uses smart sprite clipping as its default in the first place. Does anyone have any idea what's going on here?

Are your overlay sprites the exact same height as the weapon sprites? Even if it means most of the sprite is an empty area of transparent pixels.

[Not Jabba]

10 minutes ago, Gez said:

Are your overlay sprites the exact same height as the weapon sprites? Even if it means most of the sprite is an empty area of transparent pixels.

Yeah, when I flip between the base sprite and the overlay sprite in Slade, they look exactly aligned, and the borders it shows for the image are the same size. That's probably why it lines up in software -- I'm just not sure what causes it to get adjusted downward in OpenGL.

[Gez]

What if a pixel at the bottom is made visible?

[Not Jabba]

3 hours ago, Gez said:

What if a pixel at the bottom is made visible?

Good idea, but that doesn't seem to work either, for whatever reason.