I'm working on a VR version - early alpha

[duzenko]

@grodenglaive: Thanks. Yeah, mouse movement, GUI elements and the shadow issue are my priority when I continue working on the VR version. However, that probably won't happen before the release of v2.06 anymore. There are just too many changes to the engine to continue working on the 2.05 version.

How about adding the VR code in the trunk svn?

[nbohr1more]

Yeah. Do it!

[BuckleBean]

I have a general question - are there any concerns with sharing this alpha with anyone outside of the TDM community? I've recently been asked for recommendations for seated VR games/ports/mods like Alien Isolation. This fits the bill, but I haven't mentioned it to anyone besides grodenglaive, who's been active here. I'd hate for this thread to be inundated with tech support questions, especially since the mod is on hold for the moment. On the other hand, anyone could stumble into this thread and download the mod.

 

Cabalistic, do you have a preference? I'm happy to oblige.

Edited September 13, 2017 by BuckleBean

[nbohr1more]

Hmm...

 

The lightgem is not re-initializing on mission installs. You have to exit TDM and start it again

to get the lightgem back.

 

We had this problem during the 2.05 dev cycle.

 

http://bugs.thedarkmod.com/view.php?id=4395

rev 6640

 

Not sure why this is broken now...

[woah]

Oh man, I can't believe I didn't see this until now. Even if there are many technical challenges, I really can't think of a better type of game to adapt to VR. Not only that, adding VR support could bring in many new players and perhaps get more people interested in developing for the mod. VR users are starving for this kind of content. And while many gamers don't have the patience to play the flat version of a Thief game, I think this will be different since from my experience VR lends itself to slower, more immersive gameplay. The mod could also benefit from the many performance optimizations that VR would necessitate.

 

@cabalistic By the way, did you make a post on /r/vive a while back requesting suggestions for a game to mod VR support into? I vaguelly remember someone requesting this and then someone else suggesting this mod.

[cabalistic]

Sorry guys, I was away for a few days...

 

@woah: If by a while ago you mean months ago, then I may have written an answer to that post where I suggested Freespace, Jedi Knight and perhaps even The Dark Mod (not sure about that). But I was not the OP

 

@BuckleBean: As you said, it's publically available. I did not post about it outside of this forum due to its vastly incomplete nature, and I feel it might disappoint a lot of people in its current state. My goal is to have it close to the Doom3 VR mods, but it's a looong way off. Even so, as long as you emphasize its current state, I don't mind you mentioning it

 

@duzenko: I really don't think adding the code to the trunk is a good idea. VR support goes very deep into the engine core; to keep it completely optional would require a lot of code switches in a lot of places. That, in turn, will increase the code complexity and has a high risk of creating diversions between VR and non-VR engine code. Right now, when it's only just the bare-bones stereo rendering and head-tracking, this might just barely be feasible. But if I finally get around to roomscale additions, the changes will become more significant. To be honest, I would personally much rather keep this in a separate repository and pull changes from the SVN when needed. At the very least, this would require a very thorough discussion and analysis by the team before incorporating it into the trunk.

[nbohr1more]

Hmm...

 

The lightgem is not re-initializing on mission installs. You have to exit TDM and start it again

to get the lightgem back.

 

We had this problem during the 2.05 dev cycle.

 

http://bugs.thedarkmod.com/view.php?id=4395

rev 6640

 

Not sure why this is broken now...

 

http://bugs.thedarkmod.com/view.php?id=4621

 

Fixed. By me. (Surprisingly...)

[cabalistic]

Been a while, but a small update: I updated my vertexcache branch with a "fix" for the problems when loading savegames. I actually disabled the pre-generation of static interactions as it seems to be broken when loading a savegame. Not sure why, but disabling it helps and doesn't seem to have an impact on anything else. As far as I can tell, everything appears to be working now with the BFG style vertexcache. Framerate impact is minimal; it does seem to bring a few extra frames in some tight spots, but nothing really noticeable.

 

I'm not sure where to go from here. Should I merge it back to trunk? Initial tests look fine, but it is a significant change and might have some hidden problems or bugs I didn't spot yet. However, it is kind of an important step before porting further BFG changes, so getting it into trunk would be helpful to avoid regular merge conflicts with upstream changes.

