cabalistic

Have you enabled multi-core enhancements in the options? That's the one option that would give you the most immediate jump in performance compared to older versions. But that is a 2.06 feature, so if you've had it enabled from the start, there were no other major improvements from 2.06 to 2.08. But yes, the GPU does matter, particularly if you enable features like soft shadows.

2.08 contains a lot of the technical prep work that makes the improvements in 2.09 possible in the first place Also, the improvements in 2.09 require scenes that are CPU bound. If they aren't you won't see much of an impact.

No, this shader is only needed by an experimental feature, and even if it were enabled (which it is not if the Darkmod.cfg file was deleted), it would only affect actual ingame rendering, not the menu.

It's going slow, but steady. Since Valve finally published on OpenXR runtime, I decided that I would go the OpenXR route for the new VR version, which I think makes the most sense. Unfortunately OpenXR is, like every Khronos API before it, an absolute pain to use, particularly compared to the simplicity that is OpenVR. So it's taking longer to learn and implement

According to the gpuinfo database, the HD4800 should support OpenGL 3.3, so it should be able to run TDM 2.08 and the upcoming 2.09, at least. Chances are this is either a driver bug, or we're doing something wrong on the coding side. It would be great to find out the cause, and then perhaps we can fix or work around it. Unfortunately, I don't have any immediate ideas right now, will have to think about it.

No, there is no matching format, and even if there was, it would look horrible. Although I wonder if what you actually mean is what r_fboColorBits 32 gives you, anyway. The bits are a total number, not per channel - so r_fboColorBits is 32 bits for RGBA, meaning 8 bits per channel. Perhaps that's what you wanted, anyway?

Let's try not to mix different things together, it only muddies the argument. Far as I understand the story from Wikipedia, one guy in an article critized the game he'd never played, and the developer called him on his bullshit. Nothing was censored, games to this day still have black and female zombies, and I'm not aware that anyone then or now has been trying to raise that particular argument again? Sounds to me like a non-issue - you'll always have some people speaking nonsense, that's just par for the course. I'm inclined to agree with you on the TV series. I don't know that particular show, but even if you have legitimate issues with its contents, I'd argue that pretending it doesn't exist is a poor choice and a missed opportunity. For the magic cards I lack a bit of context, not knowing the history of those cards and not being a Magic player myself. The one card that the article shows I can immediately understand why it's a controversial card, although in the right context I'd also accept it as a brilliant satire. Though from what little is in the article it doesn't sound like it's satire, so... As for renaming technical terms: the move from Github at this particular moment in time is virtue-signalling and activism, for sure. To be fair, though, this debate has been ongoing for several years and precedes the recent protests. Some projects already switched terms a while ago after long debates. And given that it's been public and controversial debates, I don't find fault in that. Eventually, any decision taken will displease someone But even if you find the renaming unnecessary or downright moronic, I don't see that anything is being censored or oppressed here.

Riiiight ... I think you forgot to mention George Soros somewhere in there...

I'm sorry, what are you talking about? What zombie game was released in the past few weeks that sparked outrage about its zombies? TLoU has sparked plenty of outrage on different things, or did I miss something here?

Annoying bug. There's a subtle dependency of the order in which certain objects get deleted because they can reference each other, but it's so implicit that you basically can't see it in the code. I hope I fixed it, but I can't be 100% certain. Would appreciate it if you could test this executable, and let me know if you do find more crashes: https://ci.appveyor.com/api/buildjobs/q614b4ojrmat3umc/artifacts/TheDarkMod.7z

Thanks, I can reproduce it. Some kind of memory corruption.

Note: this is obviously a notorious scene, and you need a decently powerful GPU to see improvements from CPU time reduction

Then I'd suspect you're testing the wrong scene, or your other settings are too light. Setting FBO resolution to 2 (which means 4x the pixels!) takes twice as much GPU time for my RTX 2080 Ti at the Briarwood Manor opening, for example. It's already impressive that it doesn't take 4x as much time, but it *is* by far the most expensive graphical option there is.

Some people will try to set every graphical setting to its maximum if they have a decent system, but for something so ridiculously expensive like supersampling, that might be deceptive. I'd argue that it's an advanced setting for people who know what they're doing.

