Jump to content
The Dark Mod Forums


Development Role
  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by cabalistic

  1. FYI, I finally got around to updating the VR mod to 2.10. Just follow the installation instructions: https://github.com/fholger/thedarkmodvr/wiki/Installation There are no new VR features. Development is currently on hold because I'm rather busy working on Half-Life 2 VR. I do want to return to TDM VR as soon as I have the time, though
  2. There isn't necessarily much you can do. TDM is based on an old rendering engine that is not optimized for modern hardware. It only has limited multi-core support and doesn't always make the best use of modern GPUs. As such, your results will vary from mission to mission - some missions are better optimized than others.
  3. I haven't really heard that laptops with discrete GPUs have a significantly higher failure rate. They do, however, affect battery life, weight and consequently mobility of the laptop. The coexistence of integrated and discrete GPUs can also be a painful on occasion, with apps sometimes launching on the wrong GPU and you having to figure out which port is connected to which GPU. If mobility is not your highest priority, I think a discrete GPU in a laptop is generally fine. Otherwise, the Ryzen 6000 chips definitely have the strongest integrated GPU right now (not counting Apple's M1), but they are also still rare to find in an actual laptop.
  4. I must confess, I'm a bit skeptical. While the 12700K is stronger in single-core performance than the 5800X, it shouldn't be that much stronger. There might be additional factors at play
  5. The problem with UI, I'm afraid, is first and foremost a technical issue. The existing UI system is an absolute pain to work with, and any effort to implement any reasonable modern UI concept in that system will drive every developer involved in the effort absolutely insane. I'm only half joking. Before any such effort could take place, I feel that the system needs to be replaced entirely. But that is also a massive pain because there's no good option to keep backwards-compatibility with existing missions. And the most obvious candidates for UI systems are rather large dependencies. So while I agree with the necessity of a UI overhaul, I'm not very optimistic for it to happen anytime soon.
  6. No, I do have a device that shows the issue, that's why I strongly suspect it's a GLSL compiler bug.
  7. No, it's definitely broken. The issue we have with bindless textures, for instance, is almost certainly a GLSL compiler bug. And it's not just NVIDIA that handles all of these things without issue, it's Intel, too. And Intel's driver isn't exactly stellar, either
  8. Given that TDM is based on the older non-BFG code base and has then been heavily modified, I would guess very hard. It's good for inspiration, no doubt, but a direct copy is out of the question.
  9. Maybe I need to start working on a Vulkan backend for real (Mostly kidding. There are a couple of improvements that should ideally be done before going to Vulkan, and I don't really have time, anyway. It is tempting, though...)
  10. At this point, just disable the new backend. It's not worth debugging it any further.
  11. If you can give me a particular map and coordinates (and any particular reproduction steps I may need beyond 64bits and Bloom), I can try and see if I can reproduce it on my Aya Neo.
  12. Please try the 2.10 beta. It has a different window and renderer creation path and might give better results.
  13. 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
  14. 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.
  15. 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
  16. Well, obviously. The outline was always meant as an alternative, not an addition, to the existing highlight.
  17. Because the outline *is* the highlight in that case? I don't know what you are saying here.
  18. 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.
  19. 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.
  20. Sounds like you may have a malfunctioning gamepad/joystick connected? That would explain the cursor movement. Try disconnecting any non-essential input devices.
  21. 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
  22. There's no support for keybinds with modifiers, and it would be rather painful to implement.
  23. 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
  24. 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.
  25. 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.
  • Create New...