Jump to content
The Dark Mod Forums

cabalistic

Development Role
  • Content Count

    942
  • Joined

  • Last visited

  • Days Won

    27

Everything posted by cabalistic

  1. Phew, it's almost exactly been 3 years since my first post about my VR modification for TDM. Three more versions of the game have been released in the meantime, and with them come performance improvements that I feel it's finally viable to continue my work on the VR adaptation So without further ado, head on over to https://github.com/fholger/thedarkmodvr and grab the latest release. It's based on the future 2.09 version, but is fully compatible with a 2.08 install. Although I've tried to make the VR version use its own set of resources (separate `darkmod_vr.cfg` and shader folders), I'd recommend you make a backup or copy of your TDM installation to be able to get back to the flat version cleanly without effort. Please heed the README in the repository, particularly about the choices of VR backends. Some noteworthy information for this new version: performance should be considerably improved from the old alphas. That doesn't mean it's perfect - although the CPU bottleneck is now completely gone, the game is now severely fill-rate limited. So if you have a current-gen headset with high resolution and/or a weaker video card, forget about any supersampling or AA. I also strongly recommend to stick to stencil shadows and disable soft shadows and ambient occlusion - the latter isn't that impressive in VR, anyway, and simply not worth the GPU cost. And even then, there will be some scenes in some missions where reprojection is just unavoidable, even with the beefiest GPU. That being said, I have tried a multitude of maps, and I think it's very playable. the UI is finally usable! Both the menu and ingame HUD elements are projected to a virtual screen in front of your sitting position. It's not the most elegant or immersive solution for the HUD, but it works vertical mouse movement is excluded from the VR view - this was suggested by some of you way back, and I think it makes the experience much more enjoyable. It can make it a little hard, though, to aim with the mouse for actions like frobbing items, because there's currently no visual indication to where the mouse is pointing. I'm planning to add one asap, but in the meantime, you can equip a weapon to get a vague sense of your mouse orientation. If you do want to re-enable vertical movement in the view, set 'vr_lockMousePitch' to 0 in the console. Other than that, I hope you enjoy this new version. Let me know which improvements you'd like me to work on first. Also, there are probably any number of render and other bugs still left in there somewhere. If you find one, please report them over at the Github tracker (https://github.com/fholger/thedarkmodvr/issues), so I can keep track of them.
  2. Well, more like "applied a band-aid". ESCAPE key works for me, and unfortunately I don't have any immediate idea to offer if it doesn't for you. You could try to change your keyboard layout to an English variety, if it isn't, maybe that helps? The whole input handling on Linux needs a major rewrite. It is completely outdated and doesn't work well on modern X systems, I'm afraid. I don't know if and when I'll have time to do that, as it's not a minor task, so if anyone wants to tackle this, please do. Might even be worth considering using something like GLFW or SDL to do window management / input handling to free us from having to deal with X and Wayland on our own...
  3. I just tried the installer on Linux, and it has some problems with folder permissions: it created the "fms" folder with permissions 644 instead of the required 755, and consequently it errored out on not being able to create anything inside the fms folder due to missing permissions.
  4. I stumbled upon another little problem with the heatHaze shaders. They use some projection math to calculate their effect, and that does not play well in VR - it leads to eye bleed. I'm not familiar enough with how heatHaze works to know if there is a "proper" way to fix it for VR, but for the moment I've replaced the dynamic projection math with a fixed constant. Looks okayish, good enough for now, I hope. I think I'm getting close to a new alpha version that I'd feel good enough to release
  5. So, I got stereoscopic rendering working. Unfortunately, I'm currently unable to get OpenXR working reliably with SteamVR. It's throwing runtime errors, and generally seems to cause significant CPU overhead. It's entirely possible I'm doing something wrong, but the same code seems to work fine with the Oculus runtime, so this might also be early adopter pain on the SteamVR side. I'll need to dig a little deeper to determine whether I need to open bug reports or not. Anyway, for the time being I added an OpenVR backend and am trying to keep them in sync. That shouldn't be too hard as long as I'm not diving into input handling. Issues I'm currently focussing on: Light scissors. They are vital for performance, but I need to recalculate them for each eye view, and if done improperly, they can lead to flickering lighting or even mismatched lighting between the eyes. It should be a fairly simple calculation, but oddly enough I still struggle with some border cases. Still, might be good enough for a first alpha. Subviews, particularly mirrors, are broken, which is expected, since they need a different approach to adjust them to the eye views. Should hopefully not be too complicated to fix. Other than that, I think the version I currently have is already a massive improvement over the previous alpha. UI (both menu and ingame elements) render to a virtual screen that is placed slightly in front of you. Not the most immersive solution for the ingame elements, as now the lightgem basically "floats" in the air in front of you, but it was a simple solution that makes everything usable in VR, so a good starting point, I think. Also, I uncoupled the mouse vertical movement (pitch) from the VR view, which makes it a lot more tolerable to navigate in VR, I think. Downside is that it makes it a little harder to aim and pick up stuff with the mouse, as you don't have any indication where you are pointing at until an item lights up. Will need to figure out a way to render a simple 3D pointer target to indicate mouse aim. Performance is alright; I'd hoped for more, but current headsets have increased the resolution quite a bit, and TDM is ultimately fill-rate limited. That means there's little (if any) room for AA or supersampling, and you better keep expensive effects like soft shadows or SSAO off - the latter isn't really that important for VR, anyway. I played through "New Job" with my Index set at 120 Hz and could keep that framerate most of the time, but there were a few instances with reprojection. Not too bad, though, but this is with an RTX 2080 Ti, so... There's still one relatively simple optimization that I can do that should save a bit of fillrate.
  6. Hm, for a conscious design choice I've seen them implemented really badly way too often. It depends on the particular game, of course. I don't mind checkpoints in many games, but particularly in the stealth genre, they tend to ruin the fun for me. The most striking impact I observed in the Splinter Cell series. Whereas in the first three games, I really enjoyed going for a stealthy approach, I absolutely hated it and felt punished for it in the later games, and the difference is exactly quick saves vs. checkpoints. In the first games, I could quick save whenever I wanted - and it was incredibly fast, both the saving and the loading. And as such, I felt more inspired to try and take some risks, and if I did get caught, I didn't lose much progress and could just try something else. In the later games, however, getting caught means being reset to the last checkpoint, and if you are taking a stealthy and cautious approach through the level, that means easily replaying your last 5-10 mins. And nothing, absolutely nothing, infuriates me more than replaying the same part of the game over again that I just went through, particularly if my mistake came later. And that led to me very quickly abandoning the stealth approach, because it felt way too punishing. Playing the levels action-style also meant you went much quicker from checkpoint to checkpoint, so less time lost if I die. But playing the games action-style also diminished my enjoyment of the games immensely, and so this is at least one example where my enjoyment greatly suffered from checkpoints...
  7. Baby steps: I've got headset tracking working, I think. It looks good in the 2D view, i.e. camera follows headset movement and orientation. Still no stereo rendering, though. That's the next step; in principle it shouldn't be too hard since all elements are now in place. However, I expect a lot of subtle rendering bugs where the contents of the eyes don't quite fit due to some obscure values that haven't properly been recalculated for the eye views
  8. I'm pretty sure 2.08 does require more VRAM than 2.07, due to mandatory FBOs and a few other things. I don't know if the increase is enough to make a difference, but peter_spy might have a point. Also, be sure to enable multi-core enhancements in the options, that should help performance a bit.
  9. Bloom in 2.08 is comparatively cheap. You should turn off SSAO, first, or at least set it to its lowest setting
  10. Uuhh... okay yeah, that is puzzling. I would suggest replacing the if condition with GLAD_GL_KHR_DEBUG, although if you are sure that CheckRequiredFeatures already finished prior to the call, it really shouldn't make any difference. Even more confusing: if the extension isn't available, shouldn't that call just crash hard due to a null function pointer, or is GLAD redirecting missing functions to a noop?
  11. I'll probably open a new thread once I believe the new version to be ready for alpha testing. But since you're interested, I thought I might give a status update on my progress in the meantime: all the backend rendering improvements I wanted to do before returning to VR are now merged to the base game and to be released in 2.09. This makes my life significantly easier in maintaining the VR mod, because I don't have to juggle additional rendering overhauls when merging changes from the base game. I have the basic OpenXR setup done and can successfully initialize a VR session with it and acquire all the rendering resources I need. Next up is getting actual rendering to the headset - this won't be a stereo rendering, yet, I just want to get some output so I can verify that what I've done so far actually works The roadmap / vision for the first new release is roughly to get a decently usable keyboard/mouse sitting experience working. In particular, I hope to have the following improvements over the initial version I released: usable UI, i.e. rendered to a virtual screen instead of glued to the eyes decouple vertical mouse movement from the view, but possibly introduce an (optional) reticule to indicate the mouse's aim Let's see how it goes. Can't promise a particular timeline, but I'll try to get something workable asap
  12. Have you enabled multi-core enhancements in the options? That's the one option that would give you the most immediate jump in performance compared to older versions. But that is a 2.06 feature, so if you've had it enabled from the start, there were no other major improvements from 2.06 to 2.08. But yes, the GPU does matter, particularly if you enable features like soft shadows.
  13. 2.08 contains a lot of the technical prep work that makes the improvements in 2.09 possible in the first place Also, the improvements in 2.09 require scenes that are CPU bound. If they aren't you won't see much of an impact.
  14. No, this shader is only needed by an experimental feature, and even if it were enabled (which it is not if the Darkmod.cfg file was deleted), it would only affect actual ingame rendering, not the menu.
  15. It's going slow, but steady. Since Valve finally published on OpenXR runtime, I decided that I would go the OpenXR route for the new VR version, which I think makes the most sense. Unfortunately OpenXR is, like every Khronos API before it, an absolute pain to use, particularly compared to the simplicity that is OpenVR. So it's taking longer to learn and implement
  16. According to the gpuinfo database, the HD4800 should support OpenGL 3.3, so it should be able to run TDM 2.08 and the upcoming 2.09, at least. Chances are this is either a driver bug, or we're doing something wrong on the coding side. It would be great to find out the cause, and then perhaps we can fix or work around it. Unfortunately, I don't have any immediate ideas right now, will have to think about it.
  17. No, there is no matching format, and even if there was, it would look horrible. Although I wonder if what you actually mean is what r_fboColorBits 32 gives you, anyway. The bits are a total number, not per channel - so r_fboColorBits is 32 bits for RGBA, meaning 8 bits per channel. Perhaps that's what you wanted, anyway?
  18. Let's try not to mix different things together, it only muddies the argument. Far as I understand the story from Wikipedia, one guy in an article critized the game he'd never played, and the developer called him on his bullshit. Nothing was censored, games to this day still have black and female zombies, and I'm not aware that anyone then or now has been trying to raise that particular argument again? Sounds to me like a non-issue - you'll always have some people speaking nonsense, that's just par for the course. I'm inclined to agree with you on the TV series. I don't know that particular show, but even if you have legitimate issues with its contents, I'd argue that pretending it doesn't exist is a poor choice and a missed opportunity. For the magic cards I lack a bit of context, not knowing the history of those cards and not being a Magic player myself. The one card that the article shows I can immediately understand why it's a controversial card, although in the right context I'd also accept it as a brilliant satire. Though from what little is in the article it doesn't sound like it's satire, so... As for renaming technical terms: the move from Github at this particular moment in time is virtue-signalling and activism, for sure. To be fair, though, this debate has been ongoing for several years and precedes the recent protests. Some projects already switched terms a while ago after long debates. And given that it's been public and controversial debates, I don't find fault in that. Eventually, any decision taken will displease someone But even if you find the renaming unnecessary or downright moronic, I don't see that anything is being censored or oppressed here.
  19. Riiiight ... I think you forgot to mention George Soros somewhere in there...
  20. I'm sorry, what are you talking about? What zombie game was released in the past few weeks that sparked outrage about its zombies? TLoU has sparked plenty of outrage on different things, or did I miss something here?
  21. Annoying bug. There's a subtle dependency of the order in which certain objects get deleted because they can reference each other, but it's so implicit that you basically can't see it in the code. I hope I fixed it, but I can't be 100% certain. Would appreciate it if you could test this executable, and let me know if you do find more crashes: https://ci.appveyor.com/api/buildjobs/q614b4ojrmat3umc/artifacts/TheDarkMod.7z
  22. Thanks, I can reproduce it. Some kind of memory corruption.
  23. Note: this is obviously a notorious scene, and you need a decently powerful GPU to see improvements from CPU time reduction
  24. Then I'd suspect you're testing the wrong scene, or your other settings are too light. Setting FBO resolution to 2 (which means 4x the pixels!) takes twice as much GPU time for my RTX 2080 Ti at the Briarwood Manor opening, for example. It's already impressive that it doesn't take 4x as much time, but it *is* by far the most expensive graphical option there is.
  25. Some people will try to set every graphical setting to its maximum if they have a decent system, but for something so ridiculously expensive like supersampling, that might be deceptive. I'd argue that it's an advanced setting for people who know what they're doing.
×
×
  • Create New...