GZDoom 2.0.02 Third beta release
Moderator: Graf Zahl
-
- Global Moderator
- Posts: 308
- Joined: Sun Aug 29, 2010 6:09
Re: GZDoom 2.0.02 Third beta release
@Graf: Just wondering, are you aware of this, or did you miss it by a chance?
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: GZDoom 2.0.02 Third beta release
I can't reproduce it. I neither get lag nor flickering, everything looks fine. It must be something that only happens with older hardware, if I remember correctly, your driver still doesn't support full GL 4.4, right?
-
- Global Moderator
- Posts: 308
- Joined: Sun Aug 29, 2010 6:09
Re: GZDoom 2.0.02 Third beta release
Yes, still no GL 4.4 for me. I only got full support for 4.2.Graf Zahl wrote:if I remember correctly, your driver still doesn't support full GL 4.4, right?
I'm thinking of trying this, but I'm hesitant...
-
- Posts: 22
- Joined: Mon Sep 01, 2014 21:59
Re: GZDoom 2.0.02 Third beta release
Have you tried compiling this under linux? I just tried and got compile errors:
gzdoom/src/./gl/utility/gl_clock.h: In member function ‘void glcycle_t::Clock()’:
gzdoom/src/./gl/utility/gl_clock.h:79:21: error: ‘gl_benching’ was not declared in this scope
long long time = (gl_benching? GetClockCycle() : 0);
gzdoom/src/gl/textures/gl_texture.cpp: In function ‘void Cmd_textureinfo(FCommandLine&, APlayerPawn*, int)’:
gzdoom/src/gl/textures/gl_texture.cpp:817:118: error: cannot pass objects of non-trivially-copyable type ‘class FString’ through ‘...’
Printf(PRINT_LOG, "Texture '%s' (Index %d, Lump %d, Name '%s'):\n", tex->Name, i, lump, Wads.GetLumpFullName(lump));
The first one looks pretty trivial to fix, but I don't really know what's going on with the second one.
I'm using gcc 4.9.1 to compile.
gzdoom/src/./gl/utility/gl_clock.h: In member function ‘void glcycle_t::Clock()’:
gzdoom/src/./gl/utility/gl_clock.h:79:21: error: ‘gl_benching’ was not declared in this scope
long long time = (gl_benching? GetClockCycle() : 0);
gzdoom/src/gl/textures/gl_texture.cpp: In function ‘void Cmd_textureinfo(FCommandLine&, APlayerPawn*, int)’:
gzdoom/src/gl/textures/gl_texture.cpp:817:118: error: cannot pass objects of non-trivially-copyable type ‘class FString’ through ‘...’
Printf(PRINT_LOG, "Texture '%s' (Index %d, Lump %d, Name '%s'):\n", tex->Name, i, lump, Wads.GetLumpFullName(lump));
The first one looks pretty trivial to fix, but I don't really know what's going on with the second one.
I'm using gcc 4.9.1 to compile.
-
- Posts: 22
- Joined: Mon Sep 01, 2014 21:59
Re: GZDoom 2.0.02 Third beta release
I managed to fix those in my copy. Both of them ended up being fairly trivial, although I don't know if what I did is actually correct. I moved the extern bool gl_benching line up to get it out of the ifdef, and added (const char *) before the tex->Name to fix the second one.
However, gzdoom now doesn't run because it says my driver doesn't support opengl 3.3, despite the fact that it sort of does. The problem is that the open source driver for the R600 only supports opengl 3.3 in the core profile, and not the compatibility profile. I have no idea if you're using the compatibility stuff.
Note that 1.8.6 ran fine. Also, the open source driver does support ARB_buffer_storage, which is why I was going to try it.
However, gzdoom now doesn't run because it says my driver doesn't support opengl 3.3, despite the fact that it sort of does. The problem is that the open source driver for the R600 only supports opengl 3.3 in the core profile, and not the compatibility profile. I have no idea if you're using the compatibility stuff.
Note that 1.8.6 ran fine. Also, the open source driver does support ARB_buffer_storage, which is why I was going to try it.
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: GZDoom 2.0.02 Third beta release
GZDoom either requires a GL 4.4 core or a 3.3 compatibility profile.
With 3.3 core there is no way to upload the buffers fast enough, they all stall the renderer quite badly. The only method fast enough is good old glBegin/glEnd.
With 3.3 core there is no way to upload the buffers fast enough, they all stall the renderer quite badly. The only method fast enough is good old glBegin/glEnd.
-
- Posts: 22
- Joined: Mon Sep 01, 2014 21:59
Re: GZDoom 2.0.02 Third beta release
It looks like SDL 1.2 doesn't support creating core profiles at all, or at least not without using a fork or hack or something. The only way to create a core profile would be to use SDL2.
At any rate, GL_ARB_shader_storage_buffer_object isn't supported in the open source drivers yet. So at this point, GZDoom 2.0 won't support the open source drivers in linux at all. A binary driver will be required.
The missing extension will eventually be supported, though. At the rate development is happening, it might happen within a year. But the problem with creating core profiles will still remain unless SDL2 is used.
At any rate, GL_ARB_shader_storage_buffer_object isn't supported in the open source drivers yet. So at this point, GZDoom 2.0 won't support the open source drivers in linux at all. A binary driver will be required.
The missing extension will eventually be supported, though. At the rate development is happening, it might happen within a year. But the problem with creating core profiles will still remain unless SDL2 is used.
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: GZDoom 2.0.02 Third beta release
Why do the open source drivers not support compatibility profiles for more recent versions?
That makes them basically useless for a lot of software. The same problem exists with Apple. It's either old crap or being restricted to a core profile, letting everything in between fall into a deep void.
(BTW, although GL_ARB_shader_storage_buffer_object is used, it can be fully substituted by uniform buffers, they just create a bit more overhead. The real problem is GL_ARB_buffer_storage, because I need persistently mapped vertex buffers.)
That makes them basically useless for a lot of software. The same problem exists with Apple. It's either old crap or being restricted to a core profile, letting everything in between fall into a deep void.
(BTW, although GL_ARB_shader_storage_buffer_object is used, it can be fully substituted by uniform buffers, they just create a bit more overhead. The real problem is GL_ARB_buffer_storage, because I need persistently mapped vertex buffers.)
-
- Posts: 22
- Joined: Mon Sep 01, 2014 21:59
Re: GZDoom 2.0.02 Third beta release
I managed to make it work with just gl 3.0 compatibility (and thus with the open source drivers), without any real changes.
What's the recommended way to submit code? I also found a couple bugs.
What's the recommended way to submit code? I also found a couple bugs.
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: GZDoom 2.0.02 Third beta release
Either make a patch or a Github pull request. If both fails, zip the modified files and attach them to a post in this thread.
-
- Posts: 22
- Joined: Mon Sep 01, 2014 21:59
Re: GZDoom 2.0.02 Third beta release
I made an account on github so I could push my changes up that way, and then I made a pull request. I've been meaning to make one for a long time, so this gives me the incentive to do it.
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: GZDoom 2.0.02 Third beta release
Thanks, I moved a bit of code around - the gl state should be initialized in gl_LoadExtensions, but overall it's ok.
As for GL requirements, it was only 3.3 because I previously used texture swizzle for alpha textures, but since I changed that code and removed the dependency I think 3.0 is fine.
Any later feature must be extension-checked anyway.
There's one thing left - the problem with lights on reflective surfaces. Once this gets fixed I'll do an official release.
As for GL requirements, it was only 3.3 because I previously used texture swizzle for alpha textures, but since I changed that code and removed the dependency I think 3.0 is fine.
Any later feature must be extension-checked anyway.
There's one thing left - the problem with lights on reflective surfaces. Once this gets fixed I'll do an official release.
-
- Posts: 22
- Joined: Mon Sep 01, 2014 21:59
Re: GZDoom 2.0.02 Third beta release
I actually checked to see if I could get that to reproduce on the open source r600 driver... but nope. Works fine.
-
- Developer
- Posts: 197
- Joined: Sun Nov 29, 2009 16:36
Re: GZDoom 2.0.02 Third beta release
Before releasing something, please have a look at this compiler error:
[spoiler][/spoiler]
have a look at these warnings:
[spoiler]1)array index 6 is past the end of the array
2)GLDIT_POLY from GLDrawItemType enumeration is not handled in switch (I see that it was never used at all in the gl code ... redundant? Removing it made no problems.)
4)'mBlockAlign' is unsigned, so 'mBlockAlign >= 0' is always true.
5)a classical 'unsigned vs signed' comparison
[/spoiler]
Also, I noticed a strange flickering effect with a door in ZDoomEditDemo_v1_2.pk3 in map02. See the screenshot with the coordinates:
[spoiler][/spoiler]
My GPU is Intel Sandybridge Mobile, which supports GL 3.0.
[spoiler]
Code: Select all
/home/edward-san/zdoom/gzdoom/trunk/src/gl/dynlights/gl_lightbuffer.cpp:175:25: error:
non-constant-expression cannot be narrowed from type 'int' to 'float' in
initializer list [-Wc++11-narrowing]
float parmcnt[] = { 0, size0, size0 + size1, size0 + size1 + size2 };
^~~~~
/home/edward-san/zdoom/gzdoom/trunk/src/gl/dynlights/gl_lightbuffer.cpp:175:25: note:
insert an explicit cast to silence this issue
float parmcnt[] = { 0, size0, size0 + size1, size0 + size1 + size2 };
^~~~~
static_cast<float>( )
/home/edward-san/zdoom/gzdoom/trunk/src/gl/dynlights/gl_lightbuffer.cpp:175:32: error:
non-constant-expression cannot be narrowed from type 'int' to 'float' in
initializer list [-Wc++11-narrowing]
float parmcnt[] = { 0, size0, size0 + size1, size0 + size1 + size2 };
^~~~~~~~~~~~~
/home/edward-san/zdoom/gzdoom/trunk/src/gl/dynlights/gl_lightbuffer.cpp:175:32: note:
insert an explicit cast to silence this issue
float parmcnt[] = { 0, size0, size0 + size1, size0 + size1 + size2 };
^~~~~~~~~~~~~
static_cast<float>( )
/home/edward-san/zdoom/gzdoom/trunk/src/gl/dynlights/gl_lightbuffer.cpp:175:47: error:
non-constant-expression cannot be narrowed from type 'int' to 'float' in
initializer list [-Wc++11-narrowing]
float parmcnt[] = { 0, size0, size0 + size1, size0 + size1 + size2 };
^~~~~~~~~~~~~~~~~~~~~
/home/edward-san/zdoom/gzdoom/trunk/src/gl/dynlights/gl_lightbuffer.cpp:175:47: note:
insert an explicit cast to silence this issue
float parmcnt[] = { 0, size0, size0 + size1, size0 + size1 + size2 };
^~~~~~~~~~~~~~~~~~~~~
static_cast<float>( )
have a look at these warnings:
[spoiler]1)array index 6 is past the end of the array
Code: Select all
/home/edward-san/zdoom/gzdoom/trunk/src/gl/textures/gl_samplers.cpp:59:22: warning: array index 6 is past the end of the array (which contains 6 elements) [-Warray-bounds]
glSamplerParameterf(mSamplers[6], GL_TEXTURE_MAX_ANISOTROPY_EXT, 1.f);
^ ~
/home/edward-san/zdoom/gzdoom/trunk/src/gl/textures/gl_samplers.h:10:2: note: array 'mSamplers' declared here
unsigned int mSamplers[6];
^
/home/edward-san/zdoom/gzdoom/trunk/src/gl/textures/gl_samplers.cpp:108:22: warning: array index 6 is past the end of the array (which contains 6 elements) [-Warray-bounds]
glSamplerParameteri(mSamplers[6], GL_TEXTURE_MIN_FILTER, TexFilter[gl_texture_filter].magfilter);
^ ~
/home/edward-san/zdoom/gzdoom/trunk/src/gl/textures/gl_samplers.h:10:2: note: array 'mSamplers' declared here
unsigned int mSamplers[6];
^
/home/edward-san/zdoom/gzdoom/trunk/src/gl/textures/gl_samplers.cpp:109:22: warning: array index 6 is past the end of the array (which contains 6 elements) [-Warray-bounds]
glSamplerParameteri(mSamplers[6], GL_TEXTURE_MAG_FILTER, TexFilter[gl_texture_filter].magfilter);
^ ~
/home/edward-san/zdoom/gzdoom/trunk/src/gl/textures/gl_samplers.h:10:2: note: array 'mSamplers' declared here
unsigned int mSamplers[6];
^
3 warnings generated.
Code: Select all
/home/edward-san/zdoom/gzdoom/trunk/src/gl/scene/gl_drawinfo.cpp:632:11: warning: enumeration value 'GLDIT_POLY' not handled in switch [-Wswitch]
switch(drawitems[node->itemindex].rendertype)
^
/home/edward-san/zdoom/gzdoom/trunk/src/gl/scene/gl_drawinfo.cpp:661:12: warning: enumeration value 'GLDIT_POLY' not handled in switch [-Wswitch]
switch(drawitems[node->itemindex].rendertype)
^
/home/edward-san/zdoom/gzdoom/trunk/src/gl/scene/gl_drawinfo.cpp:694:9: warning: enumeration value 'GLDIT_POLY' not handled in switch [-Wswitch]
switch(drawitems[i].rendertype)
^
3 warnings generated.
Code: Select all
/home/edward-san/zdoom/gzdoom/trunk/src/gl/dynlights/gl_lightbuffer.cpp:108:18: warning: comparison of unsigned expression >= 0 is always true [-Wtautological-compare]
if (mBlockAlign >= 0 && totalsize + (mIndex % mBlockAlign) > mBlockSize)
~~~~~~~~~~~ ^ ~
Code: Select all
/home/edward-san/zdoom/gzdoom/trunk/src/gl/dynlights/gl_lightbuffer.cpp:113:17: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
if (totalsize > mBlockSize)
~~~~~~~~~ ^ ~~~~~~~~~~
Also, I noticed a strange flickering effect with a door in ZDoomEditDemo_v1_2.pk3 in map02. See the screenshot with the coordinates:
[spoiler][/spoiler]
My GPU is Intel Sandybridge Mobile, which supports GL 3.0.
-
- Posts: 22
- Joined: Mon Sep 01, 2014 21:59
Re: GZDoom 2.0.02 Third beta release
I just compiled v2.x on windows, and with that build the "burn" screen wipe style is causing a nearly all white screen while the burn is occurring. "Melt" doesn't have the problem, and works normally.
Edit: The same code under linux seems to work. Odd.
Edit2: Here's a screenshot. Note that the image seems to be upside down.
There's a good chance there's something messed up on my end. I'm going to wipe everything out and rebuild I think.
[spoiler][/spoiler]
Edit3: A complete rebuild didn't fix it.
Edit: The same code under linux seems to work. Odd.
Edit2: Here's a screenshot. Note that the image seems to be upside down.
There's a good chance there's something messed up on my end. I'm going to wipe everything out and rebuild I think.
[spoiler][/spoiler]
Edit3: A complete rebuild didn't fix it.
Last edited by Ralgor on Tue Sep 16, 2014 5:19, edited 3 times in total.