cabalistic

Essentially, it's as unsafe as Vulkan. more or less. Windows is fairly robust against driver crashes these days, so it's unlikely to bring down the entire OS.

Um... com_fixedTic is available in the menu under Video -> Advanced -> Uncapped FPS. Furthermore, the default value is in fact 0. There is no need for a custom file to change this setting, and it's not going anywhere

If it were not compatible, you should be getting a black screen because nothing could be rendered without textures. But in practice, it does render, just with confused texture associations. It looks and feels very much like a bug, but unfortunately I don't (yet) have access to an AMD device myself, so it' very hard to debug...

Disable r_useBindlessTextures. I'm afraid this is probably some sort of AMD driver bug.

No, and I have a feeling this isn't going to be possible, ever. If even NVIDIA doesn't offer a vendor-specific raytracing extension for OpenGL at this point, then it's very unlikely to ever be added. No way around Vulkan at that point.

Since the weights are positive, this can only be negative if the source texture is already negative.

I really need to stress this, but no, that's not "the plan" The plan is to do some experiments with PBR some time in the future after some other groundwork has been finished, and from that figure out what might or might not be done, and how. Even if the outcome is generally positive, that will almost certainly not happen for the next few releases, and even then it could realistically only apply to newly created missions with PBR in mind. So the current lighting is not going away in the foreseeable future (and beyond).

Keep in mind the manylight shaders are almost as experimental a feature as it gets. They will almost certainly change for 2.10 or even get ditched entirely, and they have certain issues right now. So yeah, they have a "high risk" with being revamped for 2.10. Then again, 2.10 isn't going to be released any time soon.

Well, if you can find a way to map mouse buttons to emulate key presses, that could work. No idea how to do that on Linux, though.

It's a known limitation due to awful input handling on Linux: https://bugs.thedarkmod.com/view.php?id=5208 That whole input code needs a full rewrite, so I can't make any promises on a speedy resolution.

Of course, but the amount of code that can be "copied" is limited due to the differences in engines between TDM and D3 BFG, and also the difference in weapons and interactions.

You can hot-reload shaders, btw. I think the console command is 'reloadGLSLPrograms' or something similar; if you hit reloadGLSL<TAB> it should definitely complete to the right one. No need to restart the game or the missions

The #pragma TDM_DEFINE is a construct to speak with C++ code. Without modifying C++ code, that directive will never do anything for you. You'd need to "#define FAKE_PBR 1" if you actually want FAKE_PBR to be something.

No, it doesn't work like that. The cubereflect shader needs to be added in a material as a material stage, and in that stage you define the texture (in this case, a cubemap) that gets bound as u_texture0 to the shader. The lighting shaders, on the other hand (i.e. everything called interaction) are completely separate and controlled entirely by code. They get exactly the textures they have now, and nothing more. If you add another texture uniform, at best it will point to a random texture, at worst it will give you garbage or even crash your driver. Also, we don't currently have an automated system to get environment cubemaps. That's sort of on my roadmap for 2.10. But right now, the cubereflect shader is only usable with a manually created cubemap and a manually set up material.

No, it is not currently possible in 2.09 and Windows. Lowering the resolution scale is the only choice, and it will give similar results.

Pretty much, yes. As far as lighting goes, translucent materials are treated like any other material, only they are added on top of anything solid already rendered. Alpha is not taken into account as a weight for this, so it's rather difficult to control. This isn't exactly great behaviour in my opinion, but unfortunately it's also not quite easy to fix. One upside is that it's at least order-independent, because otherwise that'd open a whole other can of worms

Short of 4 Gb. The installer claims it will download 3706 Mb.

Oh absolutely. And just to be clear, my interest in PBR isn't really in giving TDM a stylistic overhaul, "next-level graphics" or any such nonsense I'm more interested in if it could make our artists' lives easier, as peter_spy hinted. As an "industry standard" in some sense, it has better tooling and potentially a more consistent look across different scenes, which might need less tinkering. But again, that's all speculative

