search

DaemonEngine / Daemon

The Dæmon game engine. With some bits of ioq3 and XreaL.
https://unvanquished.net
BSD 3-Clause "New" or "Revised" License
298 stars 61 forks source link

Dynamic light fallback doesn't work #452

Open slipher opened 3 years ago

slipher commented 3 years ago

For GL drivers lacking a certain extension, there is a fallback implementation of dynamic lights, which can be tested by replacing the line in sdl_glimp.cpp

glConfig2.uniformBufferObjectAvailable = LOAD_EXTENSION_WITH_TEST( ExtFlag_CORE, ARB_uniform_buffer_object, r_arb_uniform_buffer_object->value );

with glConfig2.uniformBufferObjectAvailable = false.

However, this implementation produces no visible effect for me. It seems to be the same as setting /r_dynamicLight 0.

illwieckz commented 3 years ago

On Linux with Mesa drivers, it's expected to be possible to test the missing extension without modifying code, by using this environement variable:

export MESA_EXTENSION_OVERRIDE='-GL_ARB_uniform_buffer_object'
slipher commented 3 years ago

My suggestion to disable it by deleting a line was bad as it misses the part which sets shader defines. A right way to test with the extension disabled is /r_arb_uniform_buffer_object 0.

I found that in the 0.51 release, the fallback code path works correctly, but only if you have r_dynamicLight 1 (the deprecated option). As of the latest 0.52/sync (including #453), the fallback code is broken even if you try to use the deprecated rendering path with /r_dynamicLight -1, so there's a regression there.

illwieckz commented 6 months ago

My commit turning deprecated renderer as -1 value was broken and then there was no way to re-enable the deprecated renderer.

This PR re-enables the deprecated renderer:

Once the deprecated renderer is working again and enabled, setting r_arb_uniform_buffer_object to 0 makes a difference, the screen turn into black when there is a light in scene, meaning it uses an alternate code path but this code path is buggy.

If the fallback is only usable on the deprecated renderer, this is a good reason to keep the deprecated renderer as a fallback itself.

illwieckz commented 3 months ago

If the fallback is only usable on the deprecated renderer, this is a good reason to keep the deprecated renderer as a fallback itself.

That fallback is meant to be a fallback for the tiled lighting renderer, so having the option messing with the legacy lighting renderer is very suspicious. That fallback is part of the tiled lighting renderer.

The GLSL define used to select fallback code path when ARB_uniform_buffer_object is missing or disabled was inconsistent, but cleaning things up in #1182 doesnt help: