CPU Optimization / ini tweaks

[Darkstorne]

I recently reinstalled Oblivion and am so happy to see mods like Oblivion Reloaded and the Stutter Remover making the game playable at 40fps+ even with ENB and RAEVWD. It's great having this game both stable and stunningly prettier at the same time! I know this game is CPU restricted so was wondering what the general consensus is in 2016 regarding all the popular CPU tweaks in the game's ini file? I find many old threads online recommending changes like this for multi-core CPUs:

 

From UESP.net:

If you have a Dual/Quad core Processor or a processor with Hyper-Threading, then set these values to this:

 

bUseThreadedBlood=1 (default 0)
bUseThreadedMorpher=1 (default 0)
bUseThreadedTempEffects=1 (default 0)
bUseThreadedParticleSystem=1 (default 0)
bUseBackgroundPathing=1 (default 0)
bUseBackgroundFileLoader=1 (default 0)
iNumHavokThreads=3 (default 1)
iThreads=10 (default 3)

 

 

Are these still recommended? I know a lot of ini tweaks from the past have been shown to have either no impact or even a negative impact. I'd love to know how to get the most out of this game's CPU-heavy design. It's definitely the bottle-neck these days.

[bevilex]

I have these settings since a very long time. I am afraid I am not aware of other recommended CPU ini Tweaks. If you want to optimize CPU usage and performance, you'll have to use other methods/tweaks, for instance :

 

 

- reducing :

uGridDistantTreeRange=

uGridDistantCount=

uGridsToLoad=

in Oblivion.ini seem to have a great impact on performance (RAM usage, FPS)

- Carefully select mods , some are FPS killer

- Optimize Textures and Meshes with PyFFi and Texture Optimizers

- Clean and optimize esp files with TES4Edit

- Use stability mods (OSR, ENBoost, MoreHeap, 4GB patch) etc.

Edited July 19, 2016 by bevilex

[forli]

Even if incomplete, the most accurate guide for Oblivion.ini is the Alenet's one.

Alenet didn't simply tested the values trying to find the differences. He actually used reverse engineering in the code to find out if/how the game really uses those values.

The guide is here: http://www.nexusmods.com/oblivion/articles/44178/?

[Darkstorne]

Even if incomplete, the most accurate guide for Oblivion.ini is the Alenet's one.

Alenet didn't simply tested the values trying to find the differences. He actually used reverse engineering in the code to find out if/how the game really uses those values.

The guide is here: http://www.nexusmods.com/oblivion/articles/44178/?

This is fantastic, thanks for the link :)

[TheMastersSon]

forli, do you know what Alenet means by this:

 

"These options are taken by the Oblivion code reverse engineering, so they are accurate"

 

Did the author use a disassembler, and did they see Oblivion's source code? If not, then what does "reverse engineering" refer to?

 

Judging from the accuracy of at least a few of the claims in the article, I suspect the author simply benchmarked their own system(s) to decide whether Oblivion "uses" a given setting. If that was the case, it wasn't reverse engineering.

 

The list of system, OS, driver and other settings that can affect a game's performance, and whether it uses a given feature, is longer than your arm, and our own testing experience has disproven some of these claims, especially regarding iNumHavokThreads and the OPENMP variables. Changing them makes a big difference on our system, the author is more than welcome to come see these differences for him/herself. E.g. as recommended in other tweak guides, upping iNumHavokThreads (to 5 in our case) entirely fixed our stuttering problem during heavy battles and when multiple characters are onscreen and doing animations (deer, horses etc). We also see big FPS changes according to how iThreads and iOpenMPLevel are set in the [OPENMP] section. Etc.

 

Not to state the obvious but the features a game uses are hardware dependent. Without testing on multiple platforms (again, no idea whether the author did so) or specific info from the publisher, it's impossible to make global proclamations about any given feature. My favorite example of this is having people with Nvidia cards go into their 3D driver settings for Oblivion, and reduce the 'maximum number of pre-rendered frames' from its default (3) to 1, and watching their faces as their lag problems in the game entirely disappear. And gee whiz it has absolutely nothing to do with oblivion.ini settings. Oblivion doesn't understand pre-rendered frames, so the more you generate the more of your card's horsepower is flushed down the commode. :smile:

 

