No gun? No sprites? READ THIS! [AMD+OpenGL]
Moderator: GZDoom Developers
Forum rules
Contrary to popular belief, we are not all-knowing-all-seeing magical beings!
If you want help you're going to have to provide lots of info. Like what is your hardware, what is your operating system, what version of GZDoom/LZDoom/whatever you're using, what mods you're loading, how you're loading it, what you've already tried for fixing the problem, and anything else that is even remotely relevant to the problem.
We can't magically figure out what it is if you're going to be vague, and if we feel like you're just wasting our time with guessing games we will act like that's what you're really doing and won't help you.
Contrary to popular belief, we are not all-knowing-all-seeing magical beings!
If you want help you're going to have to provide lots of info. Like what is your hardware, what is your operating system, what version of GZDoom/LZDoom/whatever you're using, what mods you're loading, how you're loading it, what you've already tried for fixing the problem, and anything else that is even remotely relevant to the problem.
We can't magically figure out what it is if you're going to be vague, and if we feel like you're just wasting our time with guessing games we will act like that's what you're really doing and won't help you.
-
Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49066
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: No gun? No sprites? READ THIS!
-glversion 2 disables nearly all advanced features, so that's not a solution.
-
Guest
Re: No gun? No sprites? READ THIS!
I noticed that. There's a lot missing from the options menu. It's definitely not optimal and I'd prefer to have all the features working if possible.
I'm definitely going to be keeping up with this in the hope that it can be fixed and run properly, and I probably won't actually play it until this issue is resolved.
By "acceptable" I only meant that it works at least. I can run the game and play it in VR if all else fails without having to install the old GPU driver.
I'm definitely going to be keeping up with this in the hope that it can be fixed and run properly, and I probably won't actually play it until this issue is resolved.
By "acceptable" I only meant that it works at least. I can run the game and play it in VR if all else fails without having to install the old GPU driver.
Re: No gun? No sprites? READ THIS!
Curiously with GZDoom Modern and current AMD Drivers 18.8.1, using -glversion 3.3 works but 4 doesn't. I don't know if "3.3" is just read as "3" or anything but this seems like a much better work around than 2 which isn't supported in modern.
I haven't tried 18.7.1 mostly due to terrible freezing problems (which can be fixed by disabling HDCP on all monitors btw), but it was all working fine with 18.6.1 drivers.
I haven't tried 18.7.1 mostly due to terrible freezing problems (which can be fixed by disabling HDCP on all monitors btw), but it was all working fine with 18.6.1 drivers.
-
Contrabardus
- Posts: 8
- Joined: Mon Aug 13, 2018 9:09 am
Re: No gun? No sprites? READ THIS!
Can confirm. 3.0-3.9 all work as launch options. I'm also unsure if adding the .X matters or not regarding what version it uses. Going to 4.0 and above breaks it again.
The nice thing about this is that all features are present in the options menu again, including the 3D/VR options. I can actually play this again now and still have most of the nice modern GZDoom features working, which is nice.
Still a no go on the latest version though.
The nice thing about this is that all features are present in the options menu again, including the 3D/VR options. I can actually play this again now and still have most of the nice modern GZDoom features working, which is nice.
Still a no go on the latest version though.
-
Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49066
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: No gun? No sprites? READ THIS!
There is only OpenGL 3.3. Any 3.x will have the same result, essentially.
From the fact that this works I suspect it's the hardware clipping planes that exhibit some bad behavior.
There's exactly 3 differences between GL3 and GL4 mode:
On ATI/AMD, hardware clip planes are disabled on GL3 because on old drivers they were nonfunctional.
GL3 falls back to the old buffer API. I cannot imagine this to be the cause because everything else works fine.
GL3 also does not use shader storage buffers, but those do not even come into play for sprites because they are not affected by dynamic lighting at all.
First checks to do:
Instead of using -glversion 3.3, start the engine with "-lightmethod deferred" or "-buffermethod deferred" respectively and report how that looks.
If that does not help we need input from someone with a compiler setup.
Please check out the gl_LoadExtensions function in gl_interface.cpp and selectively comment in or out the setting of the various RFL_* flags, to see if setting any of these flags makes a difference. These 5 flags are currently relevant. Like I said, I suspect the clip planes so testing RFL_NO_CLIP_PLANES should come first.
RFL_SHADER_STORAGE_BUFFER = 4,
RFL_BUFFER_STORAGE = 8,
RFL_NO_CLIP_PLANES = 32,
RFL_INVALIDATE_BUFFER = 64,
RFL_DEBUG = 128,
From the fact that this works I suspect it's the hardware clipping planes that exhibit some bad behavior.
There's exactly 3 differences between GL3 and GL4 mode:
On ATI/AMD, hardware clip planes are disabled on GL3 because on old drivers they were nonfunctional.
GL3 falls back to the old buffer API. I cannot imagine this to be the cause because everything else works fine.
GL3 also does not use shader storage buffers, but those do not even come into play for sprites because they are not affected by dynamic lighting at all.
First checks to do:
Instead of using -glversion 3.3, start the engine with "-lightmethod deferred" or "-buffermethod deferred" respectively and report how that looks.
If that does not help we need input from someone with a compiler setup.
Please check out the gl_LoadExtensions function in gl_interface.cpp and selectively comment in or out the setting of the various RFL_* flags, to see if setting any of these flags makes a difference. These 5 flags are currently relevant. Like I said, I suspect the clip planes so testing RFL_NO_CLIP_PLANES should come first.
RFL_SHADER_STORAGE_BUFFER = 4,
RFL_BUFFER_STORAGE = 8,
RFL_NO_CLIP_PLANES = 32,
RFL_INVALIDATE_BUFFER = 64,
RFL_DEBUG = 128,
-
Contrabardus
- Posts: 8
- Joined: Mon Aug 13, 2018 9:09 am
Re: No gun? No sprites? READ THIS!
-lightmethod deferred doesn't do anything. No sprites as usual.
-buffermethod deferred causes a crash with error. C0000005 (Access Violation - tried to write address 000000000000868C)
Local.txt:
-buffermethod deferred causes a crash with error. C0000005 (Access Violation - tried to write address 000000000000868C)
Local.txt:
Spoiler:Report.txt:
Spoiler:Just realized that there's a 3.5.0 version out. Installed it and double checked, same results right down to the crash error.
Re: No gun? No sprites? READ THIS!
Same results here as Contrabardus, I'll pull down the git repo and see if I can get a compiler setup going.
-
Contrabardus
- Posts: 8
- Joined: Mon Aug 13, 2018 9:09 am
Re: No gun? No sprites? READ THIS!
No idea what I'm doing, but I had a look. Not much I can do there.Graf Zahl wrote:There is only OpenGL 3.3. Any 3.x will have the same result, essentially.
From the fact that this works I suspect it's the hardware clipping planes that exhibit some bad behavior.
There's exactly 3 differences between GL3 and GL4 mode:
On ATI/AMD, hardware clip planes are disabled on GL3 because on old drivers they were nonfunctional.
GL3 falls back to the old buffer API. I cannot imagine this to be the cause because everything else works fine.
GL3 also does not use shader storage buffers, but those do not even come into play for sprites because they are not affected by dynamic lighting at all.
First checks to do:
Instead of using -glversion 3.3, start the engine with "-lightmethod deferred" or "-buffermethod deferred" respectively and report how that looks.
If that does not help we need input from someone with a compiler setup.
Please check out the gl_LoadExtensions function in gl_interface.cpp and selectively comment in or out the setting of the various RFL_* flags, to see if setting any of these flags makes a difference. These 5 flags are currently relevant. Like I said, I suspect the clip planes so testing RFL_NO_CLIP_PLANES should come first.
RFL_SHADER_STORAGE_BUFFER = 4,
RFL_BUFFER_STORAGE = 8,
RFL_NO_CLIP_PLANES = 32,
RFL_INVALIDATE_BUFFER = 64,
RFL_DEBUG = 128,
I don't know how to code at all. I only know the very basics for how to compile source code. I like open source stuff, so I do it fairly frequently.
Configure and Generate with Cmake, then use MVS to build, is pretty much the extent of my skills for doing anything with GZDoom source. I have no experience beyond simply compiling and installing.
At any rate, I don't think I can be of much use beyond this point. None of the RFL entries have "= X" number values like those shown in the examples above in the gl_interface.cpp in the modern source version when I open it using MVS. Not sure what to do with anything there.
This is the gl_LoadExtentsions area of the file as I see it in the MVS edit window:
Spoiler:I've probably reached the end of where I can provide any useful input at this point. I'll still keep an eye on the thread to see how this goes, and maybe learn a little while I'm at it.
Last edited by Contrabardus on Wed Aug 15, 2018 6:40 am, edited 1 time in total.
Re: No gun? No sprites? READ THIS!
Not entirely sure if this is correct but setting line 202 of gl_interface.cpp to:
Works with sprites showing again.
Code: Select all
gl.flags |= RFL_SHADER_STORAGE_BUFFER | RFL_BUFFER_STORAGE | RFL_NO_CLIP_PLANES;-
Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49066
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: No gun? No sprites? READ THIS!
Thanks. So it is indeed the clip planes they screwed up. A very likely scenario is that they switched them to always on instead of making them switchable. Logically the shader does not set up its clip values if they are supposed to be off.
Please try the following:
Find this block of code in the main shader (shaders/glsl/main.vp in the gzdoom.pk3 project
and add
to give the formerly undefined case a defined value for the clip plane.
Please try the following:
Find this block of code in the main shader (shaders/glsl/main.vp in the gzdoom.pk3 project
Code: Select all
if (uClipHeightDirection != 0.0) // clip planes used for reflective flats
{
gl_ClipDistance[0] = (worldcoord.y - uClipHeight) * uClipHeightDirection;
}
else if (uClipLine.x > -1000000.0) // and for line portals - this will never be active at the same time as the reflective planes clipping so it can use the same hardware clip plane.
{
gl_ClipDistance[0] = -( (worldcoord.z - uClipLine.y) * uClipLine.z + (uClipLine.x - worldcoord.x) * uClipLine.w ) + 1.0/32768.0; // allow a tiny bit of imprecisions for colinear linedefs.
}
Code: Select all
else
{
gl_ClipDistance[0] = 1;
}
-
Contrabardus
- Posts: 8
- Joined: Mon Aug 13, 2018 9:09 am
Re: No gun? No sprites? READ THIS!
Confirmed, made the same edit, compiled the source, and sprites are present again.Lycanite wrote:Not entirely sure if this is correct but setting line 202 of gl_interface.cpp to:Works with sprites showing again.Code: Select all
gl.flags |= RFL_SHADER_STORAGE_BUFFER | RFL_BUFFER_STORAGE | RFL_NO_CLIP_PLANES;
Re: No gun? No sprites? READ THIS!
So I set that block to this:
But with no success, sprites are still not showing.
Edit: To clarify just in case, gun sprites are showing, it's just actor sprites that aren't.
Code: Select all
if (uClipHeightDirection != 0.0) // clip planes used for reflective flats
{
gl_ClipDistance[0] = (worldcoord.y - uClipHeight) * uClipHeightDirection;
}
else if (uClipLine.x > -1000000.0) // and for line portals - this will never be active at the same time as the reflective planes clipping so it can use the same hardware clip plane.
{
gl_ClipDistance[0] = -( (worldcoord.z - uClipLine.y) * uClipLine.z + (uClipLine.x - worldcoord.x) * uClipLine.w ) + 1.0/32768.0; // allow a tiny bit of imprecisions for colinear linedefs.
}
else
{
gl_ClipDistance[0] = 1;
}Edit: To clarify just in case, gun sprites are showing, it's just actor sprites that aren't.
-
Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49066
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: No gun? No sprites? READ THIS!
Ok. GZDoom uses 5 clip planes - numbers 0-4.
Just add gl_ClipDistance{i]=1; lines at the end, starting with i=0, until something changes. Looking at the code, planes 3 and 4 also can remain uninitialized if they are never used.
1 and 2 are always set so I do not expect those to be the cause.
Just add gl_ClipDistance{i]=1; lines at the end, starting with i=0, until something changes. Looking at the code, planes 3 and 4 also can remain uninitialized if they are never used.
1 and 2 are always set so I do not expect those to be the cause.
-
Contrabardus
- Posts: 8
- Joined: Mon Aug 13, 2018 9:09 am
Re: No gun? No sprites? READ THIS!
Same here. No sprites again.
Re: No gun? No sprites? READ THIS!
So from experimenting I've found that the problem is with gl_ClipDistance[2]
Sprites are showing again when changing
To
Sprites are showing again when changing
Code: Select all
gl_ClipDistance[2] = uClipSplit.y - worldcoord.y;Code: Select all
gl_ClipDistance[2] = 1;