A potentially significant difference, though, is that Doom 3 assets all have a coherent source and style. That makes it potentially easier to apply some kind of hacks to make them look decent when combined with PBR. This might be a lot harder to do for TDM, where assets come from various authors with different creation process and style. Ultimately, though, all of this is pure speculation. We won't know anything until we actually experiment with it in a controlled fashion. Then, and only then, will we see what may or may not be possible and how best to move forward. But either way, before such experiments can happen, there is some ground work to be done, so I feel this is a discussion for another time

Personally, I'd be all in favour to replace the current GUI system with something else. It is just terrible. So terrible, in fact, even id Software replaced it for Doom 3 BFG . And while I'm not a fan of HTML/CSS, either, I wouldn't dismiss it. It has the huge advantage of established powerful tooling, and it also offers good ways to alter the look without changing functionality, something which would be very beneficial to TDM. And a lot of people probably have at least some level of knowledge of HTML, whereas CEGUI or others like mygui, imgui, ... would be yet another custom scheme to learn. However, as always the problem is backwards-compatibility. I'm almost certain that wrapping existing GUI scripts to use any new GUI system behind the scenes is as close to an impossible task as we can get. So we'd have to establish it as a second GUI system to coexist alongside the old one for a while. But if we wanted to use the new GUI system for the main menu (which would frankly be the primary appeal), we would immediately break any customized menu in released missions, and there isn't really any way to avoid that. I don't believe such a move would find much love in the community So unfortunately, we're probably stuck with the existing system.

I would steer clear of such a license. It is too vague to know if your use is acceptable or not, because in its most extreme interpretation, it is simply unachievable. At best, you could contact the author to clarify and/or give you explicit permission for what you want to do. But otherwise, that's just a garbage statement, and that wouldn't change at all if we had any kind of package obfuscation/encryption.

Again, not without permission. Unless otherwise stated, it is an author's perogative how he chooses to distribute his work. The beta testers forum is publically accessible, so posting the mission there does give everyone the ability to download it as long as the provided link remains visible. It does not, however, imply a right to redistribute the work on any other servers including the official missions mirror.

Not if you don't have his permission. Do not try to guess what someone may or may not find respectful. If he vanishes in the middle of his work, that does not give you the right to decide what should be done with it. This is the part where I have to agree with peter_spy strongly.

I may have to see such a license to understand what is truly required, because from a technical perspective, an "unopenable package" is clearly nonsense. The game would have to be able to open it, and with the game being open source, that would immediately tell anyone who is interested how to do it. Add to that the potential effort and added complexity to implement any sort of protection (which takes dev time away from other areas) and potential increase to load times, I'm very sceptical this would be worth it. For me, this is a common theme with DRM measures - they tend to hurt the honest people more than the dishonest ones. As for the broader topic: there should be no doubt that authors have the sole authority to dictate how their works should be used. This is typically guaranteed by copyright law, but even if not, it isn't up for debate. Obviously, if your work builds on existing work, you have to adhere to any restrictions that come from that. Now, as a coder I may have a slightly more relaxed stance concerning my own contributions, because with the advent of the open source movement it is now fairly common practice to release code under a permissive license, and I typically do so even if I'm not obligated to (as TDM code contributions are by the original Doom3 GPL license). Yes, it is initially scary to do this, to "let go" of your own creations, knowing that anyone could do any kind of stupid shit with it. But it can also be very liberating, and the benefits usually outweigh the bad outcomes. Personally, I think asset creators could also benefit from a more relaxed approach here, because I frankly don't agree that code is somehow fundamentally different. In fact, I find that a little demeaning, as it suggests asset contributions are somehow of an inherently higher value that deserves greater protection?! But again, this is an individual choice and your choice alone. What I do strongly suggest for anyone to do is to make the terms of what you deem acceptable usage clear. To that regard, every mission, asset pack etc. should include a license.txt that states what uses are acceptable and also lists any non-core third-party assets included and their respective author and license. This is common practice in the software development world, and I think it would also benefit the mission-makers. Because more so than any DRM mechanism, it clearly states the acceptable terms of use, and whoever then disregards those is simply a dick.

I think that's plausible, especially if combined with throttling due to overheating. In such a scenario, the smallest improvement might lead to a significant change in outcome. But yeah, that's certainly an unexpected, but welcome outlier In most instances, the average performance gain should be relatively small, but in some specific scenes, it can be significant.