Jump to content
The Dark Mod Forums

I'm working on a VR version - early alpha


cabalistic

Recommended Posts

Yes, but the structure has implications for both. For example, the backend spends a noticable amount of time binding vertex buffers, which the BFG edition doesn't have to, afaict. As such, I believe that the BFG version lowers costs for both frontend and backend, which is exactly what we'd need at this point.

If only someone could just switch our system to one big vertex buffer...

  • Like 1
Link to comment
Share on other sites

Original:

 

https://pastebin.com/rHrwP0nA

 

Revelator's first relay of it:

 

http://forums.thedarkmod.com/topic/15178-tdm-engine-development-page/page-25?p=358097&do=findComment&comment=358097

 

he also has a hybrid BFG\Vanilla with some of these changes:

 

https://github.com/revelator/Revelation

 

Pat Raynor's hybrid BFG\Vanilla version also uses mapBufferRange:

 

https://github.com/raynorpat/Doom3

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

Link to comment
Share on other sites

@nbohr1more: I was now able to reproduce the visual artifacts you reported on an older PC with an older Nvidia card :(

Unfortunately, I don't normally have access to this PC, so unless I accidentally find the root cause tonight, it's still going to be tricky to debug this since it's just not happening on my primary dev machine.

 

Evidently, this needs more testing. I'd really appreciate some more people try out the build (you don't need a VR device) and report any problems along with their hardware. There are clearly some issues left.

  • Like 2
Link to comment
Share on other sites

@nbohr1more: I was now able to reproduce the visual artifacts you reported on an older PC with an older Nvidia card :(

Unfortunately, I don't normally have access to this PC, so unless I accidentally find the root cause tonight, it's still going to be tricky to debug this since it's just not happening on my primary dev machine.

 

Evidently, this needs more testing. I'd really appreciate some more people try out the build (you don't need a VR device) and report any problems along with their hardware. There are clearly some issues left.

You should now have full svn access?

Could you add a switch to toggle SMP on and off?

  • Like 1
Link to comment
Share on other sites

To my knowledge, you should now have full SVN access.

 

I understand that it's not your preferred workflow but the "TDM team" does test changes in SVN and then when the 2.06 beta begins

the assets will be made available to "beta testers". (We could possibly consider a 2.06 alpha as well to gather more testers.)

 

Don't get me wrong, I wholly agree that we should offer assets to accompany our read-only developer SVN access so

that outside developers can more easily integrate their work.

 

I think it's time to start another big internal argument about that soonish... ;)

  • Like 3

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

Link to comment
Share on other sites

I was able to make the Problem disappear by ensuring that Frontend and Backend run after one another, but still in separate threads. So the use of vbo on the other thread is not in itself a Problem. It appears there is still a genuine race condition, with the Frontend manipulating something that is used in the back. Just wondering why I can't reproduce it on my dev machine.

 

I do habe a work laptop with a 960M, I'll try if it happens there.

  • Like 1
Link to comment
Share on other sites

 

 

Thank you. I'm not sure if logging is on. Perhaps you can tell by the contents of my log file, which are as follows:

 

