DRD Team

Call to CheckExtension() returns false. According to this it's in Core since 3.1 which explains why it works with the line commented out. I think that the first version comparison in that if() needs to be adjusted.

By the way, are you about to remove OpenGL 2.x path completely? I'm thinking about an addition of legacy fallback if core context creation failed. At the moment there is no check in Cocoa backend at all. It was OK for OpenGL 2.1 but with the introduction of Core Profile it should be handled I guess.

No, the fallback will stay in. There's just too many old systems out there that still need support.

As for the extension, it should be supported so I wonder why the check fails. I think that's the real problem here. Altering the 'if' is only circumventing the actual error here.

As far as I remember the list of extensions was quite short. I cannot confirm this yet but it seems like core features are not reported as extensions.

Can you post your startup log?

A few startup logs for comparison:

Spoiler: nVidia 9400M on 10.7

---

Code: Select all

GL_VENDOR: NVIDIA Corporation
GL_RENDERER: NVIDIA GeForce 9400M OpenGL Engine
GL_VERSION: 3.2 NVIDIA-7.32.12 (Core profile)
GL_SHADING_LANGUAGE_VERSION: 1.50
GL_EXTENSIONS: GL_ARB_instanced_arrays GL_ARB_occlusion_query2 GL_ARB_shader_bit_encoding GL_ARB_timer_query GL_EXT_depth_bounds_test GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_EXT_texture_mirror_clamp GL_EXT_texture_sRGB_decode GL_APPLE_client_storage GL_APPLE_container_object_shareable GL_APPLE_object_purgeable GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_texture_range
Max. texture size: 8192
Max. texture units: 16
Max. varying: 16

Spoiler: nVidia 750M on 10.11

---

Code: Select all

GL_VENDOR: NVIDIA Corporation
GL_RENDERER: NVIDIA GeForce GT 750M OpenGL Engine
GL_VERSION: 4.1 NVIDIA-10.10.13 310.42.25f01 (Core profile)
GL_SHADING_LANGUAGE_VERSION: 4.10
GL_EXTENSIONS: GL_ARB_blend_func_extended GL_ARB_draw_buffers_blend GL_ARB_draw_indirect GL_ARB_ES2_compatibility GL_ARB_explicit_attrib_location GL_ARB_gpu_shader_fp64 GL_ARB_gpu_shader5 GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_occlusion_query2 GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_subroutine GL_ARB_shading_language_include GL_ARB_tessellation_shader GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_cube_map_array GL_ARB_texture_gather GL_ARB_texture_query_lod GL_ARB_texture_rgb10_a2ui GL_ARB_texture_storage GL_ARB_texture_swizzle GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_vertex_attrib_64bit GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_depth_bounds_test GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_EXT_texture_mirror_clamp GL_EXT_texture_sRGB_decode GL_APPLE_client_storage GL_APPLE_container_object_shareable GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_texture_range GL_ATI_texture_mirror_once GL_NV_texture_barrier
Max. texture size: 16384
Max. texture units: 16
Max. varying: 16
Max. uniform block size: 65536
Uniform block alignment: 256

Spoiler: Intel Iris Pro on 10.11

---

Code: Select all

GL_VENDOR: Intel Inc.
GL_RENDERER: Intel Iris Pro OpenGL Engine
GL_VERSION: 4.1 INTEL-10.14.73 (Core profile)
GL_SHADING_LANGUAGE_VERSION: 4.10
GL_EXTENSIONS: GL_ARB_blend_func_extended GL_ARB_draw_buffers_blend GL_ARB_draw_indirect GL_ARB_ES2_compatibility GL_ARB_explicit_attrib_location GL_ARB_gpu_shader_fp64 GL_ARB_gpu_shader5 GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_occlusion_query2 GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_subroutine GL_ARB_shading_language_include GL_ARB_tessellation_shader GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_cube_map_array GL_ARB_texture_gather GL_ARB_texture_query_lod GL_ARB_texture_rgb10_a2ui GL_ARB_texture_storage GL_ARB_texture_swizzle GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_vertex_attrib_64bit GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_EXT_texture_sRGB_decode GL_APPLE_client_storage GL_APPLE_container_object_shareable GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_texture_range GL_ATI_texture_mirror_once GL_NV_texture_barrier
Max. texture size: 16384
Max. texture units: 16
Max. varying: 16
Max. uniform block size: 65536
Uniform block alignment: 256

