We do often include affiliate links to earn us some pennies. See more here.

Tweaking Performance in XCOM 2

By -
When Firaxis chose to use Unreal Engine to power their latest title, XCOM 2, they chose to stay on the older version 3 of the engine instead of the latest, and fully Linux-compatible, version 4. It seems that when they brought XCOM: Enemy Unknown to the masses, they'd hacked that version 3 engine so much, it was practically an entirely new fork. Porting all their customisations to the newer engine would have been daunting, so they decided to stick with that customised engine for XCOM2.

However, this has brought some hangovers from that earlier version with it, hangovers that Feral left in place during the porting. In particular, many titles using UE3 suffer from an extremely low default memory allocation. In fact, the default PoolSize is set at just 10Mb, and I suspect that Feral have to leave it that way to ensure maximum compatibility. In fact, besides Poolsize, you can tweak quite a few settings in your game's ini file, but as usual, it appears that PoolSize is the primary factor in smoothing out the performance. Original credit to this tester for Unreal Engine 3 here from 2013, regarding the original XCOM game.

Having tried these changes myself, I can report that performance leapt from "frustrating and shoddy" to "entirely playable". There is still a little stutter evident in the loading transitions while in the dropship, but in-game performance is definitely a huge improvement. I'd go as far as to use the phrase "buttery smooth". No more slide-show explosions, or missed action-shots.

Here's what you can do.

Important Note: We suggest reverting these changes for any patches that come, as it could affect them. Always revert changes like this when a patch is released.

Before making any changes, you might want to make a copy of your file, then you'll need to open it for editing:

cd ~/.local/share/feral-interactive/XCOM2/VFS/Local/my\ games/XCOM2/XComGame/Config
cp XComEngine.ini XComEngine.ini.original
gedit XComEngine.ini


And then find the PoolSize=10 line and change it to something more reasonable, such as 256.

If you just want the quick fix, you can skip this section, however as the more detailed article points out, you might want to change the following lines too. I did, but it's not entirely clear how much they contribute. Feel free to experiment!


MipFadeInSpeed0=0
MipFadeOutSpeed0=0
MipFadeInSpeed1=0
MipFadeOutSpeed1=0
MinSmoothedFrameRate=30
MaxSmoothedFrameRate=400
bInitializeShadersOnDemand=True
DisableATITextureFilterOptimizationChecks=False
UseMinimalNVIDIADriverShaderOptimization=False
PoolSize=256 (or VideoRAM/4, up to 768 max)
bAllowMultiThreadedShaderCompile=True
ThreadedShaderCompileThreshold=4 (match your CPU cores, so an i3=2, while i5 or i7=4)
OnlyStreamInTextures=True


Having made the changes, the first thing that XCOM 2 tries to do is set it all back to default values again, so you'll need to mark that file read-only:


chattr +i XComEngine.ini


(actually, you might want to make that change with sudo so that root owns the file, preventing XCOM 2 from changing it back - some users reported that XCOM 2 does indeed "undo" the read-only flag!)

And that should be the game fixed up for immediate play!

As always, there are a lot of systems out there that will handle these changes differently, so your mileage may vary. Remember to mark the file read-only before playing and if you still don't see a change, try the "reset to defaults" trick mentioned in the original source article.

For reference, my system specs are:

O/S: Ubuntu 14.04 64bit
GPU: Nvidia GTX670, 2Gb
Chip: Intel i7 2600k
RAM: 16Gb

I used the 256Mb PoolSize as shown above, but could have gone 512Mb, as the original source article suggested "GPU memory divided by four". I used the ShaderThreshold 4 as shown above.

If you don't know your video memory, you have two options. If you're using Nvidia, you can simply run the Nvidia XServer Settings GUI (and I think Catalyst drivers might have a similar option actually). Otherwise, you can run:


dmesg | grep VRAM


That will hopefully show you how much RAM your computer detected on start up.

Good luck, Commander! Article taken from GamingOnLinux.com.
0 Likes
About the author -
author picture
I'm Neil, an avid Linux user since 2006 and a Linux-only gamer since 2013. I used to contribute to GOL's Funding Crowd articles, but now contribute the odd article directly, most recently the Play It Now series, and the IYL articles.

I also occasionally dabble a bit in Python, I do Internet Security for a living and finally, I'm a big fan of Neil Degrasse Tyson. And not just because he has a cool first name.
See more from me
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
30 comments
Page: «2/2
  Go to:

[email protected] Feb 10, 2016
It seems my script can do the job for you ;)
https://github.com/Kryuko/ue3_linux_opti
Tuxee Feb 10, 2016
WTF? Changed XComEngine.ini to bigger pool size and ThreadedShaderCompileThreshold to 2. chown'ed the file to root:root and gave it a 0755. Guess what? It got both reowned by the "me" and chmod'ed to 0770 again. How can that be? Any suggestions?
Anyway, contrary to the article my settings were not reverted - pool size is still 512 and the compile threshold still 2.

The only way that should be possible is if you're running Steam as root, which would (obviously) be a terrible idea. Beyond that possibility, you have a serious flaw on your box if you're seeing root-owned files being chowned by non-root processes...

Did the game improve for you though? That's the most important thing. :D

It did improve. And the "WTF" was exclaimed for a reason. Steam and XCOM is of course running as "me" (and the overwritten file is again owned by "me" ). My box is actually a pretty well maintained 14.04 Ubuntu.

