Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Not Jabba

Weapon "brightmaps" alignment error in OpenGL

Recommended Posts

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:

 

Y4VVGpe.png

RXOnbqX.png

 

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

 

6UGTDKs.png

 

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?

Share this post


Link to post

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

JnUSHhn.png

Spoiler

umKkizD.png

 

and what it looks like in action

 

Spoiler

 

 

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

Edited by Kappes Buur

Share this post


Link to post
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 by Da Spadger

Share this post


Link to post
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 by -TDRR-

Share this post


Link to post
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?

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

What if a pixel at the bottom is made visible?

Share this post


Link to post
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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×