cabalistic

Please try the 2.10 beta. It has a different window and renderer creation path and might give better results.

No clue, but to be honest, since neither of us can reproduce the issue, we'll just have to have both hypotheses tested. I imagine having a shader fix tested is slightly easier, so I would start with that, but if it's not that, then do try yours

It's possible, but it sounds unlikely to me. I would expect any sensible driver to not actually sample the existing framebuffer if its blendweight is zero. Could be wrong, of course, wouldn't be the first time My personal hypothesis is that we may have negative values in the input color framebuffer. This has actually happened in another place where I already put a workaround for the resulting issues in place, so this isn't too far-fetched, even though I don't fully understand the cause. Now, if there is a negative value in the input to bloom, it would probably get smeared across the bloom stages and then added to the final image, which, if the negative value is high enough, would explain why it ends up as black. This is potentially simpler to test and workaround; all we'd need is a check in the bloom_downsample.frag.glsl brightpass function that returns 0 if the brightness is negative.

Wrong shader, look at stages/frob/frob_apply.frag.glsl. Though honestly, returning to fresnel feels like we are moving in circles... If that had worked well and not be ugly as fuck, we wouldn't be where we are right now

Well, obviously. The outline was always meant as an alternative, not an addition, to the existing highlight.

Because the outline *is* the highlight in that case? I don't know what you are saying here.

An outline for frob highlight works independently of the object and its material. Without a frob outline, we are back to the status quo where highlighting an object is dependent on its material to work properly. If frob outline is deemed an optional feature, mappers need to design for it to not be present so that their objects highlight properly without the outline. Which kind of defeats the reason why the feature was implemented in the first place. On the other hand, if they wanted to keep some objects "hidden" as a secret, the outline makes that harder. So again, it's kind of difficult to design missions around both options, hence not both should be offered as approved options to players.

Would it, though? Mappers need to know what to design for. I don't mind advanced players playing with cvars to do whatever, but any UI option means we "officially" endorse that particular mode. And then maps should work in any of those modes, which, judging from prior mapper comments, isn't as trivial as it might sound. Especially the choice between "on" and "off" is quite impactful here. Which is why I must again strongly object to any UI choices on the feature. Either implement it or scrap it. No half measures, please.

Sounds like you may have a malfunctioning gamepad/joystick connected? That would explain the cursor movement. Try disconnecting any non-essential input devices.

Thanks, but just so you know, development is temporarily on hold because I'm busy with other projects. Hopefully I'll be able to get back to it some time next year

There's no support for keybinds with modifiers, and it would be rather painful to implement.

No, I can assure you it is quite far away. OpenGL has no support for ray tracing, so you'd first need to write a Vulkan renderer for it. And that is most certainly a very daunting undertaking. I mean, one day we'll migrate to Vulkan, sure, but that's not close in any meaningful sense of the word, I'd say

Yes, because we request and require OpenGL 3.3 and don't run on anything prior. And 3.3 requires 64 bit color buffer support, so there's no separate way to query the support. This is - plain and simply - a driver bug.

The 64bit color buffer visibly reduces banding in fog and other particle effects and is also a requirement for the Bloom effect to work properly. No HDR screen is required to benefit from either of those.

Yes, but the default framebuffer is never directly copied to from the multisampled render FBO. There is always a resolve FBO in-between.

That would surprise my. The resolve framebuffer is always created with the same resolution and format as the multisampled one. If there were an error in the code here, this would be an error that would most certainly also happen on our own machines, because I've seen these kinds of errors when I messed something up

Well, that'd be that, then. Unfortunately, fixing the menu elements to use an index buffer isn't an entirely trivial fix, or I'd have done it sooner, but I guess we'll have to put it on the agenda somewhere

I wonder if it's related to index buffers. Menu elements are (afaik) the last elements that are drawn from a CPU-provided index list instead of a GPU index buffer. Far as I know, the spec doesn't require one, or at least I couldn't find anything to the contrary, but it's possible some drivers expect them, anyway?

No, the updater is outdated and afaik does not download the hotfix (?). Please use the new tdm installer, download it if necessary: https://www.thedarkmod.com/downloads/

Please run the tdm installer again and upgrade to the 2.09a hotfix release. It fixes the particular error you've encountered. Can't guarantee that it won't run into a different error, but we won't know until you try

It's an experimental setting, it's not in the menu and not enabled by default. Shadow maps are still a work in progress.

If you want shadow maps to have comparable performance, you need to set "r_shadowMapSinglePass 1". In its default mode, it's well known to be slower than stencil.

As long as the feature is broken, it will not become an option or officially supported in any way, hence why it is disabled now. The only reason it's even still in the code is the vague hope it might be fixed at some point in the future.

The cost scales with the complexity of the highlighted object. A simple gold coin isn't really a concern, but a guard or other complex geometry may be a different matter. So be sure you test the right thing. Also, the hack means that while the outline is generally hidden by depth, it is not a perfect match. It will often slightly protrude into the depth-occluded region, which is not a critical concern, but it does look a little ugly to my eye.

If it were just personal visual preferences, sure. But if it being on actually impedes mappers due to stuff being visible that shouldn't be, then making it optional does not in any way solve that problem. Therefore I consider the feature broken.