Audit lists two access sources to the file: "XCOM2" and "?" - the latter one presumably setting the permissions.


Last edited by Tuxee on 10 February 2016 at 1:31 pm UTC
Wildy Feb 10, 2016
WTF? Changed XComEngine.ini to bigger pool size and ThreadedShaderCompileThreshold to 2. chown'ed the file to root:root and gave it a 0755. Guess what? It got both reowned by the "me" and chmod'ed to 0770 again. How can that be? Any suggestions?
Anyway, contrary to the article my settings were not reverted - pool size is still 512 and the compile threshold still 2.

The only way that should be possible is if you're running Steam as root, which would (obviously) be a terrible idea. Beyond that possibility, you have a serious flaw on your box if you're seeing root-owned files being chowned by non-root processes...

Did the game improve for you though? That's the most important thing. :D

It did improve. And the "WTF" was exclaimed for a reason. Steam and XCOM is of course running as "me" (and the overwritten file is again owned by "me" ). My box is actually a pretty well maintained 14.04 Ubuntu.

Audit lists two access sources to the file: "XCOM2" and "?" - the latter one presumably setting the permissions.

The directory is writable by you which means its contents could get unlinked and recreated. chattr +i prevents this
Tuxee Feb 10, 2016
The directory is writable by you which means its contents could get unlinked and recreated. chattr +i prevents this

Sounds legit - didn't think about that.
NovenTheHero Feb 10, 2016
Wow this worked wonders for me.
DePingus Feb 11, 2016
WTF? Changed XComEngine.ini to bigger pool size and ThreadedShaderCompileThreshold to 2. chown'ed the file to root:root and gave it a 0755. Guess what? It got both reowned by the "me" and chmod'ed to 0770 again. How can that be? Any suggestions?
Anyway, contrary to the article my settings were not reverted - pool size is still 512 and the compile threshold still 2.

The only way that should be possible is if you're running Steam as root, which would (obviously) be a terrible idea. Beyond that possibility, you have a serious flaw on your box if you're seeing root-owned files being chowned by non-root processes...

Did the game improve for you though? That's the most important thing. :D

It did improve. And the "WTF" was exclaimed for a reason. Steam and XCOM is of course running as "me" (and the overwritten file is again owned by "me" ). My box is actually a pretty well maintained 14.04 Ubuntu.

Audit lists two access sources to the file: "XCOM2" and "?" - the latter one presumably setting the permissions.

The directory is writable by you which means its contents could get unlinked and recreated. chattr +i prevents this

I edited XComEngine.ini using sudo gedit instead of using chattr +i (like the article suggested) and left the editor opened. When I started the game gedit noticed the file had changed and asked me to reload it. I reloaded the file and the poolsize was still set to 512 (I didn't make any other changes), I guess gedit noticed xcom taking back ownership.


Last edited by DePingus on 11 February 2016 at 2:48 pm UTC
Wumpus Feb 12, 2016
And then find the PoolSize=10 line and change it to something more reasonable, such as 256.
Poolsize issues are quite common with the Feral ports (Spec Ops: The Line eg.), (1024/4=256>>10) ?

I thought Virtual Programming did Spec Ops? I don't think Feral had anything to do with it, unless they somehow did the Linux version only.
Scherbatsky Feb 12, 2016
Confirmed! Significant improvement with Ubuntu 14.04 LTS.
edddeduck_feral Feb 26, 2016
We’re happy to report that the 1.0.1 hot fix update for XCOM 2 (Mac/Linux) is now available. This update will automatically install when starting the Steam client. If it doesn’t automatically, restart Steam. This update includes all the fixes contained in the Windows hotfix released last week. Details of all the fixes are listed below.

Mac/Linux Fixes
* Player is unable to progress to scan in the Geoscape after completing the Resistance Communications research via Tutorial - This will fix previously affected saves.
* Unable to load saves with a Chryssalid Cocoon – This will fix the issue, and for previously affected saves.
* Using the preview voice button for a modded voice pack will no longer crash the game when in the armoury.
* Improvements to frame rate and in level hitching.
* Fixed issues with Mods not enabling on some machines
* Improved “Refresh” button behaviour in modding panel
* Fixed issue with Shen’s leg flickering
* Fixed issue when switching from Japanese to other languages.
* Various minor improvements.

Linux Specific Fixes
* Fixed rare corruption caused by LC_ALL flag in users .bashrc file
* Fixed discoloured pink/blue smoke on some Nvidia hardware
* Updated warnings for users using unsupported Nvidia drivers
* Fixed Red Lights above units in level on some Nvidia hardware
* Fixed conflict between depth of field and bloom on some Nvidia hardware
* Fixed crash on launch when VPN or other virtual networks are enabled.
* Fixed Fountains out of game area not correctly fogged

We will continue our patch support over the coming months with additional fixes and performance updates. If you have any issues or questions with the Mac/Linux hotfix please contact our support team via email [email protected] or go to our website http://support.feralinteractive.com

I HIGHLY RECOMMEND YOU BACK OUT ALL INI EDITS WHEN USING THIS UPDATE. We tuned the game engine to give the best performance which means the ini tweaks might now have a negative effect on some setups so I'd test the patch with no tweaks before messing with anything.
TheRiddick Jun 25, 2016
Got a problem on retaliation missions where FPS tanks to like 15fps or so. Anyone found a solution for this?


Last edited by TheRiddick on 25 June 2016 at 3:06 am UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.