Jump to content


Development Role
  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by cabalistic

  1. Usually, mods are a work of passion and love; that's why they are offered for free despite the significant time and effort invested into them. But if nobody picks it up as their passion project and you actually want to pay someone for it, then you'll have to expect to pay a full salary. In your case, I'd say you would have to hire a team (a programmer isn't enough - you will need people to port or probably remake the assets for the new engine) and expect work for several months. So think about what salary you'd want to earn to have a decent living and multiply that by a couple of people and months, and you'll have a rough idea of what it'd cost.
  2. I think what happens is that the old method caps the framerate at just slightly below 60 fps - which means that in combination with VSync (either enabled in the game or forced by the compositor) will drop the framerate to 30 fps most of the time.
  3. No idea what you consider working. I'm not developing in a VM, so can't really help with that. You can always disable `in_grabmouse` if you prefer the game not to take control of the mouse.
  4. Makes zero difference on the newest driver. Don't think that particular trick survived whatever magic overhaul they pulled for this update. All the better, though Anyway, would have been shocking if they had managed such a massive update without introducing new bugs. In this case, they broke the findMSB function in GLSL - the compiler goes haywire on it in ssao.frag.glsl (line 81). It does work if we just use the fallback that's already in the shader behind an #ifdef, and I just checked and the fallback doesn't seem to perform any different on my NVIDIA card, so ... Would be the easiest way to fix it that I can see.
  5. Yeah, I am aware. I'm evaluating an all-AMD laptop right now, and it raised FPS from 90 to 200 fps in St. Lucia. That's pretty wild. (Though admittedly, the 90 fps were with SSAO enabled, so the comparison isn't quite fair. Still, that's probably the most significant performance increase that a driver update has provided, ever.)
  6. It's an issue with the ambient occlusion. If you disable it (r_ssao 0), it should fix the issue. I'll try to look into it later.
  7. Have you read the docs? https://www.glfw.org/docs/3.3/group__input.html GLFW_CURSOR_DISABLED is very much intentional. It should release the mouse cursor automatically if you alt+tab out of the window, so this is the intended behaviour for regular users. There should be a cvar to keep it ungrabbed for dev work, iirc.
  8. There was a change in the installation process - the old updater has been retired for a new installer. You will have to redownload that installer from the Downloads page -> https://www.thedarkmod.com/downloads/ Extract it to your existing TDM installation and run it. It should then allow you to update to 2.10.
  9. To be clear, I personally did use the native build. It works fine I haven't tried Proton, so I don't know how they compare.
  10. I have tested TDM on the Steam Deck, too, and just to be clear, performance depends on the maps you play. A lot of them run (mostly) fine on 60fps, but some do not. The opening scene for Iris, for example, drops down to 30fps.
  11. Yes, it should. You need to be close enough to the door and also move the cursor (the white dot) with the right thumbstick over the door.
  12. With that config, right trigger should allow you to open doors if the door is highlighted.
  13. 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
  14. 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.
  15. 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.
  16. 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
  17. 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.
  18. No, I do have a device that shows the issue, that's why I strongly suspect it's a GLSL compiler bug.
  19. 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
  20. 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.
  21. 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...)
  22. At this point, just disable the new backend. It's not worth debugging it any further.
  23. 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.
  24. Please try the 2.10 beta. It has a different window and renderer creation path and might give better results.
  25. 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
  • Create New...