Jump to content
The Dark Mod Forums

Performance issues on Linux


Ciordeala
 Share

Recommended Posts

I have recently installed this on Linux Mint 20.3 and I am getting performance issues, namely the frame rate is choppy. It's still playable, but it is uncomfortable to play for too long because of the choppy visuals. I have tried lowering the graphical settings but no matter how high or low I set them I get the same result. I also have the official nvidia driver installed.

On the same machine I have a Windows 7 install and it runs perfectly smooth there, so I know it's not an issue of inadequate hardware. I know I could just boot into Windows and play it but I would have preferred if I could play it on Linux since that is my main OS on this PC.

Any ideas?

Link to comment
Share on other sites

What drivers do you have installed ?

What GPU and CPU models ?

Do you have FPS set to uncapped ( huge improvement to smoothness even when below 60 FPS )?

Is vsync set to adaptive or off ?

  • Thanks 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

I seem to remember having this issue too. It's strange but the built-in FPS cap doesn't seem to work well on Linux. Perhaps there is some low-level problem determining the correct FPS from the X window system (or Wayland if you're using it).

Link to comment
Share on other sites

Something about Doom 3's FPS cap method is incompatible with modern drivers and accelerated desktop render techniques.

Capping FPS should make GPU resources available for the next frame so it should make things smoother when you are near or slightly above 60 FPS. Instead, it can steal as much as half the FPS performance even in pretty light scenes.

Setting uncapped FPS increases performance even if you use the "new" Max FPS cap that TDM uses and set it to 60.

We should probably default to uncapped FPS with max fps set to 60 and leave the old Doom 3 cap method as a developer cvar.

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 think what happens is that the old method caps the framerate at just slightly below 60 fps - which means that in combination with VSync (either enabled in the game or forced by the compositor) will drop the framerate to 30 fps most of the time.

  • Like 2
Link to comment
Share on other sites

5 hours ago, OrbWeaver said:

I seem to remember having this issue too. It's strange but the built-in FPS cap doesn't seem to work well on Linux. Perhaps there is some low-level problem determining the correct FPS from the X window system (or Wayland if you're using it).

There is platform-specific piece of code which creates OS timer that wakes up every so often and bumps "tic number".
This code is completely different on Windows and Linux. Perhaps Linux code is just bad in some way.

Link to comment
Share on other sites

Yeah, having a completely independent timer seems like a recipe for desychronisation problems.

Probably what I'd do is:

  1. If the display frame rate is less than or equal to the cap value, just enable vsync and don't do any manual synchronisation — it's not adding any value beyond what vsync does naturally.
  2. If the display frame rate is greater than the cap:
    1. After a frame is actually displayed (i.e. vsync is completed and the buffer swap has happened), store the current time in a variable.
    2. When the next frame is ready to be shown, compare the current time with the value stored in the previous step. If not enough time has elapsed, pause for the required number of milliseconds (or slightly less) before displaying the next frame.

Of course this assumes that there are suitable platform-specific methods to obtain the actual display frame rate. I can imagine this might be problematic on Linux given there are two different display servers and several desktop compositors in use.

Perhaps the quick and dirty solution on Linux is just to enable vsync by default, then disable the frame rate cap by default (since vsync will take care of it)?

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.

 Share

  • Recent Status Updates

    • nbohr1more

      Anyone have any luck with light.setShader( string ) ? It seems to make whichever light you apply it to full-bright on the initial invoke?
      · 0 replies
    • thebigh

      I'm starting to think we need another mapping contest.
      · 9 replies
    • kano

      Don't you hate it when there's a quality discussion on a forum somewhere online about something, but then two disagreeing users derail and transform it into a back-and-forth poo slinging competition at one another?
      · 9 replies
    • Diego

      Oh look the status updates are back! 
      · 2 replies
    • JackFarmer

      After watching the first three and a half episodes of "The Sandman" last night, I realize once again that overly imaginative narratives are not for me. Also, the main actor looks like he has a toothache.
      Which makes me wonder, is there a Dark Mod mission with a medieval dentist?
      · 4 replies
×
×
  • Create New...