This is another SDL backend problem.
When I was working with the fullscreen hack, I've removed _MSC_VER condition from gl_PrintStartupLog.
I didn't get any crashes from that, but after thinking about the output, I've noticed that it's subtly incorrect.
My old integrated Intel, that supports OpenGL 3.0 was logged as not supporting 3.2, yet it does support 3.3, but only in core profile.
The version reported in compatibility profile is 3.0.
The reason for this is quite simple, though a fix might not be.
I'm close to certain that GZDoom uses 3.3 core profile, once it's initialized by SDL_GL_CreateContext, but gl_PrintStartupLog runs before that point, producing incorrect values. That might be the reason behind those crashes in the comment.
OpenGL context not queried correctly
Moderator: Graf Zahl
-
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
Re: OpenGL context not queried correctly
GZDoom can use core profile only if some GL 4.4 extensions are present. A pure GL 3.3 core profile is absolutely useless. Without persistently mapped buffers the engine still needs glTexCoord and glVertex which are compatibility profile only.
-
- Posts: 18
- Joined: Sat Apr 11, 2015 5:30
Re: OpenGL context not queried correctly
Once again...:sigh:...Graf Zahl wrote:GZDoom can use core profile only if some GL 4.4 extensions are present. A pure GL 3.3 core profile is absolutely useless. Without persistently mapped buffers the engine still needs glTexCoord and glVertex which are compatibility profile only.
Yet, I'm close to certain, that this core profile is the one that GZDoom actually uses, simply cause it's the once SDL picks.
-
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
Re: OpenGL context not queried correctly
Don't you think I know my own engine better?
No, the core profile only gets picked if it's either GL 4.4 or presence of GL_ARB_buffer_storage availability.
Core profile without persistently mapped buffers is too slow.
No, the core profile only gets picked if it's either GL 4.4 or presence of GL_ARB_buffer_storage availability.
Core profile without persistently mapped buffers is too slow.
-
- Posts: 18
- Joined: Sat Apr 11, 2015 5:30
Re: OpenGL context not queried correctly
Well, a funny thing here, GL_ARB_buffer_storage is available here, both on core and compatibility.
There's no GL_ARB_shader_storage_buffer_object though.
Though is seems I was wrong in part, 3.0 is indeed picked.
Yet, an attempt to explicitly pick core seems ignored...
There's no GL_ARB_shader_storage_buffer_object though.
Though is seems I was wrong in part, 3.0 is indeed picked.
Yet, an attempt to explicitly pick core seems ignored...
-
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
Re: OpenGL context not queried correctly
If it picks compatibility over core, it means that the check for usability of the core profile failed.
The requirements are as follows:
- if version >= 4.4, pick core.
- if the glGetStringi function is not found, pick compatibility (this is the only defined method to get the extension string in core profile.)
- if GL_ARB_buffer_storage is found, pick core
- otherwise pick compatibility
The requirements are as follows:
- if version >= 4.4, pick core.
- if the glGetStringi function is not found, pick compatibility (this is the only defined method to get the extension string in core profile.)
- if GL_ARB_buffer_storage is found, pick core
- otherwise pick compatibility