Jump to content
The Dark Mod Forums

I'm working on a VR version - early alpha


cabalistic

Recommended Posts

Here is my tdm_update.log

It displays 2.06 in the main menu of the game, but only there. When I try opening it with VR mod installed and the game gives me the initialization error it's called 2.05:

According to the log, you should have proper 2.05 version.

I could suspect that probably you run 64-bit version, forgetting that 2.05 did not have one. But your log suggests that you did a clean download, so you should not even have the 64-bit executable.

 

I tried to update from same address starting with 2.07 installation.

I see version 2.05 both in menu and game console after update.

Maybe you should disable you antivirus and run the updater again with same settings.

  • Like 1
Link to comment
Share on other sites

According to the log, you should have proper 2.05 version.

I could suspect that probably you run 64-bit version, forgetting that 2.05 did not have one. But your log suggests that you did a clean download, so you should not even have the 64-bit executable.

 

I tried to update from same address starting with 2.07 installation.

I see version 2.05 both in menu and game console after update.

Maybe you should disable you antivirus and run the updater again with same settings.

 

It's quite possible that I ran the x64 executable when it displayed 2.06. I tried again and now it's says 2.07...

 

I actually switched back to the original executable for 2.05 and I'm getting the same problem with "error during initialization" that I posted a screenshot of. That probably means that this problem is not related to the VR mod, but rather TDM 2.05. Any idea why the x64 executable works but not the x86? It works without a problem in my regular 2.07 install...

  • Like 1

My Fan Missions:

   Series:                                                                           Standalone:

Chronicles of Skulduggery 0: To Catch a Thief                     The Night of Reluctant Benefaction

Chronicles of Skulduggery 1: Pearls and Swine                    Langhorne Lodge

Chronicles of Skulduggery 2: A Precarious Position              

Chronicles of Skulduggery 3: Sacricide

 

 

 

Link to comment
Share on other sites

Oh, ok I will try to delete all files except the tdm_update_tdmsync and tdm_mirrors and reinstall then, cause I just took my 2.07 and made a copy and updated. Maybe with a fresh install, and no x64 shenanigans the game will boot.

 

edit: Yup! That worked! Thanks stgatilov!

Edited by Bienie
  • Like 1

My Fan Missions:

   Series:                                                                           Standalone:

Chronicles of Skulduggery 0: To Catch a Thief                     The Night of Reluctant Benefaction

Chronicles of Skulduggery 1: Pearls and Swine                    Langhorne Lodge

Chronicles of Skulduggery 2: A Precarious Position              

Chronicles of Skulduggery 3: Sacricide

 

 

 

Link to comment
Share on other sites

  • 3 weeks later...

Just a quick note, I have a Valve Index set to arrive later this month. I'm very excited to take TDM for a spin with the new headset. Since it uses SteamVR, I expect it to work just as it did with the Vive & Rift. For what it's worth, I didn't have any luck using SteamVR input to rebind the keyboard/mouse controls to VR controller triggers/buttons. I may explore other solutions once I have the Index + controllers in hand.

Link to comment
Share on other sites

  • 3 months later...

I never tried - the frontend changes from BFG were too drastic. I did manage to parallelize some parts of the frontend, but it was a challenge to get the relevant data structures thread-safe. In the end, while it increased the frontend performance a bit, it made the backend run worse. Either the additional threads were stealing CPU time from the backend (which is potentially fixable), or the changes to the data structures were detrimental to the backend. I abandoned the effort, since at the time at least I didn't have any scenes were the frontend was a significant bottleneck compared to the backend.

  • Like 1
Link to comment
Share on other sites

27 minutes ago, cabalistic said:

I never tried - the frontend changes from BFG were too drastic. I did manage to parallelize some parts of the frontend, but it was a challenge to get the relevant data structures thread-safe. In the end, while it increased the frontend performance a bit, it made the backend run worse. Either the additional threads were stealing CPU time from the backend (which is potentially fixable), or the changes to the data structures were detrimental to the backend. I abandoned the effort, since at the time at least I didn't have any scenes were the frontend was a significant bottleneck compared to the backend.

Right

With gl_BasePointer and persistent mapping I start seeing front end bottle-necking around AddModels.

So I'm trying to route it via ParallelJobList and getting all these errors.

I already switched tri allocator from vanilla D3 thread-unsafe static allocator and tried synchronizing numDrawSurfs but it's still crashing with corrupt memory and even looped linked lists...

  • Like 1
Link to comment
Share on other sites

Well, here's a relevant commit that shows what I did in my last attempt: https://github.com/fholger/thedarkmod/commit/87880984c894fd2dd68ba87e8bf34785ff5eaf1c