There is no GL_ARB_uniform_buffer_object extension in the list but it's definitely supported as a part of Core Profile.

That's odd. I think the best thing in this case is to skip the CheckExtension call on Macs. Regardless, I think if any hardware does not support this extension it has to be demoted to legacy support no matter what.

From OpenGL 3.1 Specification:

H.3.51 Uniform Buffer Objects
The name string for uniform buffer objects is GL_ARB_uniform_buffer_object. This extension is equivalent to new core functionality introduced in OpenGL 3.1 and is provided to enable this functionality in older drivers.

I'm curious why does the check expect OpenGL 3.3? Does the implementation use something introduced in it? If not, shouldn't version require an adjustment?

BTW the same spec states:

H.3.2 Promoting Extensions to Core Features
ARB extensions can be promoted to required core features in later revisions of OpenGL. When this occurs, the extension specifications are merged into the core specification. Functions and enumerants that are part of such promoted extensions will have the ARB affix removed.

GL implementations of such later revisions should continue to export the name strings of promoted extensions in the EXTENSIONS strings and continue to support the ARB-affixed versions of functions and enumerants as a transition aid.

Maybe I got it wrong or maybe Apple did so... I think the names of the extensions that became core features must be reported anyway.

EDIT: This answer seems to share the same thought.

_mental_ wrote:From OpenGL 3.1 Specification:

H.3.51 Uniform Buffer Objects
The name string for uniform buffer objects is GL_ARB_uniform_buffer_object. This extension is equivalent to new core functionality introduced in OpenGL 3.1 and is provided to enable this functionality in older drivers.

I'm curious why does the check expect OpenGL 3.3? Does the implementation use something introduced in it? If not, shouldn't version require an adjustment?

I checked against 3.3 because the reference I used said that this was the version where the feature was made core. If the feature was made core in 3.1 the check needs to be altered.

GL implementations of such later revisions should continue to export the name strings of promoted extensions in the EXTENSIONS strings and continue to support the ARB-affixed versions of functions and enumerants as a transition aid.

Maybe I got it wrong or maybe Apple did so... I think the names of the extensions that became core features must be reported anyway.

I guess Apple's reasoning was that they do not allow any core contexts lower than 3.2 so that version's feature set was used as a baseline.

BTW, I'm a bit puzzled that the 9400M does not have GL_ARB_sampler_objects. The hardware can do it for sure.

It's in Core since 3.3 so I need to install macOS 10.9 in order to get support for sampler objects. Despite Apple's laziness it's a good point to do not use outdated software

I say, keep opengl 2.1 compatibility as long as possible (or at least until I buy a new machine ). Semi-seriously, Doom is an old game played mainly by old people who tend to possess old machines.

drako wrote:Doom is an old game played mainly by old people who tend to possess old machines.

That's clearly not correct. The majority of users here uses up-to-date hardware.


Regarding 2.x support, it will remain as long as it won't get in the way of some actual improvements. But I cannot count out some feature regressions if I think that some part of the compatibility fallback has to go for maintainability reasons.

People with old machine tend to play with vanilla doom ...
Or doom legacy in case they want to use the glider engine

ibm5155 wrote: People with old machine tend to play with vanilla doom ...
Or doom legacy in case they want to use the glider engine

Also not correct, or there wouldn't be people here asking to keep OpenGL 2.1 support in GZDoom, or anyone on the ZDoom forum getting upset with Win9x support being dropped.

Just because they are a minority does not mean they aren't here.

I still occasionally see people browsing this site on Windows XP with IE 6. Service pack 2, even. I have no idea what hardware is running that, but I can almost promise you it's not something you've bought at a chain retailer within the past year. Anything that they did can probably just about all of those can run GZDoom's OpenGL3 engine on the Core profile without issues, unless they are running an older AMD card of which AMD butchered the drivers.

I'm pretty much aligned with Graf's opinion on this matter. I'll try not to break it and if I can support it with a reasonably low amount of effort I will.

But I also at the same time have very little tolerance for people with that old hardware because OpenGL 3.0 is from 2008 - that's 8 years ago. If people want to use old hardware that's their choice, but I can get quite angry when they take it for granted, or worse even expect, that I will spend time and resources on something that's essentially not my problem. I wonder how many of those people would be willing to spend DAYS extra development time on a feature if the situation was reversed. Not many I'm willing to bet.