Jump to content
The Dark Mod Forums
Sign in to follow this  
cabalistic

I'm working on a VR version - early alpha

Recommended Posts

@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?

  • Like 2

Share this post


Link to post
Share on other sites

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 by BuckleBean
  • Like 1

Share this post


Link to post
Share on other sites

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...

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites

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...)

  • Like 2

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

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

  • Like 2

Share this post


Link to post
Share on other sites

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.

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

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.


Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

Hmm, I wonder if ModelOverlay is at work here.

 

Maybe R_FreeStaticTriSurfVertexCaches shouldn't be called where it is?

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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...

  • Like 2

Share this post


Link to post
Share on other sites

@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.

  • Like 3

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.


My Fan Missions:

   Series:                                                                           Standalone:

Chronicles of Skulduggery 1: Pearls and Swine                     The Night of Reluctant Benefaction

Chronicles of Skulduggery 2: A Precarious Position              Langhorne Lodge

Chronicles of Skulduggery 3: Sacricide [WIP]

 

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...