DRD Team

Ok, so I did further testing. The commit which I suspected of causing problems in the previous post is fine (that part of code does not even execute). Now I suppose that the problem is somewhere in this commit: https://github.com/coelckers/gzdoom/com ... db25e9440d or https://github.com/coelckers/gzdoom/com ... db25e9440d but that will be more difficult for me to test. (I look at commits from Aug 20 and 21).


Update

The code which initializes the portion of memory where call [0] occurs is in the bottom of the file https://github.com/coelckers/gzdoom/blo ... /gl_load.c (Aug 19, 2016 build initializes this portion of memory while Aug 21, 2016 does not) dpJudas: It seems to me that this portion of the code https://github.com/coelckers/gzdoom/com ... 702511ff53 is never called on my machine (is that possible?)

Graf Zahl : I really hope I can use gzdoom on my machine. It seems to me that a problem cannot be huge since the newest builds run fine on another laptop with OpenGL 2.1

Seeing you use a debugger with no debug info is making me cry. Here's a zip with a compile of master with pdbs: http://esoteric.clanlib.org/~mbn/gzdoomWithPdb.zip

If you got visual studio installed you can double click on the .dmp file in the crash report zip and it will show you the call stack of where it crashed. Alternatively you could try use OllyDbg again - I think it will automatically detect the pdb if its located next to the executable. You could also upload the crash report from this exact version - that will allow me to look at the included minidump on my computer.

About the version check for glEnable(GL_TEXTURE_2D), as Graf said, the thing should not be needed on any system with shaders available. Your driver is reporting GLSL 1.20, which is why it shouldn't be calling that.

dpJudas Thanks for the file with debug info. The exception occurs gl_interface.cpp line 70 call glGetString(GL_EXTENSIONS). The call just before that one, glGetIntegerv(GL_NUM_EXTENSIONS, &max); returns -1 in rax and 0 in max. It seems to me that the OpenGL context is not initialized correctly, but I do not know why. I attach the crash report and a screenshot from x64_dbg Update: The table with addresses of OpenGL functions is not initialized at all. The only function which has the address in the table is glGetIntegerv
Update2: The address of glGetIntegerv is set up by line 2469 of gl_load.c . My system does not have the glGetStringi function so the function ogl_LoadFunctions returns in line 2472. My system does have glGetString function Update3:

Possible (partial?) solution: add " _ptrc_glGetString = (const GLubyte * (CODEGEN_FUNCPTR *)(GLenum, GLuint))IntGetProcAddress("glGetString"); " in line 2470 and (?) call Load_EXT_framebuffer_object and possibly some other functions from gl_load.c

Possibly ProcExtsFromExtList will have to be updated to look similarly as CollectExtensions from gl_interface.cpp and called before ogl_LoadFunctions returns.

The debug branch included an updated gl_load.c because I had to add KHR_debug to the list of extensions. That seems to have overwritten the changes in this earlier commit: https://github.com/coelckers/gzdoom/com ... 6003ada6cc. The description there seems very familiar to what you're describing.

We probably should add some comments in gl_extlist.txt documenting what changes has to be done to this file after running LoadGen.lua. Otherwise this thing will probably resurface sometime i n the future next time another extension is needed.

I just pushed legacy method to collect extensions. Now it won't crash on that Intels but will give the following error: The only way to start is to disable render buffers: The same ancient notebook has ATI Mobility Radeon HD4330. With this graphics card GZDoom crashes on linking the default shader, at gl_shader.cpp:213. The following errors were reported: I don't remember did I see something similar before or not Just out of luck with newer drivers and stuck on buggy ATI's OpenGL 3.1 implementation.

Regarding GLLoadGen: Maybe this should be reported to the maintainers of GlLoadGen as well so that they can fix it.

Regarding ATI: Maybe the problems got hidden by previous versions forcing ATI GL 3 drivers to use only GL 2 features. Damn, I was hoping I could remove the 2.x with shader path after making core profiles work.

