GZDoomBuilder-Bugfix, a maintenance fork of GZDB

[leodoom85]

My laptop has specs from 8 years ago. I use Windows 7 and have an old dedicated card that supports OpenGL 3.3.
Most importantly, there's no warning at all, it works as normal except that...how can I put it...it looks like a HOM in Doom. Whatever menu pops up in the screen, it stays there and gets frozen in screen...

[ZZYZX]

And that's why I never really wanted to write an own game engine: "it doesn't work" for someone else which is untestable/unfixable...
Not really sure what may cause that. dp, any ideas, maybe? Or any ideas on debugging this? Maybe adding some OpenGL extension listing to the log to see if something is not supported..?

Actually, here is a debug build (x64): https://www.mediafire.com/file/98ugl87k ... d.zip/file
Can you (leo) please try to run it and tell if there is anything meaningful in OpenGLDebug.log? (should be generated in the editor's directory)

[dpJudas]

Adding the OpenGL render info that GZDoom also displays would be the first step. That way we'd at least know which GPU and driver version we are dealing with.

Since it is a HOM there's two likely candidates:

1) OpenGL context isn't positioned correctly, SwapBuffers not working, viewport or scissor rects not updating correctly, OpenGL context failed and error handling was missing. This could be tested with a glClear with a red color.
2) The vertex shader is acting up - this is a lot more tricky to track down.

[leodoom85]

Gimme 10 hours and I'll do it. I have a job to deal with daily

[Clay]

Tried it out. Did some things like copy pasting playing around in visual mode and such. There is a slight kind of choppiness. Similar to a frame rate drop but it was minimal at most times only rarely getting to an annoying level.

I did notice a difference in the way lines are displayed(see Image). Left is new build, right is R3064. The seem to be outlined in white. Which isnt really a problem unless lines are rather dense and clustered. Wasn't sure if this was indicative of anything so I decided it was worth the mention.

Win7, AMD CPU, Nvidia GTX-970 GPU.

[Enjay]

I'm not in a position to check anything right now, but talk of visual mode slowing down by 10% (if that's still the current estimate) does worry me. Visual mode can already be quite slow/choppy if a mod has a lot of resources or has a complicated map. For some mods, I already toggle things display to off for general editing in 3D mode unless I really need to see the things. Displaying things in 3D mode can really cause some significant slow down. So, an estimate of 10% slower for something that is already slow-ish is really quite concerning IMO.

[ZZYZX]

Note that for some people performance actually improved. This is not 100% stable. Though, yes, it is a problem.

Gray outline in 2D is probably due to different rendering mode, will fix.

[Clay]

Any performance impact I felt was indeed minimal. I have no idea about the difficulty of doing what guys are and just point out what I notice.

Thanks a bunch for everything!!!

[ZZYZX]

Debug build just crashed with null dereference for Leo, so probably OGL version not supported or not able to initialize altogether.
Will later add OGL initialization error handling to see where exactly it fails.. for now, just asked for GZDoom's log to see the GL version.

[dpJudas]

I think it is worth mentioning that this patch isn't just a port to OpenGL. It also moves the codebase from a Direct3D 9 age (mixture of fixed function and shaders) to the modern GPU age: OpenGL 3.2 is roughly equivalent to Direct3D 11. Perhaps even more importantly, it establishes an abstraction between the actual graphics API in use and the high level code in GZDB. You could add vulkan support without touching a single line on the C# side of things. That is very different from the old version.

I'm fairly sure the performance of the 3D mode could be improved to surpass the D3D9 version if a little time was spent on it. The code I saw there wasn't exactly doing it in an efficient way.

About leo's crash - does modern GZDoom work for him? It should be having the same minimum OpenGL version.

[ZZYZX]

GZDoom does. Asked for hardware relevant logs:

---

Code: Select all

GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: ATI Mobility Radeon HD 4500/5100 Series
GL_VERSION: 3.3.11672 Core Profile Context (Core profile)
GL_SHADING_LANGUAGE_VERSION: 3.30
GL_EXTENSIONS: GL_AMDX_debug_output GL_AMDX_vertex_shader_tessellator GL_AMD_conservative_depth GL_AMD_debug_output GL_AMD_depth_clamp_separate GL_AMD_draw_buffers_blend GL_AMD_name_gen_delete GL_AMD_performance_monitor GL_AMD_pinned_memory GL_AMD_sample_positions GL_AMD_seamless_cubemap_per_texture GL_AMD_shader_stencil_export GL_AMD_texture_cube_map_array GL_AMD_texture_texture4 GL_AMD_vertex_shader_tessellator GL_ARB_ES2_compatibility GL_ARB_base_instance GL_ARB_blend_func_extended GL_ARB_color_buffer_float GL_ARB_compatibility GL_ARB_compressed_texture_pixel_storage GL_ARB_conservative_depth GL_ARB_copy_buffer GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_buffers_blend GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced GL_ARB_explicit_attrib_location GL_ARB_fragment_coord_conventions GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_geometry_shader4 GL_ARB_get_program_binary GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_map_buffer_alignment GL_ARB_map_buffer_range GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_occlusion_query2 GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_seamless_cube_map GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_objects GL_ARB_shader_precision GL_ARB_shader_stencil_export GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shading_language_420pack GL_ARB_shading_language_packing GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_sync GL_ARB_texture_border_clamp GL_ARB_texture_buffer_object GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_compression GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map GL_ARB_texture_cube_map_array GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_gather GL_ARB_texture_mirrored_repeat GL_ARB_texture_multisample GL_ARB_texture_non_power_of_two GL_ARB_texture_query_lod GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_rgb10_a2ui GL_ARB_texture_snorm GL_ARB_texture_storage GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_transform_feedback_instanced GL_ARB_transpose_matrix GL_ARB_uniform_buffer_object GL_ARB_vertex_array_bgra GL_ARB_vertex_array_object GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_envmap_bumpmap GL_ATI_fragment_shader GL_ATI_meminfo GL_ATI_separate_stencil GL_ATI_texture_compression_3dc GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_ATI_texture_mirror_once GL_EXT_abgr GL_EXT_bgra GL_EXT_bindable_uniform GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_copy_buffer GL_EXT_copy_texture GL_EXT_direct_state_access GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_histogram GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texgen_reflection GL_EXT_texture3D GL_EXT_texture_array GL_EXT_texture_buffer_object GL_EXT_texture_compression_latc GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_texture_shared_exponent GL_EXT_texture_snorm GL_EXT_texture_storage GL_EXT_texture_swizzle GL_EXT_timer_query GL_EXT_transform_feedback GL_EXT_vertex_array GL_EXT_vertex_array_bgra GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_conditional_render GL_NV_copy_depth_to_color GL_NV_copy_image GL_NV_explicit_multisample GL_NV_float_buffer GL_NV_half_float GL_NV_primitive_restart GL_NV_texgen_reflection GL_NV_texture_barrier GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SUN_multi_draw_arrays GL_WIN_swap_hint WGL_EXT_swap_control

AMD, obviously.

About being very different, sure. I remember one major blocker for me to remove SlimDX was hard dependency on vectors, matrices and some other classes from SlimDX, thank god you removed these...
Wasn't very fixed-pipeline before either though from what I remember. Everything happened through uniforms and D3D "effect" shader compiler (which also used to not work on WINE, I guess it's not very popular...)

Separately: tried to request OpenGL 5.0, got C# exception, not crash or HOM. So it's something more tricky than that.
Going to compare initialization code to GZDoom later. And also maybe we are not setting the context correctly to the window... (and some drivers ignore that whereas some others die instantly)
And/or that may be related to WINE crashing with X11-something-cursor during SwapBuffers (which for me means that SwapBuffers was called against a bad DC, with null rectangle)

[dpJudas]

I agree it was mostly non fixed-pipeline, but Direct3D 9 in itself was in this weird hybrid age where you could do a bit of both. In GZDB that surfaced in how you declared the vertices, some of the fixed function transform matrices and the way it did fog. In any case, you want the high level rendering work to be separated from the low level part. That is much more true in the codebase now.

[ZZYZX]

So I tested my wild guess from above and added wglMakeCurrent right in front of ::SwapBuffers and it started working for Leo


x86: http://www.mediafire.com/file/zlecwnz2m ... 09.7z/file
x64: http://www.mediafire.com/file/vv7d5qany ... 64.7z/file

Supposedly this should also work on WINE.
If it does, that would also explain why Windows version crashed, but Mono doesn't (because Mono uses a different native library with GLX in place of WGL).

edit: I tested it on my Ubuntu with fresh prefix, worked flawlessly.
I guess that saves me a native build

[dpJudas]

Looking at your branch, did you add those unconditional 'ApplyViewport' lines to all the Draw calls?

The RenderDevice.Draw calls are very performance sensitive. Any additional call you make there you risk that the driver re-evaluates the GPU pipeline serving the whole thing below the surface. That's what that whole need apply thing is about - to only disturb the GPU waters when a state actually changed.

Also figured out why the 3D mode is not very fast: it creates a vertex buffer for every sector. While that saves it from generating them again (which is good, what GZDoom should be doing), it also means it does a hell of a lot of vertex buffer binds (very bad). I think we need to create some abstraction somewhere that ensures a lot of sectors share GPU vertex buffers so only a few buffer binds are needed.

[ZZYZX]

Yes, I did, during some debugging. Thought viewport was leaking. Will remove later.
Why did vertices not lag before in D3D though?

Also, I think we could store all vertices in a single buffer and just reference different positions within that. The buffer will only need to be regenerated when we edit a sector, since its a map editor. Do you think this is a good idea? Or it won't help with performance due to many drawcalls needed anyway?

What's slow here, drawcalls or binding of the buffer?