Note, this is almost two years old, things may have changed. I also used TBB at the time instead of porting BFG job queues for easier development. You'll see that I had to replace a number of the allocators because they are inherently not thread-safe, and use atomics at several places. These are not light changes to be made; even though it worked fine in my tests, they may not be safe. That's another reason why I abandoned the effort.

  • Like 1
Link to comment
Share on other sites

5 minutes ago, cabalistic said:

Well, here's a relevant commit that shows what I did in my last attempt: https://github.com/fholger/thedarkmod/commit/87880984c894fd2dd68ba87e8bf34785ff5eaf1c

Note, this is almost two years old, things may have changed. I also used TBB at the time instead of porting BFG job queues for easier development. You'll see that I had to replace a number of the allocators because they are inherently not thread-safe, and use atomics at several places. These are not light changes to be made; even though it worked fine in my tests, they may not be safe. That's another reason why I abandoned the effort.

That commit has a rather different scope. It deals with lights and interactions while my focus is on adding ambient models

  • Like 1
Link to comment
Share on other sites

On 10/3/2019 at 12:56 PM, cabalistic said:

Yeah, but I have a feeling the challenges will be similar in some regards. Also, light interaction is one of the highest-scoring functions in the profiler from the frontend.

You might want to check out the current trunk. Got about 15% fps increase with parrallel jobs and add-models.

Yeah, it's buggy right now, but with enough critical section hunting I hope to find and fix it.

  • Like 1
Link to comment
Share on other sites

According to AppVeyor:

c:\projects\thedarkmod\typeinfo\main.cpp(203): error C2143: syntax error: missing ';' before '*' [C:\projects\thedarkmod\typeinfo.vcxproj]
c:\projects\thedarkmod\typeinfo\main.cpp(203): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int [C:\projects\thedarkmod\typeinfo.vcxproj]
c:\projects\thedarkmod\typeinfo\main.cpp(203): error C2065: 'MAX_THREADS': undeclared identifier [C:\projects\thedarkmod\typeinfo.vcxproj]
c:\projects\thedarkmod\typeinfo\main.cpp(206): error C2061: syntax error: identifier 'xthreadInfo' [C:\projects\thedarkmod\typeinfo.vcxproj]
c:\projects\thedarkmod\typeinfo\main.cpp(207): error C2065: 'info': undeclared identifier [C:\projects\thedarkmod\typeinfo.vcxproj]
c:\projects\thedarkmod\typeinfo\main.cpp(207): error C2182: 'Sys_DestroyThread': illegal use of type 'void' [C:\projects\thedarkmod\typeinfo.vcxproj]
c:\projects\thedarkmod\typeinfo\main.cpp(207): error C2365: 'Sys_DestroyThread': redefinition; previous definition was 'function' [C:\projects\thedarkmod\typeinfo.vcxproj]
  c:\projects\thedarkmod\idlib\sys\sys_threading.h(208): note: see declaration of 'Sys_DestroyThread'
c:\projects\thedarkmod\typeinfo\main.cpp(207): error C2448: 'Sys_DestroyThread': function-style initializer appears to be a function definition [C:\projects\thedarkmod\typeinfo.vcxproj]

I think there were additional errors, but this is the first one AppVeyor stumbles over. Also, on Linux:

[ 27%] Building CXX object CMakeFiles/TheDarkMod.dir/idlib/Thread.cpp.o
/home/appveyor/projects/thedarkmod/idlib/Thread.cpp: In static member function ‘static int idSysThread::ThreadProc(idSysThread*)’:
/home/appveyor/projects/thedarkmod/idlib/Thread.cpp:218:3: error: ‘_exit’ was not declared in this scope
   _exit( 0 );
   ^~~~~
/home/appveyor/projects/thedarkmod/idlib/Thread.cpp:218:3: note: suggested alternative: ‘_Exit’
   _exit( 0 );
   ^~~~~
   _Exit

 

  • Like 1
Link to comment
Share on other sites

4 minutes ago, cabalistic said:

According to AppVeyor:


