Anonymous edits have been disabled on the wiki. If you want to contribute please login or create an account.


Warning for game developers: PCGamingWiki staff members will only ever reach out to you using the official press@pcgamingwiki.com mail address.
Be aware of scammers claiming to be representatives or affiliates of PCGamingWiki who promise a PCGW page for a game key.

Topic on Talk:Tom Clancy's Splinter Cell: Conviction

Markie (talkcontribs)

I've added a citation for the performance issues.

Those fixes added by someone are placebos:

1 - The CPU affinity fix: The game process already sets itself to every core available as it should, it just doesn't use more than 2 cores in reality due to engine limitations.

2 - The .ini fix: Those changes either do nothing or make the game more unstable.

I've added a disclaimer to the co-op 30 fps unlocker - "This fix lacks instructions and needs testing."

EDIT: Cleaned up some wording and formatting as well, and removed those generic/placebo fixes from the Issues fixed section.

Deton24 (talkcontribs)

Then there must be something else wrong with multithreading in this game. I highly doubt that you really use an ancient CPU, so you can notice any difference using Ragnos config, because it helped me a lot. Nothing else really made a difference to me, and I tried a lot of things, including affinity, which in fact, could be deleted because of varying results (if any). I only didn't test new culling value suggested by someone else here: https://www.pcgamingwiki.com/w/index.php?title=Topic:Vitczj1coqqjcrri&topic_showPostId=viy7nu4zwpz2pddt&fromnotif=1#flow-post-viy7nu4zwpz2pddt But its value was changed already by Ragnos in the config, but it was different. Previous config (the one above Ragnos) did nothing to me, but Ragnos would stay with the new culling value. The config forces low details as a downside, but performance was better vs stock low details if memory serves.

If you can, please leave alone Ragnos config with culling value. If you have anything against, please speak out further to investigate the issue further (with your specs at best). The old edit for reference: https://www.pcgamingwiki.com/w/index.php?title=Tom_Clancy%27s_Splinter_Cell:_Conviction&diff=1010533&oldid=1010472#Exceptionally_bad_performance_or_refusing_to_launch_on_some_AMD_GPUs

PS. Did you check DXVK? Just copy and paste all x32 libraries near exe. It might do the trick.

Markie (talkcontribs)

Ragnos' config file lowers down the entire set of graphical options the same way you could be doing through the in-game menu (plus a few other small tweaks that don't actually help such as the culling one in this particular case) so of course the game should run better. Forcing low graphical settings through an .ini file isn't really fixing anything so it's just a placebo. Try comparing it to the game with those same settings but set manually instead of by using his .ini file...

I have tried DXVK in Splinter Cell: Conviction, if memory serves me right the game either had errors and didn't launch at all of had severe lag because of it. Either way, it was made unplayable. DXVK isn't a magical solution either, it might help overriding API bottlenecks in certain games by replacing whatever API was in place originally, but it won't overcome deeper engine limitations such as the lack of multi-core support or other kinds of poor optimization.

Deton24 (talkcontribs)

Okay then. Maybe I'll try to retest the game to verify Ragnos config influence vs low settings, since I'm not entirely sure whether it was better than stock low, because it was a long time ago. Culling influence was verified by someone else. It might be hardware-dependant. Please notice that not everything is placebo because doesn't work for your configuration. That's why I wouldn't feel comfortably deleting similar entries anywhere and personally wouldn't recommend it. Just for sake of not making any contributor angry. Since then, maybe also DXVK version changed and will do some magic, but of course, it's not a cure for all evil like on Radeons in AC Origins.

Markie (talkcontribs)

I understand, I'm not going out calling anything a placebo. I have tested this game on multiple hardware configurations including different GPU vendors. Anyone can roll back changes I or someone else made and if there's a disagreement we have this discussion section for that. It would be nice to post some evidence or proof that tweaks and fixes such as those presented actually work though. As I've said, I went ahead and tested them and none helped so that's why I made the changes to the page, explaining them in the process.

Deton24 (talkcontribs)

I finally performed some initial tests. It turned out that using Windows 7, eventually Vista SP2 compatibility mode gives 50 vs 60 FPS reproducible performance gain in one scene in Iraq, but drops to 30 FPS are still there.

I somehow managed to launch D9VK which essentially does the same as DXVK, but now is further developed under DXVK project. The latter doesn't work for me as well. D9VK: https://github.com/Joshua-Ashton/d9vk (copy only d3d9.dll to src\system)

Performance is more consistent now in places with FPS drops, thought it didn't really increase much beside CPU usage. W7 compatibility mode is no longer necessary in the aforementioned place to achieve comparable performance.

Maybe later I'll try to check particular config solutions and maybe document some tests and squeeze more performance.

