cabalistic

It is, in fact, not just default, but mandatory. The option doesn't exist anymore, FBOs are always active.

Yes, the latest release should work fine with the 2.09 release. But I'll also update the build with the final 2.09 code base soon, just in case

I still don't get where you get that from? Like I said, one of the instances (the jitter screenshot feature) is a bug that broke unintentionally. And yes, we do disagree about its relevance or importance, and as a consequence it may have stayed open longer than you wanted, but nbohr did fix it. The main menu changes originated from a dilemma that the devs were blocked from doing improvements to the menus because some missions could have overwritten some parts of it and thus break in the process. And unless you want us to stop doing any improvements to the mod, these kinds of issues need to be addressed. stgatilov did a full due diligence on this, investigated which missions would potentially be affected, developed a couple of potential proposals to move forward and, to my knowledge, did reach out to a few mappers to figure out what kind of control over the menu they really need to find a compromise that offers decent customizability without being a maintenance nightmare. And finally, the handling of full screen resolutions. Like I said, I was and am not in favour of this particular change, so on that one we agree. I just don't see a pattern here.

My point is, please don't mix a number of unrelated issues together to create a confirmation bias that TDM is somehow moving in a direction to restrict player or mapper choice. That's not the case. But the reality is also that any point of available customization creates an exponential growth of possibilities for things to get broken when changes are made. Unfortunately, our capacity to maintain and support every corner case is limited. When stuff breaks, it is in most cases not intentional and we do our best to fix it. But with limited developer capacity (2.09 had like 3 (?) active developers), some things will invariably take longer or fall of the bandwagon when they are not judged critical. And in cases where a break is intentional, we do usually reach out to mappers or the community as a whole to discuss the issue and collect feedback.

Those are three very different things. The first one is a classic maintainability vs flexibility dilemma. The second one is simply a bug (that admittedly devs don't care too much about, but nbohr1more still appears to have fixed it). And the third one - well, actually I still don't know why we did that. I opposed the change

Render scale means that the game is rendering to a lower resolution internally and then upscaling the image in the end. That upscaling is irrelevant for performance, even on the crappiest GPU. Well, unless you get really fancy about it. Then it might be measurable. But right now, it's just a simple bilinear filter that is as close to free as you can get

My biggest gripe with the way fullscreen resolution works now is that it is not intuitive to users, because it doesn't really have a precedent in other games. Any recent game release I can think of absolutely changes the resolution if you set it ingame, and TDM not doing that is therefore just unexpected behaviour. Resolution scaling is a different concept and imho should not have been mixed together like this.

Wait, no. That ticket is about reflection probes, which are meant to greatly simplify the setup of (parallax-corrected) cubemap reflections in the scene. They are not about lighting and have absolutely nothing to do with lightmaps. They also won't improve performance and would in fact cost a little if enabled, as it's a new render feature.

That's not technically true. You are never using more than one pick at the same time. You do need a tension tool, though, which neither of TDM's picks are and we might thus assume it's just implicitly there. The only thing that's potentially unrealistic is regularly needing both picks for a single lock. Because while that may be needed in the rare case, it's not a common theme for common locks Well, and the whole process of picking a lock in multiple stages is also not exactly how that works, but then again, it's a game, not a lockpicking simulator...

I've only briefly looked into the Xlib bindings when I fixed the most glaring issues with keys that were not working in TDM. My impression is that getting this right is not trivial, at all. I believe switching Linux input completely to GLFW might be a much better option at this point. I truly think that would solve (most of) the input bugs for Linux. Perhaps I'll find some time for 2.10 to try this out.

I fully intend to see it through till it reaches its full roomscale form Even if progress may be slow.

Really? I feel that would be pretty stupid, honestly... The fps cap is there so your GPU doesn't run amok in the menu and other lightweight scenes, or to keep a more stable average FPS. There is absolutely no use case to select every value between 30 and 300, so a slider just isn't the right tool, imho. There are only a few select values that actually make sense.

If you're reporting performance, we really need your hardware specs. In any case, if turning off r_usePersistentMapping improves performance, that is a strong indicator that your driver straight up lies or has poor implementation of that feature. But in this instance, you may also want to set r_useNewBackend 0 to switch back to the pre 2.09 render backend, which relies less on persistent mapping than the new one.

The new GOG Galaxy client is a god-send in that regard, as it can integrate with your other accounts and list your entire library. I've used it repeatedly to verify if I really don't own a particular game or just forgot under which account it is

For fuck's sake, stop. *Every post*, you seem to feel the need to tell us how liberal you are, only to then doubt your great liberal ideals. It's getting extremely boring at this point. As for Iran, well. There are two options. You can either bomb the country to hell, or you can try diplomacy. Given the absolute marvelous and fantastic track record the western world has with bombing and invading countries in the middle east, which has truly made the world a better and safer place in the past, forgive us that some of us Europeans favour a different approach this time. It's also funny how you assume that Iran would have broken the deal eventually, and yet the only side who actually did was the USA.

The latest CMake versions do support precompiled headers. Failing that, we have a custom hacked-together solution for it for TDM's CMake builds. I could also assist you in setting up an automated build pipeline for your repository to spot compile errors faster - just let me know

I'm afraid a small test case isn't trivially possible, particularly since I still don't understand 100% what is going wrong for you, exactly. It isn't even as simple as saying that your card/driver doesn't support the half-float format, because when you first disabled r_tonemap, but left r_fboColorBits at 64, you were still rendering to a 64 bit framebuffer, and that seems to work fine. The difference between the two FBOs in question is that one is using a render buffer and the other is using a texture. So I guess the problem is more related to half-float textures than render buffers, but it's hard to say for certain.

Is an FBO allowed to take a different internal format than the requested one? Because we do validate them, so a failure to create the FBO as requested should at least give a warning in the console... But either way, I agree it doesn't seem worth the effort.

@Araneidae Did some research, and it turns out support for our 64 bit color precision is actually core since OpenGL 3.0. This is probably a driver bug - I'm afraid you'll have to remember to stick to 32 bits color precision as a workaround. There's nothing for me to detect missing support, unfortunately.

Please add a bugtracker item for me. When textures are made bindless, texture parameters can no longer be changed for those textures. Changing AF or other parameters with bindless may require recreating the textures.

Alright, thanks for testing. And thanks to @lowenz to find the relevant clue I'll ensure we add proper detection for 64 bit support so that it isn't enabled on systems that don't support it.

@Araneidae You could try to change the color precision to 32 bits (either in the menu or by setting `r_fboColorBits 32` via the console or in your darkmod.cfg. Perhaps we don't have proper detection for 64 bit color buffer support right now, and that messes things up if your card doesn't actually support is, as lowenz's post suggests? Although I wouldn't really understand how disabling tonemapping could influence this, but who knows...

Don't know where you got that number, but no. Both CPU and GPU can and do operate at much higher temps while under load - as they typically are in games. 50° C would mean that the GPU barely has anything to do at all

You could give this executable a quick try: https://ci.appveyor.com/api/buildjobs/rmmv3blgfthoj7sx/artifacts/build%2Fthedarkmod.tar.bz2 (you can ignore the contained glprogs, just the executable) I've cleared the framebuffer before rendering to it. Should not make an iota of difference as the first step is a copy from the previous fbo, anyway. But at least we can rule it out.

If tonemap is enabled, GUI is rendered to an additional intermediary framebuffer, otherwise directly to the screen. I just don't get how rendering to the framebuffer would produce those distorted looks, and only for you.