Hey everyone, the last couple of weeks I've been working on an overhaul to TDM's renderer that slightly improves CPU utilization in the game and should thus improve performance in CPU-bottlenecked scenes. This is the next step in our ongoing backend modernization and targeted for 2.09. However, since the changes are quite involved, I'd love to get a headstart on testing, so that we can catch any major problems or regressions early The 2.08 beta test has absolute priority. But if you happen to be curious and have a bit of extra time to spare, I'd appreciate any feedback you can provide. Current test build: https://ci.appveyor.com/api/buildjobs/q614b4ojrmat3umc/artifacts/TheDarkMod.7z You'll need a 2.08 beta installation. Make a copy of your TheDarkModx64.exe and glprogs folder (if present) so that you can go back to 2.08, then extract the files from the archive to your installation. Instructions for testing: There are two parts to this. First is a new render backend which significantly reduces CPU draw call overhead by better ordering of draw calls and using modern OpenGL features (if available). You can enable it with cvar r_useNewBackend. Most important thing to test here is that there are no visual artifacts or regressions from the new renderer. So ideally go through some scenes and switch between old and new backend and let me know if you notice any differences For good measure, you can also try to toggle the cvars r_useMultiDrawIndirect and r_useBindlessTextures, which toggle two particular modern OpenGL features that the new backend can use. Ideally, toggling these should not result in any visual changes, either. The second part is further parallelization of a particularly compute-heavy step in the renderer. @duzenko spent some time to port BFG threading code to TDM, and this initial work is already in 2.08. However, it wasn't quite stable, so enabling it in 2.08 causes crashes eventually. I spent some more time stabilizing this portion, and combined with the new backend, it should yield some FPS increases in CPU-heavy scenes. To enable this feature, enable the cvar r_useParallelAddModels (caution: disable this when going back to 2.08, or you'll have crashes!). Here, I'm mostly looking for confirmation that it runs without crashes. You can also tweak the level of parallelization with the cvar jobs_numThreads. It defaults to 2, if you have 6 or more cores, I'd advise to increase it to 4. Further increments don't seem to yield much improvement. Thanks for your time! Oh, and just to give an idea of why I did this: This is performance with 2.08: And this is with r_useNewBackend and r_useParallelAddModels enabled:

I walked your test map through a graphical debugger - this has absolutely nothing to do with the vertex colors, themselves. I can comment out their contributions to the shading, and it still looks wrong. The problem stems from the vertex normals/tangents/bitangents not giving a smooth interpolation over the model with vertex colors, resulting in the underlying tris being visible in the specular term calculation. So, to me it looks like the model with vertex colors has gotten its vertex normals/tangents/bitangents messed up. Whether that happened during export or during load by the game, I'm not sure.

Perhaps you accidentally ended up with r_tonemap 0? In which case postprocess gamma would be disabled and not take any effect.

Before anyone spends any significant amount of time on getting TDM to run natively on macOS again, remember that Apple has deprecated OpenGL on its platform, and the version that is supported has not been updated in a while. Since creating and maintaining a full Metal port just for the macOS platform is not feasible for this project, I'm afraid a TDM native executable may soon be impossible to do at all.

I think "conspicuity" or "conspicuity level" would be the most fitting term (as far as I can judge that as a non-native speaker )

Don't really have an opinion on this - prior to this thread I hadn't even heard of Elbrus I don't see anything problematic in the patch. If it helps, by all means.

I think we'll have to consider shadow maps an ongoing experimental feature. One significant hurdle (in my opinion) is that not all light types are implemented in shadow maps, which means that the engine will fall back to stencil for some lights and thus still generates stencil shadow volumes even when you select shadow maps. So in a way, you currently get the worst of both worlds with shadow maps

Nvidia's SAO isn't really specific to Nvidia cards. All the techniques it uses are in some way also present in the FidelityFX implementation or Intel's ASSAO, those just add a couple additional advanced optimizations Reasons for SAO: it was well documented, had an OpenGL sample implementation, good license, was reasonably simple to implement in a reasonable amount of code (definitely much less than the afore-mentioned ones!) and offers reasonable quality at reasonable performance - not fully state of the art, but also significantly better than some basic implementations that you often find in tutorials (and which I started with in my first attempt)

I've seen it, but there's only an implementation for DX12, and given the sheer size of the shader file, that would be a monumental task to port Also, it's using compute shaders, which we don't (yet) support in the engine. That's also what stopped me from using Intel's ASSAO, which seems conceptually similar, and going for the older, but simpler SAO.

AO exclusively affects ambient lighting - if ambient is weak or overlaps with direct light, you won't see much of an effect. Also, a few missions have some AO already baked into the textures, reducing the difference. If you really want to see SSAO in action, I can recommend William Steele 5

Not exactly a regression, no. Gamma/brightness were completely reimplemented and are no longer changing the desktop/OS gamma, but instead handling it ingame as an image post-processing step. Unfortunately, the consequence is that it no longer affects the menu. In all likelihood we'll remove the popups for this release, as it'll take some effort to make them work with the new implementation.