Markie (talkcontribs)

I tried the game with the latest DXVK version (1.9.3), both the standard and async versions. Launched it, waited until the shader cache compilation stutters in the intro and menu went away, then loaded every mission in the game and did the same thing, moving around for a bit. Normal DXVK has endless stutter - the more frequent stutters at the start do go away but the game simply won't become stutter-free at any point, it will always happen during camera movement. It seems that DXVK doesn't deal well with the geometry or textures in this game because I'm pretty sure the stutters happen according to how much detail is on-screen at the moment, quite curious (and if you move the camera too fast it happens even if there's not a whole lot of detail visible). So I tried DXVK-async and did the process all over again. It did get rid of the additional stuttering but it turns out it doesn't increase performance to any extent whatsoever. If you wait and let the shader cache build for long enough, the apparent frame rate increase which is present initially (while the game is stuttering) is gone, it's same thing with DXVK or DXVK-async. It performs the exact same as the game running under DX9.

Deton24 (talkcontribs)

Very nice research. Thank you.

I performed some tests using dxvk-async, and it turned out I have some performance increase vs in-game d3d9. https://drive.google.com/drive/folders/1TTyoZAABsuSC8Tx4-T7A0efY8PDTndu6?usp=sharing

It was recorded using Radeon Relive which has some performance impact - 45 with, and 53-55 FPS without recording.

Notice the FPS drop to 32-35 while looking for the most distant enemy on the left in d3d9 while DXVK keeps there around 47 with a moment drop to 39.

The reason I have some performance gain might be either old CPU or AMD card. Maybe both.

The game stutters for me in general, but yes, stuttering on the beginnings of the levels disappeared using dxvk-async. Very nice find.

Markie (talkcontribs)

Good news, I tried the most recent version of DXVK (1.10.1) and it did give me a consistent performance increase, around 10 FPS. I tested the initial area right after people run away and you start controlling Sam and the area where you peek under the door right at the start of the second level looking to the right, which have some of the worst performance drops in the game. In the 1st one whereas the game would drop to 43-ish FPS at worst without DXVK, it basically didn't drop below 59 FPS even moving away from the corridor which you have to go through and looking at the general direction of the rest of the level, and in the 2nd one instead of getting a minimum of 43 FPS when the frame rate drops while using the mirror (sometimes even hitting 40 FPS for a moment) the lowest I managed to get was 53 FPS and it would easily climb back up to a locked 60 FPS (V-Sync was on) if I just moved a bit from that particular position and camera angle. Stutters are also far less present than with previous versions of DXVK. Normal DXVK or async didn't make a difference after I let the shader cache build up - both increased performance and the game behaved the same way. The only issue is: stutters here and there while moving the character and the camera around (and sometimes when approaching objects or NPCs, apparently) just don't seem to go away. I'm pretty sure it's not related to the shader cache compilation since those stutters are always present and reproducible. The game can even crash if I move the camera too fast in a random direction causing it to stutter too "hard". I tried using V-Sync through DXVK by configuring the dxvk.conf file and setting d3d9.maxFrameLatency to 1, d3d9.numBackBuffers to 3 and d3d9.presentInterval to 1, but much like in GTA IV the in-game V-Sync seemed to be more stable... either way, neither solved the problem, I just couldn't get rid of the stuttering. That's the only issue now.

Deton24 (talkcontribs)

For these stutters, try out using DXVK-Async and put this line in dxvk.conf near exe:
dxvk.enableAsync = true

Technically, for fair comparison, you should delete cache.

Also, you can try to fiddle with this parameter:
dxvk.numAsyncThreads = 10 or 16 or 6 or 5 or 0 (auto)

Markie (talkcontribs)

I tried DXVK-Async with the necessary command and no cache built. It's very unstable, I tried loading different levels multiple times but it just crashed way too much while moving around and even during cutscenes while loading levels actually. With normal DXVK the game is mostly fine except for the occasional stutters which never stop and rare crashes.

Deton24 (talkcontribs)

I need to admit I performed the tests with dxvk-async in the videos above without that command, and it was better than regular DXVK for some reason. But maybe it's some regression in dxvk-async in newer versions, and it didn't happen on 1.9.3 version. The crashes you encounter during heavy stuttering are rather not strictly game related, because I know it is the way how DXVK behaves for some reason and it happened for me before for GTA IV, but rarely.

Looks like I have the best results with
dxvk.enableAsync = true
d3d9.maxFrameLatency = 1
dxvk.numAsyncThreads = 6
Or for auto - 0 (at least not much above physical CPU core/thread value might be good idea in this case). Tested with dxvk-async 2.0 - it's pretty much stutter-free.