Regarding Intel: I think, instead of trying to fix all those issues, if framebuffer creation fails, it should silently revert to gl_renderbuffers 0 mode. I think there is very little point in trying to make this all work with obsolete hardware. It should be clear by now that these things do not handle modern rendering techniques well.

Good idea on the silent revert to gl_renderbuffers 0 mode. I'll prepare a PR adding that.

In theory, it could retry with a different combination of formats to try make the glCheckFramebufferStatus succeed. EXT_framebuffer_object so lovely requires at least one combination to succeed, without specifying what that combination should be. It might not like half-floats, RGBA16, or an alpha channel, or who *beep* knows what. Just mentioning in case someone should be interested enough in coding such a thing.

Graf Zahl wrote:Regarding GLLoadGen: Maybe this should be reported to the maintainers of GlLoadGen as well so that they can fix it.

Sure, I'll do it.

dpJudas wrote:Good idea on the silent revert to gl_renderbuffers 0 mode. I'll prepare a PR adding that.

In theory, it could retry with a different combination of formats to try make the glCheckFramebufferStatus succeed. EXT_framebuffer_object so lovely requires at least one combination to succeed, without specifying what that combination should be. It might not like half-floats, RGBA16, or an alpha channel, or who *beep* knows what. Just mentioning in case someone should be interested enough in coding such a thing.

Seriously, who cares? I actually wonder if disabling postprocessing on this old hardware might be a better option as here it actually might cause slowdowns due to poor shader performance.

Hehe, yes, you're right of course. On a somewhat related note, what do you think we should do with the old gl_vid_multisample? Keep it for the old cards, or remove it and only support multisampling for newer cards?

Remove it I'd say. On these old cards it will most likely just be a drag on performance anyway.

Ok, the newest build 2099 gives me:

Execution could not continue.

glCheckFramebufferStatus failed: GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT

This seems to be the same problem as this one: http://tracker.dengine.net/issues/1977
Developers of doomsday eventually work that out and now doomsday runs fine on my machine (avg 20 fps with hi-res textures and 3d models).

Part of doomsday log which may be helpful :

