Not Jabba Posted February 23, 2019 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? 0 Share this post Link to post
Kappes Buur Posted February 24, 2019 (edited) 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 0 Share this post Link to post
Da Spadger Posted February 24, 2019 (edited) 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 0 Share this post Link to post
-TDRR- Posted February 24, 2019 (edited) 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- 0 Share this post Link to post
Da Spadger Posted February 24, 2019 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? 0 Share this post Link to post
-TDRR- Posted February 24, 2019 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. 0 Share this post Link to post
Da Spadger Posted February 24, 2019 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. 0 Share this post Link to post
Gez Posted February 25, 2019 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. 0 Share this post Link to post
Not Jabba Posted February 25, 2019 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. 0 Share this post Link to post
Gez Posted February 25, 2019 What if a pixel at the bottom is made visible? 0 Share this post Link to post
Not Jabba Posted February 25, 2019 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. 0 Share this post Link to post