Jump to content
The Dark Mod Forums

Recommended Posts

Posted

I guess I'll need to double-check that the vertexcache changes don't break shadow mapping.

Don't worry about shadow maps, I will look into that myself after trunk merge

...

Trunk shows no change in fps with glgeterror skipped on AMD. Will clone your git and give it a try.

...

First impressions: buttons in the main menu flickering when hovering mouse over them?

...

Rightful Property won't load - stuck somewhere in image load.

  • Like 1
Posted

So, I've got a puzzle for you. I experimented some more with parallelization and made some experimental changes to call AddActiveInteraction in R_AddModelSurfaces in parallel or serially depending on a cvar switch. In each case I timed how long it takes. I can clearly see the times go down with the parallel version, yet the time the frontend takes in total hardly changes at all. Goes down slightly in some maps, actually seems to rise in others. Really don't get it. :(

  • Like 1
Posted (edited)

Actually, never mind. The scenes I was just testing that were strongly frontend-limited yesterday or suddenly backend-limited, so that's why I see no improvements. Something strange is going on with those backend timings, I don't get it.

 

Edit: So it seems Afterburner is another thing that somehow eats time on the backend. Very weird...

Edited by cabalistic
  • Like 1
Posted

Some more careful timing analysis shows that the frontend time does indeed go down in the multithreading scenario. However, the time between two frames (i.e. after backend and frontend finish and until they start again) suddenly increases and eats up any time savings.

 

I investigated more closely, and what suddenly takes a lot more time is unmapping the vertex caches. If I move that inside the backend, then some other operations still seem to block. My current hypothesis is that even though the backend seemingly finishes early, the GL backend is actually still working. And the next (blocking) GL call thus has to wait. So my seemingly amazing savings after commenting out glGetError might just have been hiding the true backend costs, because that way the backend was waiting for frontend instead of GL...

 

At this point it's still an open question whether I can turn the multithreading savings into something tangible.

  • Like 1
Posted

Intel test (github repo)

Map loads - whew!

Fps is lower than trunk - 36 vs 46.

Second load aborts with error: Not all interactions removed.

This was with the last commit before TBB addition.

Ignore gl errors shows no impact on fps to me.

Console quit hangs in idSessionLocal::WaitForFrontendCompletion

  • Like 1
Posted

Interesting - and disappointing. Thanks for testing. Was this on Rightful Property? What settings did you use for shadows etc.? There's also a commented line in RenderWorld.cpp:1498 that you might try to enable. It pregenerates some of the static interactions and might take some load of the system, but it causes problems with savegames I haven't yet tracked down.

 

As for the error, I'll have to look into that. Might be some missing cleanups, or just an oversight with the new interactionTable.

  • Like 1
Posted

So I just tested this with the two devices I have with Intel graphics.One is my work notebook (it's technically an Optimus hybrid of onboard Intel 530 and a GTX960m), the other is my GPD Win (Intel Atom with onboard graphics).

 

First of all, I cannot reproduce any framerate drops in Rightful Property. The GPD Win goes from 19-20 fps to 21-23 fps. The notebook stays just under 50 fps in both cases. Looking at the logs (r_logSmpTimings), I can see a fairly significant reduction in frontend drawing duration on the notebook, which does not increase the frame rate because the backend stays the same and limits it.

 

Unfortunately, the notebook also shows some serious graphical artifacts with the vertexcache version. I tried different versions of the Intel driver to no avail. The GPD Win is fine. The Nvidia card on the notebook is also fine.

 

You did not see any visual artifacts, right? They were fairly noticable, so you'd probably have mentioned them. As for the performance, can you give me more information about the graphical settings you are using? Resolution, AA etc. as well as shadow maps or stencil, ... And what build are you using, release x86 or x64?

 

I'm not sure where to go from here. If the changes cause performance drops or even visual artifacts on some machines, then I'm not sure we want to apply them. But I don't really have a clue how to fix either.

  • Like 1
  • 2 months later...
Posted

So glad to head that! I would think minimizing the CPU bottleneck would be the key to TDM's performance in VR, since that seems to be where it already is in standard TDM. Best of luck in your endeavours and I can't wait to one day jump into TDM-VR!

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

 

 

 

Posted

Great to hear the initial alpha is finding some use :)

Just to manage expectations, though: due to current time constraints, it's unlikely that any new release will be ready before May, and that will still be a seated version. So please be patient with me :)

  • Like 3
  • 3 weeks later...
  • 2 weeks later...
Posted

Just thought to chime in, thank you for working on this, I have a rift my end too and look forward to giving this a whirl!

  • Like 1
  • 2 months later...
Posted

I'm afraid the currently released version is not compatible with 2.06. At the very least, the executable is still on 2.05 code and probably won't play well with 2.06 assets.

 

I have ported my modifications to 2.06 and continue to work on it, but it's currently not in a state ready to be released, sorry.

  • Like 1
Posted

I'm afraid the currently released version is not compatible with 2.06. At the very least, the executable is still on 2.05 code and probably won't play well with 2.06 assets.

 

I have ported my modifications to 2.06 and continue to work on it, but it's currently not in a state ready to be released, sorry.

 

No worries at all! I'll just keep from updating for the time being. Thanks for the quick reply.

  • 3 weeks later...
Posted

Decided to give this another shot and it still doesn't launch in VR. SteamVR just sits there showing me the room and tdm runs on the screen. I even tried creating a steam shortcut for TDM with "run in VR" option.

 

Get to work, cabalistic! work for my entertainment! *cracks whip*

 

In all seriousness I'm always baffled by my incompetence when it comes to all technical things in TDM.

Posted

First things first sorry if these are too primitive:

 

1) Do you have a 2.05 installation of TDM? It may not run on a 2.06 installation.

