GZDoom 2.0.02 Third beta release

News about GZDoom.

Moderator: Graf Zahl

Blue Shadow
Global Moderator
Global Moderator
Posts: 308
Joined: Sun Aug 29, 2010 6:09

Re: GZDoom 2.0.02 Third beta release

Post by Blue Shadow »

@Graf: Just wondering, are you aware of this, or did you miss it by a chance?
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: GZDoom 2.0.02 Third beta release

Post by Graf Zahl »

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?
Blue Shadow
Global Moderator
Global Moderator
Posts: 308
Joined: Sun Aug 29, 2010 6:09

Re: GZDoom 2.0.02 Third beta release

Post by Blue Shadow »

Graf Zahl wrote:if I remember correctly, your driver still doesn't support full GL 4.4, right?
Yes, still no GL 4.4 for me. I only got full support for 4.2.

I'm thinking of trying this, but I'm hesitant...
Ralgor
Posts: 22
Joined: Mon Sep 01, 2014 21:59

Re: GZDoom 2.0.02 Third beta release

Post by Ralgor »

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.
Ralgor
Posts: 22
Joined: Mon Sep 01, 2014 21:59

Re: GZDoom 2.0.02 Third beta release

Post by Ralgor »

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. :)
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: GZDoom 2.0.02 Third beta release

Post by Graf Zahl »

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.
Ralgor
Posts: 22
Joined: Mon Sep 01, 2014 21:59

Re: GZDoom 2.0.02 Third beta release

Post by Ralgor »

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.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: GZDoom 2.0.02 Third beta release

Post by Graf Zahl »

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.)
Ralgor
Posts: 22
Joined: Mon Sep 01, 2014 21:59

Re: GZDoom 2.0.02 Third beta release

Post by Ralgor »

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.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: GZDoom 2.0.02 Third beta release

Post by Graf Zahl »

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.
Ralgor
Posts: 22
Joined: Mon Sep 01, 2014 21:59

Re: GZDoom 2.0.02 Third beta release

Post by Ralgor »

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.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: GZDoom 2.0.02 Third beta release

Post by Graf Zahl »

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.
Ralgor
Posts: 22
Joined: Mon Sep 01, 2014 21:59

Re: GZDoom 2.0.02 Third beta release

Post by Ralgor »

I actually checked to see if I could get that to reproduce on the open source r600 driver... but nope. Works fine.
Edward-san
Developer
Developer
Posts: 197
Joined: Sun Nov 29, 2009 16:36

Re: GZDoom 2.0.02 Third beta release

Post by Edward-san »

Before releasing something, please have a look at this compiler error:

[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>(  )
[/spoiler]

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.
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.)

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.
4)'mBlockAlign' is unsigned, so 'mBlockAlign >= 0' is always true.

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)
            ~~~~~~~~~~~ ^  ~
5)a classical 'unsigned vs signed' comparison

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)
                    ~~~~~~~~~ ^ ~~~~~~~~~~
[/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]Image[/spoiler]

My GPU is Intel Sandybridge Mobile, which supports GL 3.0.
Ralgor
Posts: 22
Joined: Mon Sep 01, 2014 21:59

Re: GZDoom 2.0.02 Third beta release

Post by Ralgor »

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]Image[/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.
Locked

Return to “News”