Let me know what you think. If you want to try it out for yourself, the code is here: https://github.com/fholger/thedarkmod/tree/vertexcache

[nbohr1more]

Will test tonight!

 

I think we should be ready to merge.

 

2.06 freeze should be around the commit "SS: allow shadow FBO with r_usefbo 0" so anything newer

is going to be manually added to 2.06 during beta.

[duzenko]

Trunk

[nbohr1more]

I am getting CTD crashes when I shoot an arrow through the head of an AI.

 

Mission: Closemouthed Shadows.

[cabalistic]

Just to make sure: it doesn't happen with svn trunk?

[nbohr1more]

Right. Trunk does not crash with that sequence.

[cabalistic]

Thanks, I'll look into it.

[nbohr1more]

I tested a few permutations of setting toggles to see if there was a cvar (r_useStateCaching, etc)

that tickles the bug but no change I tried would resolve this crash.

 

It was too late for me to look at the debug data last night but I can try to gather a stack tonight

if I get a chance.

[cabalistic]

Thanks, but it is easy enough to reproduce it. The crash happens in the copy operation when copying decal vertices to the mapped temp vertexbuffer. It appears as if the vertexbuffer in that code path is not properly initialized; several of its parameters look way off. Strange, though, that this only surfaces in this very specific instance and not generally. After all, it's not like there are different vertexbuffers for the general scene and for decals...

 

So yeah, I know where the crash happens. I don't fully understand the why, yet

[nbohr1more]

Hmm, I wonder if ModelOverlay is at work here.

 

Maybe R_FreeStaticTriSurfVertexCaches shouldn't be called where it is?

[duzenko]

Feature request: add message pump loop while waiting for the front end thread.

Reason: front end might sometimes try to send messages to the error window -> freeze.

[cabalistic]

Hm, do you have a reproducible case for this? I wonder if it's even thread-safe to send messages directly, or if that might need a workaround. I'll have a look at what BFG does.

[duzenko]

Hm, do you have a reproducible case for this? I wonder if it's even thread-safe to send messages directly, or if that might need a workaround. I'll have a look at what BFG does.

Add common->error(...) to anywhere in frontend. It uses a SendMessage on Windows so it's very safe but requires the main thread to pump messages for this to happen.

[cabalistic]

@duzenko: Are you sure this is just a message pump issue? I added a common->Error call, and I immediately get a crash, not a freeze. Looking at the code, Common::Error tries to shut down the game by calling various methods which are decidedly not thread-safe. I don't think in its current state this method can work at all with threading enabled. Definitely not from the frontend, probably not even safely from the backend.

 

I had a look at the BFG version, but it's essentially the same, so probably similarly broken. Fixing this could be quite involved - you would need a way to stop executing the frontend or backend (whichever it was thrown in), then wait for the other thread, signal the error to the backend (main) thread and stop the game after the sync point. Doable, but quite a bit of effort. Is it worth it? After all, errors should be fairly rare except for development issues. You can always disable the multi-threading for debugging...

[cabalistic]

@duzenko: I went ahead and implemented the necessary indirections. It's not the nicest bit of code, but it appears to work. I haven't tested all possible cases, yet. The required changes would look like this: https://github.com/fholger/thedarkmod/pull/1/file

Basically, the Error and FatalError methods first throw an intermediate exception. On the frontend, this is caught and stored and then rethrown on the backend. In the backend, it is caught and then defers to the actual implementation of those functions. I have tested Error from the frontend, which worked fine. I still need to test using the functions on the backend, that might need an extra sync with the frontend.

 

Let me know if you think it's worth it. I can then push it to trunk after the additional tests.

[duzenko]

Let me know if you think it's worth it. I can then push it to trunk after the additional tests.

It's exactly what I had in mind. Does it show the error window in the end? If so, it's good for trunk.

[cabalistic]

Yeah, it seems to be working. I pushed it to trunk; let me know if you find any problems.

[Bienie]

First, deep respect to you for working on a full VR conversion for the Dark Mod. That is exactly what I've been dreaming about since I purchased my Rift CV-1. I don't really have any programming knowledge but if I can help in any other way I'd be more than happy to! Not sure if I could figure out how to compile your current version and give it a go, but I would very much like that. I think if we eventually can have a roomscale-ready version it would not only take the dark mod experience to a whole other level but also bring in a lot of the VR-crowd.