2) Are you starting the right executable? (TheDarkMod.exe from the 0.1.3 release)

3) Did you put 'vr_enable 1' in your autoexec.cfg?

  • Like 1
Posted

Yup. And if I pull the console during gameplay and check for the vr_enable it says it's 1.

 

This executable is the normal one from installation, right?

 

I have my suspicions that steamvr might be the one not playing along. It's known to be difficult.

  • 4 weeks later...
Posted

Hi guys - if there's anything I can do to help with the VR implementation let me know. ( I'm the D3BFG Fully Possessed VR mod dev )

 

I know you're working on engine optimizations now, and most of the work I've done is on the BFG engine so isn't directly compatible, but I'm happy to lend a hand if I can.

  • Like 4
Posted

Hey, thanks for the offer! I studied your code when I attempted my initial VR modifications. Even though it wasn't directly applicable, it certainly helped to guide me in the right direction :)

 

I'm currently working on a small FBO overhaul for the renderer. After that, I need to port the VR mod to the latest sources. Unfortunately, that may still take a while, but after that's done, there's more than enough work to share :) The most pressing would be to make the UI and HUD VR-friendly. And then, of course, going for actual room-scale and controller input.

  • Like 3

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

    • JackFarmer

      "The Year of the Rat." 
      😄

      Al Stewart must be proud of you!
      Happy testing!
      @MirceaKitsune
      · 1 reply
    • datiswous

      I posted about it before, but I think the default tdm logo video looks outdated. For a (i.m.o.) better looking version, you can download the pk4 attached to this post and plonk it in your tdm root folder. Every mission that starts with the tdm logo then starts with the better looking one. Try for example mission COS1 Pearls and Swine.
      tdm_logo_video.pk4
      · 2 replies
    • JackFarmer

      Kill the bots! (see the "Who is online" bar)
      · 3 replies
    • STiFU

      I finished DOOM - The Dark Ages the other day. It is a decent shooter, but not as great as its predecessors, especially because of the soundtrack.
      · 5 replies
    • JackFarmer

      What do you know about a 40 degree day?
      @demagogue
      · 4 replies
×
×
  • Create New...