[game\DarkModGlobals.cpp ( 362):INI (INIT) FR: 0] LogFile created at 2017.08.08 21:03:23
[game\DarkModGlobals.cpp ( 365):INI (INIT) FR: 0] DLL last cleaned and rebuilt on Jul 23 2017 11:13:21
[game\DarkModGlobals.cpp ( 367):INI (INIT) FR: 0] The Dark Mod 2.05, code revision 6757
[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogBegin: 0
[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogEnd: 0
[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogInfo: 0
[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogDebug: 0
[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogWarning: 0
[game\DarkModGlobals.cpp ( 408):FRC (FORCE) FR: 0] LogError: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_FRAME: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_SYSTEM: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_MISC: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_FROBBING: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_AI: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_SOUND: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_FUNCTION: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_ENTITY: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_INVENTORY: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_LIGHT: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_WEAPON: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_MATH: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_MOVEMENT: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_STIM_RESPONSE: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_OBJECTIVES: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_DIFFICULTY: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_CONVERSATION: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_MAINMENU: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_LOCKPICK: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_AAS: 0
[game\DarkModGlobals.cpp ( 418):FRC (FORCE) FR: 0] LogClass_STATE: 0

 

 

For system crashes, turn 0's to 1's since I'm not sure what's causing your crash.

It might make TDM run slower, but this is only temporary. Once the game crashes, post the darkmod.log file here.

Sorry for the late reply.

  • Like 1

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

I was able to make the Problem disappear by ensuring that Frontend and Backend run after one another, but still in separate threads. So the use of vbo on the other thread is not in itself a Problem. It appears there is still a genuine race condition, with the Frontend manipulating something that is used in the back. Just wondering why I can't reproduce it on my dev machine.

 

I do habe a work laptop with a 960M, I'll try if it happens there.

 

LOL you and John Carmack

 

 

John Carmack - This was explicitly to support dual processor systems. It worked well on my dev system, but it never seemed stable enough in broad use, so we backed off from it. Interestingly, we only just found out last year why it was problematic (the same thing applied to Rage’s r_useSMP option, which we had to disable on the PC) – on windows, OpenGL can only safely draw to a window that was created by the same thread. We created the window on the launch thread, but then did all the rendering on a separate render thread. It would be nice if doing this just failed with a clear error, but instead it works on some systems and randomly fails on others for no apparent reason.

  • Like 1

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

Ok, so I can also reproduce the issue on my laptop, so I do have a device to debug with.

Also, in fullscreen at an increased resolution, I finally managed to see a glimpse of the issue also on my dev machine. Only for a second or so, but it was there. So this is definitely a general issue, which is a relief. For some reason, the GTX1070 is much more stable against it than the GTX960, but still.

Unfortunately, concurrent race conditions are still tricky to debug, but hopefully I can track it down now that I've seen it for myself.

 

@nbohr1more: I did not receive any credentials for SVN. So even if there exists an account for me with access, I still can't access it :)

Edited by cabalistic
  • Like 2
Link to comment
Share on other sites

@nbohr1more: I think I fixed the problem. Can you try the new build? https://github.com/fholger/thedarkmodvr/releases/tag/v0.1.2

The problem was that the GL buffers filled in the frontend thread needed to be synced properly before the backend attempts to render them. Doing a glFlush (as I did) is not sufficient and can lead to the very artifacts we observed, depending on how fast the GPU is compared to the CPU.

 

The fix is to either use a full glFinish (which is expensive, takes a lot of time), or use a fence sync. However, the latter is only available in OpenGL 3.2 (which is 8 years old, give or take). I don't know where The Dark Mod stands on backwards compatibility? What is your intended minimum specs?

If we want to modernize the engine further (which I very much would like to attempt to help with), it's probably good to decide the targeted OpenGL version upfront.

 

In any case, I've decided to put development of the VR mod on hold for now. I feel the engine still needs another significant performance improvement for VR to truly be viable, so I'd like to concentrate on that first. There are some obvious candidates for improvements we should backport from Doom3 BFG, namely glMapBuffer, GPU skinning and others. I don't know how feasible it is or how much work it actually requires, but I'm willing to give it a shot. But these changes really need to happen to the SVN version, so that's why I'm abandoning my VR branch for now.

  • Like 2
Link to comment
Share on other sites

@nbohr1more: I think I fixed the problem. Can you try the new build? https://github.com/fholger/thedarkmodvr/releases/tag/v0.1.2

The problem was that the GL buffers filled in the frontend thread needed to be synced properly before the backend attempts to render them. Doing a glFlush (as I did) is not sufficient and can lead to the very artifacts we observed, depending on how fast the GPU is compared to the CPU.

 

The fix is to either use a full glFinish (which is expensive, takes a lot of time), or use a fence sync. However, the latter is only available in OpenGL 3.2 (which is 8 years old, give or take). I don't know where The Dark Mod stands on backwards compatibility? What is your intended minimum specs?

If we want to modernize the engine further (which I very much would like to attempt to help with), it's probably good to decide the targeted OpenGL version upfront.

 

In any case, I've decided to put development of the VR mod on hold for now. I feel the engine still needs another significant performance improvement for VR to truly be viable, so I'd like to concentrate on that first. There are some obvious candidates for improvements we should backport from Doom3 BFG, namely glMapBuffer, GPU skinning and others. I don't know how feasible it is or how much work it actually requires, but I'm willing to give it a shot. But these changes really need to happen to the SVN version, so that's why I'm abandoning my VR branch for now.

I would try glMapBuffer + ring pointer writes

Configurable buffer size would allow for 3+ frames of geometry.

Link to comment
Share on other sites

But you have to unmap it for the backend to actually render it. I think the BFG approach of having two buffers and swapping them between each frame is the more viable approach.

 

In any case, this only works for the frame-allocated buffers. Currently, the engine also creates a lot of static objects dynamically in the frontend, which BFG got rid of. That might be a more substantial rewrite, though.

  • Like 2
Link to comment
Share on other sites

Hmm. I guess if you want to go older than OpenGL 3.2, ATI\AMD support NV_fence going back to Radeon 9200

 

http://feedback.wildfiregames.com/report/opengl/feature/GL_NV_fence

 

https://www.khronos.org/registry/OpenGL/extensions/NV/NV_fence.txt

 

Or do a GL version check and do either depending...

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

Link to comment
Share on other sites

@nbohr1more: I think I fixed the problem. Can you try the new build? https://github.com/fholger/thedarkmodvr/releases/tag/v0.1.2

The problem was that the GL buffers filled in the frontend thread needed to be synced properly before the backend attempts to render them. Doing a glFlush (as I did) is not sufficient and can lead to the very artifacts we observed, depending on how fast the GPU is compared to the CPU.

 

The fix is to either use a full glFinish (which is expensive, takes a lot of time), or use a fence sync. However, the latter is only available in OpenGL 3.2 (which is 8 years old, give or take). I don't know where The Dark Mod stands on backwards compatibility? What is your intended minimum specs?

If we want to modernize the engine further (which I very much would like to attempt to help with), it's probably good to decide the targeted OpenGL version upfront.

 

In any case, I've decided to put development of the VR mod on hold for now. I feel the engine still needs another significant performance improvement for VR to truly be viable, so I'd like to concentrate on that first. There are some obvious candidates for improvements we should backport from Doom3 BFG, namely glMapBuffer, GPU skinning and others. I don't know how feasible it is or how much work it actually requires, but I'm willing to give it a shot. But these changes really need to happen to the SVN version, so that's why I'm abandoning my VR branch for now.

 

Yes, this build has solved the problem! :)

 

I can now max out tdm_lg_split and tdm_lg_interleave and really open up the FPS here.

 

Edit:

 

Well... 99%of the problem. The skybox in Briarwood Manor flickers when I set tdm_lg_interleave > 1. tdm_lg_split 1 still works though.

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

Link to comment
Share on other sites

The fix is to either use a full glFinish (which is expensive, takes a lot of time), or use a fence sync. However, the latter is only available in OpenGL 3.2 (which is 8 years old, give or take). I don't know where The Dark Mod stands on backwards compatibility? What is your intended minimum specs?

If we want to modernize the engine further (which I very much would like to attempt to help with), it's probably good to decide the targeted OpenGL version upfront.

 

I think the current approach with OpenGL is: we use something very old like version 2.1, and we enable extensions for anything relatively modern (like e.g. framebuffer).

If you need a fence, there is no problem in using it via GL extension.

Just make sure that when cvar for multithreaded rendering is disabled (I hope it is already present in the code?), this extension is not required. In such case people with old video card can still play the game without issues.

Link to comment
Share on other sites

 

I think the current approach with OpenGL is: we use something very old like version 2.1, and we enable extensions for anything relatively modern (like e.g. framebuffer).

If you need a fence, there is no problem in using it via GL extension.

Just make sure that when cvar for multithreaded rendering is disabled (I hope it is already present in the code?), this extension is not required. In such case people with old video card can still play the game without issues.

Can't see why support 2.1 when everyone is on DX10 hardware these days: http://store.steampowered.com/hwsurvey/videocard/.

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  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • 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.
      · 4 replies
    • 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
×
×
  • Create New...