[How do I disable console?]

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

[Stalls on Install]

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.

[Unable to link openal during compilation]

10 hours ago, Alberto Salvia Novella said:

If I compile libraries by myself, that gcc dir is "gcc10". Although this is easy fixed by substituding the string with:

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.

[Stalls on Install]

5 hours ago, Alberto Salvia Novella said:

It seems to depend on how busy the server is at that moment. After many tries it couldn't work at all, but if you try later it could always work.

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.

[Messin with shaders]

22 minutes ago, totallytubular said:

I really want to get a noise generation routine going, because it could be used to tone down the "wet / gloss look" of speculars while preserving the brightness / shine. I can't seem to figure that out, though.

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...

[Messin with shaders]

8 minutes ago, totallytubular said:

With BRDF going, my FPS has dropped a bit, but game is still playable. So, I looked at the functions, and noticed that if some key variables are 0, they'll just generate a 0 output. So, added some logic branching to skip BRDF and just default to 0 if those key variables are 0. Didn't really help with performance; not many things will be 0.

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.

[Stalls on Install]

4 hours ago, stgatilov said:

Any ideas?

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.

[Stalls on Install]

22 minutes ago, stgatilov said:

@cabalistic, maybe you could look at something there?

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...)

[Linux testers needed: new window management and input handling]

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.

[Linux testers needed: new window management and input handling]

7 hours ago, datiswous said:

But then in TDM I constantly see a desktop mouse cursor in view aside from the normal cursor.

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.

4 hours ago, MirceaKitsune said:

I'm still curious about a little detail if anyone happens to know the answer: Does the new window management and input system support Wayland natively... by which I mean using the pipeline without having to go through X11? I'm re-asking because I hear KDE Plasma 5.22 (coming next month) should fix all the final issues I was personally running into and kept me on X11, thus a switch may be on the table again.

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.

[Dark mod won't start after 2.09 update]

@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.

[Dark mod won't start after 2.09 update]

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

[Dark mod won't start after 2.09 update]

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.

[Dark mod won't start after 2.09 update]

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.

[Dark mod won't start after 2.09 update]

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?

[ATTN ALL, question about Dark Radiant & professional use]

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.

[[Resolved in TDM 2.10] Any plans to reimplement bordered display at lower resolutions?]

See

 

[[Resolved in TDM 2.10] Any plans to reimplement bordered display at lower resolutions?]

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

[Green shadows bug]

13 minutes ago, OrbWeaver said:

Are we absolutely 100% sure that it is actually a case of a broken driver? Could it be that we are not using the extension exactly as the specification demands, or are exercising some edge case that AMD aren't expecting most games to use?

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

[Crash on startup]

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...)

[The mission has low fps. Searching for a solution.]

1 hour ago, Gadavre said:

Do not make new versions of this game available only for owners of powerful gaming computers. You can always leave ability  of playing with the performance as in 2.07.

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.

[The mission has low fps. Searching for a solution.]

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...

[The mission has low fps. Searching for a solution.]

Guess I'll fire up nSight later...

[The mission has low fps. Searching for a solution.]

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?

[Linux testers needed: new window management and input handling]

28 minutes ago, Lzocast said:

same issue I have on other laptops (and other OS types) that the game doesn't like you trying to move with WASD and use the trackpad at the same time

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