cabalistic

Do you have an autoexec.cfg? Anything set in there would take precedence over darkmod.cfg.

That means that the request never even reaches my server. I can ask my ISP about it as that's their infrastructure, but I'd still need a source IP to help them identify the incoming request.

There's an override variable specifically for this purpose: THIRDPARTY_PLATFORM_OVERRIDE. You can set it when running CMake, and it will override the defaults which are meant to fit the prepackaged binaries.

Unfortunately, the server isn't even close to being busy, so there has to be another cause. But I'd need a concrete timestamp (including timezone) and the client IP for a failing request to investigate further. Perhaps a traceroute to tdm.frydrych.org at the time of failure could also help to rule out issues.

Without injecting additional input into the shader (which would require code changes), your options for noise are limited. You could try to use the hash function that the SSAO shader is using; it calculates a "random" value based on the fragment's position: ivec2 screenPos = ivec2(gl_FragCoord.xy); // "random" rotation factor from a hash function proposed by the AlchemyAO HPG12 paper float randomPatternRotationAngle = mod(3 * screenPos.x ^ screenPos.y + screenPos.x * screenPos.y, 3.14159); This gives a value in [0, PI), so you'll want to adjust that for whatever you need. Whether or not this particular pattern will look good for your intended use, I can't say...

It's worth noting that such conditionals do not necessarily have any positive impact on performance in a shader. They only do under very specific circumstances, the easiest of which is if the value you are testing is a uniform. If instead it somehow depends on the vertex input or a texture or similar, it almost certainly will not help. This is because fragment shader invocations are scheduled in groups, and unless a conditional can be definitively decided for the entire group, it will have to evaluate both paths for all fragments. So from my understanding, testing anything involving the normal should not help.

At the moment, only one. We could try to test a download from my mirror with artificially limited download speed. Perhaps there's a hidden timeout somewhere if download takes too long, although I didn't find anything obvious.

Can't find anything in the logs. Mirror itself is up and running, I've been downloading from it regularly with the installer without any issues. Does the installer have any kind of error handling and reporting for connection issues? I.e. would it notice if the connection is closed or unresponsive, or if an error code were returned? (Although I should have seen one in the logs, but you never know...)

We link statically to a GLFW binary shipped with the TDM source. So depending on whether that one's X11 or Wayland would determine which system the resulting TDM binary would support. Linking to both is not possible.

Make sure that in_grabMouse is set to 1. The default value for this changed with the GLFW changes, so if you recreated a new darkmod.cfg with 2.09a before launching with the dev build, you might have the wrong value. The prebuilt executables almost certainly won't. My understanding is you have to compile GLFW for Wayland, so you'd have to compile a custom TDM version with a Wayland-compatible GLFW build. I make no guarantees, though.

@StudentManiac You can try to download and test this build: https://ci.appveyor.com/api/buildjobs/knrpbrrl60ken1v8/artifacts/TheDarkMod.7z It is based on the current dev version, so I can't promise that it'll work flawlessly, but it should at least allow you to start it.

The error message is unique in the code base. So both cause and workaround are fairly clear, in this particular case.

Sorry to interject, but no. The cause is already clear, there is no further information required. If a driver update doesn't fix it, we'll have to work around it in code. There is no other recourse.

You could try installing the latest driver from AMD, anyway: https://www.amd.com/en/support/graphics/amd-radeon-hd/ati-radeon-hd-5000-series/ati-radeon-hd-5550 I'm afraid there's nothing else to do right now. This is a driver bug we'd have to work around or ignore in code, and until then you'll have to stick to 2.08.

Try updating your graphics driver. For details: the error occurs because OpenGL reports a value for GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS that is lower than the value expected by TDM, which is 48. However, 48 is the minimum value allowed by the OpenGL 3.3 standard, so either your graphics driver is lying about supporting OpenGL 3.3 (in which case it should have failed earlier), or the returned value is just incorrect. In either case, updating your GPU driver is the best hope for a fix. What GPU do you have?

I really have to ask, though - why not Unity or Unreal? Or Godot, if open source is important? All three of them are much more modern engines and probably a lot easier to work with, in general. You'd have to find a very specific advantage in using idTech4 to justify that route, imho. And as stgatilov pointed out, TDM is a very specific derivative of idTech4, so even if you absolutely do want to go idTech4, there are probably engine clones that are better suited for it.

See

Already done. It's in the latest dev build.

I'm 95% sure. It works fine on NVIDIA and Intel (recent ones that actually support the extension), and it works on some AMD cards, too. In fact, I remember at least one report where it only broke after a driver update. Which is also the reason why we chose to enable it by default - reports of broken behaviour on AMD only came later and never materialised in internal tests

What happens if you delete the currentfm.txt? Perhaps the dev version conflicts with the currently selected mission. (Just in case it does, it would be helpful to save its current value before deleting it...)

This is what I mean. You seem to think that's our goal, or simply a matter of choice. It is not. But we simply can't test on every possible hardware, we have neither the time nor the resources. The changes in 2.09 are designed to benefit more powerful hardware, yes, but they are not designed to make weaker hardware worse (except really old hardware, perhaps). And in general, they don't. This is a particular case, and we'll have to figure out why. And reporting performance regressions is very much appreciated. Just leave the analysis and assumptions to us Btw, I did a brief test on my work laptop with a 1050 Ti. Performance does drop slightly in @stgatilov's scene, from about 200 fps to 180. So there is a regression, but it's nowhere near your magnitude. I haven't been able to analyse it further, because nSight for some reason refuses to access performance counters on the Laptop, will have to figure that out first.

Well, this might get a little more complicated. 2.07: 2.09: @GadavreI know this is probably not your intention, but your posts often read as if you accuse everyone around here of doing a bad job. But as you can see, issues are typically a little more complicated than they may appear at first sight. We do definitely strive to improve the mod, not make it worse. But we are only a handful of hobbyists working on the project in our spare time. We don't have the resources of commercial studios to test everything on every possible system. Just something to keep in mind That being said, the profiling on my system is pretty clear: GPU time is approximately similar, but 2.07/2.08 are CPU bound due to draw call inefficiency. 2.09 focussed on improving that part specifically, and so the framerate improves quite a bit. Obviously, these improvements do not help if you are GPU bound, but there's also nothing here that would suggest that 2.09 should perform that much worse. I'll try and test on a weaker GPU to see if I can reproduce the issue there. You might also try and update your drivers and system, if there are updates available. Just in case...

Guess I'll fire up nSight later...

If that's true even with `r_useNewBackend 0`, then the most obvious candidates would either be changes to the model/materials itself in-between those versions, or changes in culling behaviour on the frontend. How does 2.08 perform?

That's usually an OS or even hardware feature - the trackpad gets temporarily disabled when you press a key so that you don't accidentally interact with the mouse when typing. Can probably be disabled, but is probably not what you'd want to do for regular usage