cabalistic

No, wait, this is happening within a loop. So small timeout is fine: while ( result != GL_ALREADY_SIGNALED && result != GL_CONDITION_SATISFIED ) { result = qglClientWaitSync( bufferLock[frame], GL_SYNC_FLUSH_COMMANDS_BIT, 1000000 ); if ( result == GL_CONDITION_SATISFIED ) { backEnd.pc.waitedFor = 'S'; } if ( result == GL_WAIT_FAILED ) { common->Warning( "glClientWaitSync failed.\n" ); break; } }

Hm, I don't remember the context right now, but I think the timeout should probably be longer, more like 1 second. Perhaps I made a mistake with the number, or someone accidentally changed it. Nothing happens on wait timeout. The docs say it is safe to call glDeleteSync either way. Try calling glFlush or even glFinish (just as an experiment, definitely don't commit that ) right before the wait. It may also be the case that the timeout is simply too short, as mentioned above. If it still times out even with glFinish, it is absolutely a driver bug.

I'm actually using gamma 1.4 and brightness 1.2 right now. The default values might still need some adjustments Yeah, some noise in the AO is expected, particularly in the distance or where the depth buffer is already crowded. As long as it does not disturb the actual rendered scene...

Strange that it errors out, but if you have VS 2017 installed, you shouldn't need to install the redistributables, anyway. Have you tried starting the game?

Just for reference, this is what SSAO should look like: So yeah, it does darken the (impression of the) scene, but it should not make a drastic difference. If you see different behaviour between SSAO turned on and off, please let me know so that we can debug the issue

SSAO shouldn't noticeably darken the whole scene - are you sure it's not the new gamma/brightness system that makes TDM look darker than before? You can look at the actual SSAO output via "r_showFBO 4" - this should be a white image with the darkened AO shades. If that image is somehow gray, then the effect may be misbehaving on your GPU.

Sorry, there's a thread over in General with instructions:

Try the 2.08 beta. It's not perfect, but I did add some improvements that should allow at least the most standard keys to be mapped properly.

TDM's engine has sufficiently evolved from its Doom3 origins that any such port cannot (easily) be copied over to TDM. In this particular instance, the Doom3 Vulkan renderer is based on the BFG version, while TDM is not, so the difference is even greater. That being said, Vulkan is currently not something that would benefit TDM too much and might even hurt it. As duzenko mentioned, support for older hardware is still important, which means we have to maintain the OpenGL renderer. Having to maintain an additional renderer (Vulkan) on top of that would only increase the bug count and maintenance cost. At the same time, many of the immediate issues that TDM faces in terms of performance can (and will) be addressed with OpenGL and do not require Vulkan support, at all.

Hm, that sounds more like a delayed loading algorithm, where it's loading lower quality levels first to get the player into the game faster, then progressively loads higher quality assets and uses them when they become available (?). Dynamic resolution scaling would usually start you off at its highest level and progressively drop you lower as necessary.

What would make much more sense is a dynamic resolution scaling, i.e. dynamically downscale the render resolution if performance is too low. This is a fairly common technique deployed in actual games. I even did a prototype of it for TDM at some point, but there are some annoying non-trivial issues with the approach. Still, it could be done in principle...

I'm not sure that would make much sense. These days, texture resolution is usually not the primary limiting factor. So lowering it depending on the framerate may yield little to no performance benefit at all.

Honestly, this is not worth it, imho. That spec doesnt even support fence syncs, so it would run like crap, anyway. Please lets not spend valuable time on this right before beta

Yes, Vulkan would need porting shaders, too. Actually, the porting itself has been completed in the meantime, but Vulkan would need more - Vulkan requires compiled shaders in the SPIR-V format, so the entire pipeline for shaders would have to change somewhat. The problem is, with Vulkan you'd basically have to completely reimplement the entire rendering pipeline and properly decouple some additional parts of the engine, all of which is a massive undertaking (though very educational, I'm sure). Modern OpenGL techniques, on the other hand, can be integrated piece by piece and coexist with the existing pipeline, so much more manageable. It's also doubtful that Vulkan would deliver significant improvements over modern OpenGL, because the engine has more glaring bottlenecks. So, given the effort required and the expected negligible gains just make a Vulkan port rather impractical. Not saying that it wouldn't be fun to do, just not practical

This should now be fixed.

It does not, currently. I'm working on it, and there's an older alpha of VR support. Hopefully, after the upcoming 2.08 release, I'll be able to update the alpha version again

Phew, key mapping on Linux looks quite broken in the code. Doom3 is using a very limited mapping table on possibly the wrong input. I added a new mapper for standard special keys that should at least improve the situation, starting from 2.08. In the long term, we may need to look into a rewrite, possibly using a sensible input library.

You're right, the shadow geometry can be cached. Rendering it to the stencil buffer, however, cannot, because it's done from the camera's point of view (unlike shadow maps), and that typically changes between frames. But of course, the geometry is the more significant cost

At least for classical stencil shadows, yes. You can't really implement a forward+ renderer with stencil shadows. Technically, TDM uses a trick for soft stencil shadows that would allow it, but it is detrimental to performance. And even then, stencil shadows would have the disadvantage that they need to be rerendered on every frame, whereas shadow maps can potentially be cached as long as the light itself or the shadow casters in its vicinity don't move. As for putting shadow volume generation to the GPU: that's possible, in principle. However, my experience with geometry shaders has been poor, they usually tank GPU performance quite significantly if you use them for anything other than a few simple objects. I'm not sure it's a good trade-off, and personally at least I think the kind of effort needed to implement it is better spent on improving shadow mapping. But that's just my personal opinion

The performance comparison is not that simple. Yes, the GPU side is fairly cheap, but even there it has drawbacks. In particular, it requires to render each (shadow-casting) light separately, which is not ideal in modern rendering architectures and does not scale particularly well with many lights. And while the rendering itself is cheap, creating the necessary shadow geometry is not. That's traditionally done on the CPU, and it's one of several reasons why TDM is currently heavily CPU-bottlenecked. There are a couple of reasons why it's currently not the case, but I'm willing to wager that shadow maps will eventually outperform stencil in TDM

This is a question for @duzenko, but I think the fullscreen resolution handling was changed such that the render window is always at full desktop resolution, but the internal render resolution is set according to your choice. So even if the app runs at 4k, rendering should not. Can you see a quality / performance difference ingame between different resolution settings?

That's the dynamic index/vertex buffer running out of memory. This is fine, though, they are automatically resized. Basically, to not waste GPU memory, they start at fairly modest sizes. But the more demanding your map is, the more memory you need. If the current value is not sufficient, the buffers are resized automatically. The messages are informative only.

Perhaps it's not texture-related, but rather the vertex/index buffers. That might suggest memory corruption or possibly missing/incorrect GPU fences.

You people keep missing each other's points, I think. Context matters Alberto, while I agree with your practices in principle, even "universal" concepts don't apply universally to every problem. I would recommend trying to find a recording of John Romero talking about id Software's history and how they approached game design. He specifically mentions why missing assets are not treated as hard errors, and - surprise - it was specifically to enable fast iteration and getting products shipped Like I said, context matters. Missions and assets are not quite the same thing as writing code.

This would basically require to develop a "new" renderer in WebGL, and possibly some other significant platform porting. I'm not stopping anyone from doing it, but this is going to be a significant amount of work. If I'm writing a new renderer, I'd rather learn Vulkan in the process than another variant of GL