Wall decals bleeding

[CaptainToenail]

I have a simple decal that is placed in the map using the Decal thing.

In Hardware renderer it displays as expected. However in software mode, it is buggy.

1. You can see the decal bleeding through walls
2. It also renders in mid-air when it encounters corners

Is this a known issue? See pics below. Top is software mode, bottom is hardware mode. This is with GZdoom 4-3-3.

---

---

[Graf Zahl]

I don't think it was ever meant to handle something this large. In the hardware renderer it works because the depth buffer automatically takes care of it.

[CaptainToenail]

The graphic is 128x128. I'll try something smaller later and see if that renders ok. Thanks for the quick response.

[dpJudas]

Does this happen with an earlier version of GZDoom? If it is a regression I think I may have an idea what could be causing it.

[CaptainToenail]

Ok, update time.

dpJudas wrote:
> Does this happen with an earlier version of GZDoom? If it is a regression I think
> I may have an idea what could be causing it.

So I downloaded a year old build, 3-7-1, and the decals render properly there.

It seems the bug also applies to other decals e.g. the Phoenix Rod scorch mark, so it's not restricted to my new decal alone.

[dpJudas]

Thanks for checking that. I'll try look into it once I figure out what this adl.lib file is about that gzdoom now can't find.

[Graf Zahl]

You'll have to delete and recreate the solution. Some CMake fuckup.
If you have to switch between pre- and post- ZMusic builds, better use different directories. For some reason CMake remembers obsolete settings and creates bogus projects.

[dpJudas]

You'll have to delete and recreate the solution. Some CMake fuckup.
If you have to switch between pre- and post- ZMusic builds, better use different directories. For some reason CMake remembers obsolete settings and creates bogus projects.

Thanks. That did the trick.

I really hate testing that possibility tho because my gzdoom output folders is always full of bunch of pk3s and other test stuff. If I clean it out murphy's law dictates I would like to test something with one of them 1 day later.

[dpJudas]

Okay, I pushed a fix for what I believe is the cause of this. That said, I don't have much to test with so I dunno if it fixed it or not.

[drfrag]

Deleting the CMake cache should fix it.

[Graf Zahl]

I really hate testing that possibility tho because my gzdoom output folders is always full of bunch of pk3s and other test stuff. If I clean it out murphy's law dictates I would like to test something with one of them 1 day later.

You really shouldn't save the output inside the CMake project folder. I deliberately keep that free of any final output data so that deleting it is harmless when necessary.

[Rachael]

I symlink my CMake-built GZDoom executable from elsewhere. I absolutely refuse to run it from within the CMake project folder because I intentionally designated it to be volatile - so that if I need to rebuild from scratch, it's a few simple commands to do so and I am back up and running within minutes and no additional setup required.

If I absolutely must directly use my CMake copy, then I will just copy my .ini from elsewhere since it has all the references to all my game data elsewhere in my system and makes it easy to find without copying it into the folder.

[Graf Zahl]

I normally use the 'oldstyle' setting and keep the target directory outside the GZDoom project folder hierarchy. And that directory never gets deleted when I have to mess around with the project which sometimes is unavoidable.

[dpJudas]

It isn't that I can't come up with a more elaborate solution if I put my mind to it. It is just that I'm lazy and dumps the files into the folder where gzdoom picks it up, and that happens to be the build folder the way cmake+visualstudio works.

Btw. what is this oldstyle setting exactly? Something in CMake's setup?

[Graf Zahl]

It isn't that I can't come up with a more elaborate solution if I put my mind to it. It is just that I'm lazy and dumps the files into the folder where gzdoom picks it up, and that happens to be the build folder the way cmake+visualstudio works.

There's two kinds of lazy.
First, the one where you won't do some things because they are time consuming and not really necessary (like not cleaning the house every week, when doing it once a month is really enough.)
Second, the kind where you make your life miserable by not investing a minor amount of time to solve a problem that'll bite you in the ass later.

This clearly is the second kind of 'lazy'!

Btw. what is this oldstyle setting exactly? Something in CMake's setup?

You can set the binary output folder in CMake.
This oldstyle setting also allows placing release, debug and relwithdebinfo builds into the same folder by renaming the executables.