I mention this because, if the author tested on an Nvidia system, the above lag caused by Oblivion's default settings would have masked any performance changes that occurred by changing oblivion.ini settings. Again we need to know if just benchmarking was used to make these determinations or Oblivion's source code.

Edited July 22, 2016 by TheMastersSon

[forli]

Nope, he used reverse engineering. In case you didn't noticed, Alenet is the author of Oblivion Reloaded, a very complex OBSE plugin which inject code directly in the game executable and can even patch bugs in the engine. This would have been completely impossible without reverse engineering.

 

So Alenet surely saw the Oblivion code, and he knew exactly what he was saying in that article, as he saw the actual code used by Oblivion to manage those settings. When he said the game use 1 anyway for iNumHavokThreads, it means the actually saw in the code Oblivion does ignore whatever value you put in iNumHavokThreads and use 1 instead; and when he said iThreads and iOpenMPLevel are not used, it means Oblivion never reads/uses those values in the code.

Of course, he added benchmark tests on top of that (like with iTreeClonesAllowed), and there's a chance he made a mistake (maybe some settings are really used but he didn't find them), but unless someone can prove he's wrong (by showing a piece of Oblivion's code, not by just showing benchmarks), his researches remain the most accurate ones we ever had.

 

Benchmarks are never accurate. The performance differences you noticed may have been caused by anything, even external factors like the CPU/RAM/HD used by the OS at the time you did those benchmark tests or the temperature of your computer, which may have slowed everything down in some tests.

Edited July 22, 2016 by forli

[zdswulyx]

Unless Alenet worked for Bethesda seeing the code it's not possible. The only code he can see is the machine code; it's difficult, but not impossible with the help of decompilers and deassemblers to get a grasp of the original.

 

It's also possible Bethesda released the code, similarly to id for Doom and Quake, but it would be a such big positive news that everyone would know it and we would not need hacks as Oblivion reloaded, it would be possible to actually fix the bugs directly in the engine.

[forli]

Machine code IS code (hard to read, but still code)!

If you take a look at Oblivion Reloaded you'll see he has all skills required to read the machine code.

 

Bethesda has still not released the Morrowind source code, so it's very unlikely they will ever release the Oblivion source code.

It's true: without source, only Gods can create plugins like OR, OSR and EngineBugFixes to patch bugs in the game code.

[TheMastersSon]

forli, machine code is not code, it's the result of code. There's no need for disassembly if one has the source code to read. :)

 

Regarding iNumHavokThreads, here's one difference of opinion offered by IanPatt, a developer of OBSE. He claims the setting is both read and used by Oblivion's runtime.

 

"* bUseThreadedBlood - Does nothing. Isn't even read by the runtime.
* bUseThreadedMorpher - Is read by the runtime, but isn't used for anything.
* bUseThreadedTempEffects - Is read by the runtime, but isn't used for anything.
* bUseThreadedParticleSystem - Is read by the runtime, but isn't used for anything.
* bUseMultiThreadedTrees - Is read by the runtime, but isn't used for anything.
* iNumHavokThreads - Is passed to Havok and probably does what it sounds like."

 

https://forums.nexusmods.com/index.php?/topic/183530-quad-cores/

 

All I can tell you is that the setting definitely makes a difference on our system.

[forli]

Even if it's the result of the code, machine code read during reverse engineering is the actual code executed by the CPU, so it's the most accurate (and difficult to read) code.

I know there's no need to disassemble the machine code if we have the source code... but we don't have the source code! As I said, we still don't have not even the Morrowind source code, so I don't think we'll ever see the Oblivion's one. I believe these kind of engine fixes/patches will always be in the hands of few skilled programmers who succeed in read the machine code (the only code we have now, and probably the only code we'll ever have).

 

 

... and there's a chance he made a mistake (maybe some settings are really used but he didn't find them)...

I didn't excluded the possibility for errors, but the statement

iNumHavokThreads - Is passed to Havok and probably does what it sounds like

 

means IanPatt didn't digged in the Havok engine ("probably does what it sounds like..."), so he didn't really know if Havok really use it, while it's possible Alenet made further studies while developing OBGE4/OR (since he claims the engine uses 1 anyway).

Still, if iNumHavokThreads makes a difference, then Alenet missed something.