Changing display mode to 800 x 600 x 32 (75.0 Hz)
Display mode has changed
[GLFramebuffer] Texture-based framebuffer failed: [ConfigError] (in GLTarget::validate) Incomplete
attachments
Trying again without depth/stencil texture
Color texture with unified depth/stencil renderbuffer failed: [ConfigError] (in
GLTarget::validate) Incomplete attachments
Trying again without stencil
Renderer features unavailable: sky mask, lensflare depth
OpenGL 2.1 supported
[Sys_GLInitialize] OpenGL information:
Version: 2.1.0 - Build 8.15.10.2869
Renderer: Mobile Intel(R) 4 Series Express Chipset Family
Vendor: Intel
Capabilities:
Compressed texture formats: 6
Use texture compression: no
Available texture units: 8
Maximum texture anisotropy: 2
Maximum texture size: 4096
Line width granularity: 0.5
Line width range: 0...7.5
OpenGL Extensions:
3DFX extensions:
texture_compression_FXT1
ARB extensions:
color_buffer_float, depth_buffer_float, depth_texture, draw_buffers, draw_instanced,
fragment_program, fragment_shader, framebuffer_sRGB, half_float_pixel, half_float_vertex,
multitexture, occlusion_query, pixel_buffer_object, point_parameters, point_sprite, shader_objects,
shading_language_100, shadow, texture_border_clamp, texture_compression, texture_compression_rgtc,
texture_cube_map, texture_env_add, texture_env_combine, texture_env_crossbar, texture_env_dot3,
texture_float, texture_non_power_of_two, texture_rectangle, texture_rg, transpose_matrix,
vertex_array_object, vertex_buffer_object, vertex_program, vertex_shader, window_pos
ATI extensions:
separate_stencil
EXT extensions:
abgr, bgra, blend_color, blend_equation_separate, blend_func_separate, blend_minmax,
blend_subtract, clip_volume_hint, compiled_vertex_array, draw_buffers2, draw_range_elements,
fog_coord, framebuffer_blit, framebuffer_object, multi_draw_arrays, packed_depth_stencil,
packed_float, packed_pixels, rescale_normal, secondary_color, separate_specular_color, shadow_funcs,
stencil_two_side, stencil_wrap, texture3D, texture_compression_s3tc, texture_edge_clamp,
texture_env_add, texture_env_combine, texture_filter_anisotropic, texture_lod_bias,
texture_rectangle, texture_sRGB, texture_shared_exponent, texture_swizzle, transform_feedback
IBM extensions:
texture_mirrored_repeat
NV extensions:
blend_square, conditional_render, texgen_reflection
SGIS extensions:
generate_mipmap, texture_edge_clamp, texture_lod
WIN extensions:
swap_hint
Extensions (WGL):
WGL extensions:
ARB_buffer_region, ARB_extensions_string, ARB_framebuffer_sRGB, ARB_make_current_read,
ARB_pbuffer, ARB_pixel_format, ARB_pixel_format_float, EXT_depth_float, EXT_extensions_string,
EXT_swap_control
[audio::System > AudioDriver] FMOD Sound System (c) Firelight Technologies Pty, Ltd., 1994-2013
[audio::System] Audio configuration:
CD: FMOD/CD
Music: FMOD/Ext
SFX: FMOD
Using SteamApps path: c:\program files (x86)\steam\SteamApps\common
[GLFramebuffer] Texture-based framebuffer failed: [ConfigError] (in GLTarget::validate) Incomplete
attachments
Trying again without depth/stencil texture
Color texture with unified depth/stencil renderbuffer failed: [ConfigError] (in
GLTarget::validate) Incomplete attachments
Trying again without stencil
Renderer features unavailable: sky mask, lensflare depth
Texture-based framebuffer failed: [ConfigError] (in GLTarget::validate) Incomplete
attachments
Trying again without depth/stencil texture
Color texture with unified depth/stencil renderbuffer failed: [ConfigError] (in
GLTarget::validate) Incomplete attachments
Trying again without stencil
Renderer features unavailable: sky mask, lensflare depth
Texture-based framebuffer failed: [ConfigError] (in GLTarget::validate) Incomplete
attachments
Trying again without depth/stencil texture
Color texture with unified depth/stencil renderbuffer failed: [ConfigError] (in
GLTarget::validate) Incomplete attachments
Trying again without stencil
Renderer features unavailable: sky mask, lensflare depth
Texture-based framebuffer failed: [ConfigError] (in GLTarget::validate) Incomplete
attachments
Trying again without depth/stencil texture
Color texture with unified depth/stencil renderbuffer failed: [ConfigError] (in
GLTarget::validate) Incomplete attachments
Trying again without stencil
Renderer features unavailable: sky mask, lensflare depth

Edit: Can somebody share the pdb file of the newest build with me?

All this means that framebuffer support is mostly useless on your system as it'd make essential features unavailable. The only solution would be to revert to direct screen rendering here and disable the postprocessing stuff entirely.

Doomsday solution: http://tracker.dengine.net/projects/den ... buffer.cpp

It seems that my card falls in the category of "Case 2" line 186. (the whole revision: http://tracker.dengine.net/projects/den ... 2fdf3f5b50)

Postprocessing seems to be possible.

Pull request adding the fallback and removes gl_vid_multisample: https://github.com/coelckers/gzdoom/pull/91

About what Doomsday does, the problem isn't just whether postprocessing is theoretically possible, but also if it would be flexible and fast enough for what we need it for. There's a certain amount of diminishing returns in development versus what cards and features that would add. Doubling the development time for a card that probably wouldn't even hit 60 fps with the features on doesn't seem like a good investment.