c:\projects\thedarkmod\typeinfo\main.cpp(203): error C2143: syntax error: missing ';' before '*' [C:\projects\thedarkmod\typeinfo.vcxproj]
c:\projects\thedarkmod\typeinfo\main.cpp(203): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int [C:\projects\thedarkmod\typeinfo.vcxproj]
c:\projects\thedarkmod\typeinfo\main.cpp(203): error C2065: 'MAX_THREADS': undeclared identifier [C:\projects\thedarkmod\typeinfo.vcxproj]
c:\projects\thedarkmod\typeinfo\main.cpp(206): error C2061: syntax error: identifier 'xthreadInfo' [C:\projects\thedarkmod\typeinfo.vcxproj]
c:\projects\thedarkmod\typeinfo\main.cpp(207): error C2065: 'info': undeclared identifier [C:\projects\thedarkmod\typeinfo.vcxproj]
c:\projects\thedarkmod\typeinfo\main.cpp(207): error C2182: 'Sys_DestroyThread': illegal use of type 'void' [C:\projects\thedarkmod\typeinfo.vcxproj]
c:\projects\thedarkmod\typeinfo\main.cpp(207): error C2365: 'Sys_DestroyThread': redefinition; previous definition was 'function' [C:\projects\thedarkmod\typeinfo.vcxproj]
  c:\projects\thedarkmod\idlib\sys\sys_threading.h(208): note: see declaration of 'Sys_DestroyThread'
c:\projects\thedarkmod\typeinfo\main.cpp(207): error C2448: 'Sys_DestroyThread': function-style initializer appears to be a function definition [C:\projects\thedarkmod\typeinfo.vcxproj]

I think there were additional errors, but this is the first one AppVeyor stumbles over. Also, on Linux:


[ 27%] Building CXX object CMakeFiles/TheDarkMod.dir/idlib/Thread.cpp.o
/home/appveyor/projects/thedarkmod/idlib/Thread.cpp: In static member function ‘static int idSysThread::ThreadProc(idSysThread*)’:
/home/appveyor/projects/thedarkmod/idlib/Thread.cpp:218:3: error: ‘_exit’ was not declared in this scope
   _exit( 0 );
   ^~~~~
/home/appveyor/projects/thedarkmod/idlib/Thread.cpp:218:3: note: suggested alternative: ‘_Exit’
   _exit( 0 );
   ^~~~~
   _Exit

 

Do we still need TypeInfo for anything? If so I would like to know if I'm missing on something useful.

The other error is something I can't grasp. Is it a cmake project? Do you build it with scons or??

  • Like 1
Link to comment
Share on other sites

Sorry, yes, I'm working on a CMake build system. It was just the first result from AppVeyor I found, wasn't intentional. Are you saying idlib/Thread.cpp should not be compiled on Linux? If so, it's my mistake. Otherwise it has nothing to do with CMake...

  • Like 1
Link to comment
Share on other sites

20 minutes ago, cabalistic said:

Sorry, yes, I'm working on a CMake build system. It was just the first result from AppVeyor I found, wasn't intentional. Are you saying idlib/Thread.cpp should not be compiled on Linux? If so, it's my mistake. Otherwise it has nothing to do with CMake...

No, it should, but it seems to compile with 'default' scons command. I'm rather clueless when it comes to these command -line tools.

  • Like 1
Link to comment
Share on other sites

Imho, your code should not rely on the precompiled header to function correctly, it's just a compile speed improvement. In fact, not every file currently even includes the precompiled header - on MSVC it is auto-included in every file, but with SCons precompiled headers are not used and not auto-included, and that's one of the reasons why these kinds of missing headers regularly crop up in the Linux build :)

(My CMake build does use precompiled headers even with GCC, which significantly speeds up compile times and is more on par with the MSVC build.)

  • Like 1
Link to comment
Share on other sites

1 hour ago, cabalistic said:

Imho, your code should not rely on the precompiled header to function correctly, it's just a compile speed improvement. In fact, not every file currently even includes the precompiled header - on MSVC it is auto-included in every file, but with SCons precompiled headers are not used and not auto-included, and that's one of the reasons why these kinds of missing headers regularly crop up in the Linux build :)

(My CMake build does use precompiled headers even with GCC, which significantly speeds up compile times and is more on par with the MSVC build.)

Could you offer any advice on how to make scons use precompiled headers as well? It takes forever to compile.

  • Like 1
Link to comment
Share on other sites

I got no clue. As far as I know, SCons does not directly support it, so you'd have to hack it in, somehow. I had to do the same in CMake (their native support for precompiled headers will only be available in an upcoming version), but I'm not knowledgable enough about SCons to repeat the feat. Nor would I want to - I'd rather replace SCons with CMake entirely.

  • Like 1
Link to comment
Share on other sites

I started on multi draw calls again. I think you did that in VR branch already.

My problem: most surfaces have different model matrices. In my test only 10% of depth pass surfaces are in the world space. Simply calling MultiDrawElements does not handle that.

For that reason now I just only redirect the world space surfaces to multi draw.

What do you think is the best approach here? Uniform buffers for matrices? Would take quite an effort to generate it. Also, not sure of buffer upload overhead compared to more draw calls.

Grouping surfaces by space? How many draw calls would we save considering many entities have only one or few surfaces?

Link to comment
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.


  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 1 reply
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...