域名将于6月份到期,并且不再续费,届时网站将无法访问。
6月份之前如果服务器到期将提前关闭网站,请改访问模组网社区

Oblivion Stutter Remover 介绍

Oblivion Stutter Remover(简称OSR),可以让游戏更好或者更流畅的运行,可以避免或者减少卡顿,并且能够避免因卡顿而引起的跳出,不过大部分情况下它并不会很明显的提高FPS,而是提升最低FPS的值。

因为OSR的英文说明太长,而且专业词汇太多,理解比较困难,所以我就试着翻译一下了,出错请帮忙指正

PS:下面的解说来基于官网里面4.20的readme,4.1的部分有另外补充。。。。虽然不想说,但是:内容看不懂可以无视,这东西真不需要知道太多。

提醒:从下面的解说中我们可以知道 Oblivion Stutter Remover 具有锁帧的效果,而且错误的配置可能会降低游戏稳定性……所以如果你只是装一些服装、种族的话,你其实是没有必要安装这个的。但是,从另一方面来讲,国内玩家总让人感觉有点贪心的感觉——也许是因为炮灰版或者天际降临版整合的东西太多了,而这两个版本又是大家入门时第一个接触到的,这导致很多人以为自己的上古4就应该装一堆的高材质美化——这种情况下,OSR 又变成必须的了。
简单的说,MOD数量比较少的人是建议不安装这个的,但如果因为安装大量高材质等内容而引起卡顿、1.7G跳出的,OSR就成了你的必需品了。

概述 · Overview

Oblivion Stutter Remover(简称OSR),可以让游戏更好或者更流畅的运行,可以避免或者减少卡顿,并且能够避免因卡顿而引起的跳出,不过大部分情况下它并不会很明显的提高FPS,而是提升最低FPS的值。

Oblivion Stutter Remover是针对Oblivion的,当然,还有针对Fallout的Fallout Stutter Remover以及针对Fallout: New Vegas的New Vegas Stutter Remover。这篇说明可能也会稍微涉及到这两个插件。我们把这几个插件统称为Stutter Remover(简称SR)。

作者建议在使用Stutter Remover之前先阅读说明的1到5部分,其他部分对普通用户一般不是很重要,不过我个人建议还是都读一下,你可以简单浏览一下小标题,然后选择是否细读里面的内容。

需求 · Requirements

Oblivion Stutter Remover (OSR)

需求:
– Oblivion
– – version 1.2.0.416
– Oblivion Script Extender
含以下功能:
– 64 Hertz Fix
– FPS management
– Critical Section adjustments w/ overrides
– Hashtable adjustments w/ overrides
– Heap replacement
– RNG replacement
– other

Fallout Stutter Remover (FSR)

需求:
– Fallout 3
– – version 1.7.0.3
– Fallout Script Extender
含以下功能:
– 64 Hertz Fix
– FPS management
– Critical Section adjustments w/ overrides
– Hashtable adjustments w/ overrides
– RNG replacement
– other

New Vegas Stutter Remover (NVSR)

需求:
– Fallout: New Vegas
– – versions supported:
– – – 1.0.0.240 (minimal support only)
– – – 1.1.1.271 (minimal support only)
– – – 1.2.0.285
– – – 1.2.0.314
– – – note that 1.1.0.268 is NOT supported
– New Vegas Script Extender
含以下功能:
– 64 Hertz Fix
– FPS management
– Critical Section adjustments w/ overrides
– Hashtable adjustments w/ overrides
– RNG replacement

下载 · Download

T网载点

本站载点

安装 · Installing

1.A 如果你下载的OSR是zip压缩包,就把Data目录扔到Oblivion目录内。
1.B 如果你下载的OSR不是.zip压缩包,你就需要把sr_Oblivion_Stutter_Remover.dll扔到Oblivion\Data\obse\plugins目录内(如果没有此文件夹的,就自己创建)。如果你安装了旧版的OSR,请删除ini配置文档(即 Data\obse\plugins\sr_Oblivion_Stutter_Remover.ini ),没有ini文档的话,游戏加载时会根据你的情况自动生成新的ini文档;
2. [可选] 通过修改OSR的ini文档自定义OSR配置,关于你可能需要调整的配置,可以参考本文中第5部分。
3. [可选] 用OBSE运行游戏再退出,检查一下OSR是否在游戏中加载了。因为OSR每次运行后都会在游戏目录内生成一个日志文件sr_Oblivion_Stutter_Remover.log。如果运行游戏后,你没有找到此文件,则表示你可能OSR安装错误或者OBSE安装错了。

卸载 · Uninstalling

直接把 Data\obse\plugins 里面的 sr_Oblivion_Stutter_Remover.dll 删掉,或者把这个dll文件移到别的地方。

常见配置修改 · Common Settings Changes

为了方便大部分用户使用,OSR设置中使用了一些缺省值,但这样并不完全适用你:可能是某些设置并不是你喜欢的,或者OSR没有完全准确地检测出你的电脑配置。同时,考虑稳定性与流畅性时,OSR的缺省设置所追求的更多的是稳定性;在卡顿最少与平均FPS最高,OSR的缺省设置所追求的则是卡顿最少。

OSR将配置保存在文件 sr_Oblivion_Stutter_Remover.ini 内,如果文件不存在的话,你可以用运行游戏(要求是obse启动),然后OSR便会生成一个新的INI配置文件(数值都是缺省值,需要调整)如果你不小心把INI数值改乱了,或者想要把配置恢复到缺省值,也可以删掉INI文档再运行游戏重新产生。

这边只是一些常见的修改,更详细全面的规则则在第8部分(原文写第8部分,但没有,疑似作者写错。)。

Master\bReplaceHeap(缺省:0,可考虑修改为1)
缺省下,此功能是关闭的。因为部分用户开了之后,游戏稳定性会下降,不过开启此功能确实能提高性能,提升的多少取决于你的游戏可以使用的线程数。如果线程数很多,那么就会有很明显的性能提升。同时,这边还能解决Windows XP下游戏装了大量Mod后长时间运行游戏而引起的卡顿。
如果你开启 Master\bReplaceHeap 后遇到了一些问题(CTD之类的),你还可以尝试修改一下 Heap\iHeapAlgorithm 的数值,此数值通常为6, 5, 4, 2 , 1或3。(小冰梦说:不要遇到问题马上就关闭 bReplaceHeap ,你应该先测试一下哪个 iHeapAlgorithm 最稳定,同时调整 iHeapSize 的大小。具体可参考第9部分关于 Heap 的说明)

FPS_Management\MaximumFPS(缺省:30,可以考虑修改为0或者其他数值)
有的人不愿意限制FPS,那你可以通过修改此数值为0从而关闭最大帧数限制。同样地,如果你玩游戏时刷新率不是60赫兹,你可以考虑把此数值修改为刷新率的数值,或为一半,或为三分之一(小冰梦说:有兴趣的可以往下读,会发现 MaximumFPS 超过屏幕刷新率的一半时,部分玩家游戏的稳定性会降低)。此设置在 Master\bManageFPS = 0 时无效。

Critical Section Suppression(特殊)
缺省下,OSR会抑制一个特定的critical section(实验证得,关掉此critical section后游戏能够更好地运行)。同时,这里面还存在另一个critical section,部分用户已证明将其抑制后游戏不会发生任何问题,但部分用户抑制后则会在室内->室外场景切换时CTD或者其他的麻烦。这个critical section关闭了的话,只会在性能上有小小的提升,所以作者并不建议开启,不过如果你想要开启的话,在ini中找到行“_comment = Renderer+0x80”(4.1版本是搜索“CallerAddress = 0x70172A”),然后在该行后面新增一行,并添上“Mode = 5”,注意是“Mode”而不是“mode”。此设置在 Master\bHookCriticalSections 或者 CriticalSections\bUseOverrides 为0时无效。
注意:如果你是使用New Vegas Stutter Remover的话,你会找到很多行“_comment = Renderer+0x80”,这边每一行对应的是不同版本的FNV,你可以全部修改,或者只修改你正在使用的FNV版本所对应的。

CriticalSections\iDefaultMode(缺省为2,可以考虑修改为3)
一般地,OSR尝试在 Mode 2(模式2) 下减少每一个 CRITICAL_SECTION 的卡顿,使用 Mode 3(模式3) 可能会稍微增加卡顿,不过也可能提高FPS。iDefaultMode 是给那些在 Mode 中没有 override(在ini的OverridesList下)设置的 CRITICAL_SECTION 使用。

历史版本 · Version History

翻译价值不大,原内容如下

Show the Content

version 1:
This was known as FPS Capper. All it did was FPS management.version 2:
This was known as FPS Capper. All it did was FPS management.

version 3 beta 1:
The first version to be named Oblivion Stutter Remover. Sometimes freezes for several minutes at the main menu. NPC voice and face movements can screw up in dialogue.
version 3 beta 2: NPC voice and face movements can screw up in dialogue.

version 3 beta 3: NPC face movements can screw up in dialogue, but not nearly as bad as in beta 2.

version 3 beta 4:
Don’t use this version! In some cases nearby NPCs would randomly die whenever you did a cell transition.
version 3 beta 5:
Reports of very rare drastic FPS drops, fixable by restarting Oblivion.

version 3 beta 6:
There was a long delay between beta 5 and beta 6, filled by many alpha releases. This was the first version of OSR to really do a decent job of actually reducing stutter for the average user. This is because of new features: critical section fairness tweaks, critical section suppression, and heap replacement. Unfortunately, heap replacement still has major problems for many users. bFix64Hertz was set to 0 by default in the ini, it should be 1 instead.

note: there was never a version 3 final. If there’s enough demand I could make one up based off of version 3 beta 6 source code with a few fixes.

Version 4.1.0:
Major Changes:
– Fallout 3 support: Doesn’t provide as much benefit on Fallout 3, but it does help. See Fallout Stutter Remover.
– .ini file: Completely different ini file format
– Hashtable resizing: New feature for improving performance
– Critical Sections: Generalized many special cases for critical sections, now much more adjustable from the ini file.
– Heap Replacement: Fixed a few bugs, but I think it still has problems.
– Version naming: Versions released to tesnexus are now called release versions instead of beta versions. Versions released to my ftp server are now called beta versions instead of alpha versions. The first digit of the version number (“4” in this case) is incremented only when major changes are made to configuration or distribution format. The 2nd digit of the version number (“1” in this case) is incremented each release version. The 3rd digit of the version number is incremented once for each beta version. Whenever a digit is incremented, all digits further to the right are reset to 0.

Version 4.2.0:
Major Changes:
– New Vegas support: See New Vegas Stutter Remover
– Hashtable Overrides: Resizes large numbers of (semi-)specific hashtables to better sizes.
– Heap Replacement: A few extra heap algorithms supported.
– Profiling: Extra options for recording performance data to the log.
– RNG Replacement: Replaces the vanilla RNG with a higher quality & faster RNG.

工作原理 · How This Works

OSR从根本上hack游戏引擎,主要修改Oblivion从硬盘到内存的这段过程。

注意:OSR不是 4GB补丁、Silent Feet、PyFFI、Oblivion Crash Prevention System 等工具的替代品,所以如果你是因为声卡或者相关软件的问题而引起的卡顿,使用此工具可能能减少卡顿,但最实际的措施是使用类似于Silent Feet的减少声音使用的mod。并不存在“装了OSR后,我就能克服所有流畅性的问题”这种说法。关于其他性能的工具与Mod可以参考第10部分。

下面内容,因为技术限制,能力不够,故没翻译
7.1: FPS Management:
FPS Management 可以控制帧数同时调整游戏时间的流动速率。通过让游戏引擎在卡住不动的时候不强行跳过从而缓和卡顿。从效果上看,很长时间才能完成的帧最终会变成慢动作。其实是通过让 Oblivion 表现得就像是 iFPSClamp = MinimumFPS (锁定帧数 = 最小帧数)时工作,但也只针对那些帧数小于最小帧数的情况。这么做能够提高稳定性。同时可以控制最大帧数——部分玩家反映他们将最大帧数控制在屏幕刷新率一半以内的话,游戏会变得流畅许多,同时还能帮助引擎在第二线程中清理掉无用资源。
FPS Management 同时可以让游戏的核心线程休息细微时间,许多人证实此方法能够减少卡顿(不过此工具还有其他功能,搞得此功能看起来很多余)。

7.2: Critical Sections:
Critical sections 是由微软提供,Oblivion 拿来控制游戏内部线程不相互冲突的线程同步机制。默认情况下,OSR总会让所有的线程都尽可能公平的运行,甚至会牺牲性能来实现此效果,其目的是确定所有线程都不会过分使用其他线程使用的资源。然而,某个特定的 critical section 则被限定成使用稍少的公平度,另一个则完全被限制得没有任何效果。这些内容都可以在 ini 中修改。

7.3: Heap Replacement:
Oblivion 使用自制的 heap(又叫内存管理、内存分配),好像是 Bethesda 为了 Oblivion 而重新开发的。但是这个 heap 存在缺陷。特别的,在多线程负荷下,其表现非常糟糕,而 Oblivion 又经常处于多线程负荷。此插件可以替换 heap 为其他方式,有很多选择方案,而且大部分在多线程负荷下运行都快特别多。比较不幸的,替换 heap 好像会导致部分玩家游戏不稳定。我也不太清楚这究竟是因为我的 heap 存在缺陷或者 Oblivion 在非原版 heap 下会跳出。
由此功能而实现的性能提升是非常明显的,比如减少卡顿、减少读取时间、让部分菜单显示快点,也可能稍微提升FPS。不过也不是所有玩 Oblivion 的玩家都经常多线程工作。有人听了可能会失望,但是因为这会降低游戏的稳定性,所以默认下我并没有开启此功能。不过,大部分人多是获得很大的性能提升,所以我还是建议玩家可能的话可以试着开启此功能,真的不稳定了,再关掉就好了。

7.4: Hashtables:
Oblivion 捆绑了一堆用来查找数据的哈希表。用的是普通的哈希表,问题在于他们从来没有考虑更新下这个东西,而默认的大小主要是给那些未安装MOD的游戏使用,对于装了MOD的,这就显得太小。当哈希表超载了,游戏性能便会下降。当哈希表多余了,内存则会浪费掉。很可惜的,大部分的哈希表几乎在整个游戏每个角落都有,而且 OBSE 也做了很多常识,我个人不是太清楚相关的线程模型,所以想要安全、动态的调整哈希表变得特别困难。我最终也只找到几样我能够控制其大小的哈希表,效果看起来还行。

完整配置 · All Settings

OSR把配置保存在 Data\obse\plugins\sr_Oblivion_Stutter_Remover.ini 里面,如果文件不存在的话,可以用OBSE启动游戏,OSR便会自动生成一个新的。如果你不小心把INI数值改乱了,或者想要把配置恢复到缺省值,也可以删掉INI文档再运行游戏重新产生。

INI文档里面的结构大致是“模块 { 设置 = 数值 }”,下面解说时,如果提到“模块x\设置a”,就是表示 模块x 下面的 设置a。

另外,设置的名称首字母如果是i,表示数值应该为整型(就是数值只能是整数,不能是小数);首字母如果是b,表示该数值是布尔型(数值只能是0或者1);首字母如果是f,表示该数值是浮点型(可以是小数,如3.14)。部分设置不含这里面提到的三个的首字母……因为还没确定其所对应的比较恰当的类型。

以下是完整的配置以及所对应的缺省值(可能不是100%最新):

– 模块:Master{}
用来开启/关闭OSR的子系统功能,以及那些不属于任何子系统的功能。

Master\bManageFPS (缺省: 1)
设置为0可以关掉FPS管理系统,让所有在FPS_Management下的配置都失效。

Master\bHookCriticalSections (缺省: 1)
设置为0可以关掉Critical Section系统,让所有在CriticalSections下的配置都失效。

Master\bHookHashtables (缺省: 1)
设置为0可以关掉Hashtable系统,让所有在CriticalSections下的配置都失效。

Master\bReplaceHeap (缺省: 0)
设置为1可以开启Heap替换系统,让所有在Heap下的配置都生效。

Master\bLogToConsole (缺省: 0)
设置为1可以把日志显示在控制台里。
注意:已经自动生成日志文档在游戏目录的sr_Oblivion_Stutter_Remover.log了

Master\bFix64Hertz (缺省: 1)
设置为1可以修复一个造成游戏microstutter(帧延时波动)的问题。此问题通常被称为“64 Hertz 现象”:游戏引擎时序逻辑发生在每秒1/64的分辨率下,而当垂直同步关闭的话,屏幕刷新率通常禁止引擎每秒运行60帧。这种冲突会造成帧延时波动。OSR的解决办法是把每秒1/64替换为每秒1/1000。

Master\bFlushLog (缺省: 1)
让OSR把所有日志信息直接写入 sr_Oblivion_Stutter_Remover.log 而不是暂时保存在内存中。因为对硬盘的大量使用,所以可能会略微降低性能,但也能在把出错信息及时的保存在log文档中。

Master\bFastExit (缺省: 0)
让游戏快速退出。对部分OBSE版本,会造成游戏内的游戏设置发生变化而无法再退出的时候保存游戏。

Master\bExtraProfiling (缺省: 0)
让OSR调整游戏内大量小细节的性能,并且将这些数据记录到日志(log文档)中。

Master\iSchedulingResolution (缺省: 1)
增加系统计划任务,设置为1,OSR与Oblivion能够更好的工作,不过会降低笔记本电池的寿命。

Master\bExperimentalStuff (缺省: 0)
开启Experimental模块下的功能

Master\iMainHookPoint (缺省: 1)
设置OSR何时挂钩Oblivion,用来检测信息段范围(frame boundaries),判断游戏是否已加载或者初始化完毕,可能的数值有
0: main hook disabled(直接关闭hook)
1: use top level once-per-frame game function(游戏默认的:每帧一次)
2: use DX8 mouse input code(根据DX8鼠标输入)
3: (not supported on all targets) hook at time measurement((暂不支持所有目标)根据时间检测)

– 模块:Experimental{}
包含一些不建议修改或者未完成的项目,请原谅我不翻译了。

Experimental\iReduceLongSleep (缺省: 0)
If set to 1 or higher it will reduce the duration of Oblivion Sleep() calls. Setting this to 1 may help performance on many-core CPUs. Setting this to values higher than than 1 is not recommended. 1 means 50% reduction, 2 means 75% reduction, etc.

Experimental\bRemoveShortSleep (缺省: 0)
If set to 1 this will suppress Sleep() calls with very short durations.

Experimental\iThreadsFixedToCPUs (缺省: 0)
If this is set to a non-zero value then N threads will be locked to only run on the first N cores, where N is the value you set this to. In addition, the main thread may be given extra priority over all other threads for some purposes.

Experimental\bSuppressRandomSeeding (缺省: 0)
Calls to srand() will be suppressed.

Experimental\bMonitorBSShaderAccumulator (缺省: 0)
Performance of certain extra code will be recorded to the log.

Experimental\iPrintSceneGraphDepth (缺省: 0)
Not recommended. Every single frame, this will print out the scene graph to a depth limited by this setting.

Experimental\bReplaceRandomWrappers (缺省: 1)
Replace some wrappers of rand() that Oblivion uses internally. This also ends up fixing bugs in them, which may have a subtle but possibly noticable effect on game balance.

Experimental\bBenchmarkHeap (缺省: 0)
When the main menu is reached this spends a second or two benchmarking the heap. The results will be printed to the log file. If heap replacement is used it will call the replacement heap directly, otherwise it will call Oblivions native heap.

Experimental\bAlternate64HertzFix (缺省: 0)
Not recommended at this time. Attempts to fix issues that the 64 Hertz Fix addresses in a slightly different way.

Experimental\bAlternateHeapHooks (缺省: 0)
Not recommended at this time. Attempts to replace the vanilla heap in a slightly different way.

Experimental\iHeapMainBlockAddress (缺省: 0)
If non-zero, it should be set to something like 0x20000000, 0x30000000, etc (an 8 digit hexadecimal number that ends with at least 6 consecutive zeroes). This is the address where OSR will attempt to put the main memory alloction for its heap if heap replacement is enabled and the heap algorithm selected is #3, #5, or #6.

– 模块:FPS_Management{}
FPS管理模块设置

FPS_Management\bAllowSlowMotion (缺省: 1)
设置为0可以关闭OSR对游戏时间流动的替换。早期的版本中,开启此功能会导致场景切换后,玩家周围的NPC会突然死去的bug,但新版本已经解决了此bug,如果你觉得不放心的话,可以设置为0从而避免此bug。设置为0的话,MinimumFPS 和 iHardMaxFrametime将失效。

FPS_Management\MaximumFPS (缺省: 30)
这边限制游戏可以达到的最大FPS。作者认为设置为30已经够了。注意,通常我们说的是frames per second,即每秒的帧数,但这边是把frames per second的数值转换成milliseconds-per-frame(每帧的毫秒),然后再独立考虑每个帧。如果某个帧完成得太快,OSR会强制引擎主线程休息,直到正确的毫秒过了。让主线程休息可以减少Oblivion后台线程或其他后台程序对资源的使用,从而让CPU和/或GPU以更低的温度运行,并且比较省电。

FPS_Management\MinimumFPS (缺省: 10)
限制游戏的最低FPS。不过,非我们平时指的时间,而是指游戏中的时间。所以,如果游戏很卡的话,你仍然可能遇到FPS数值为1的情况。但这边会降低游戏中的时间到正常的10%,从而实现游戏中的时间的FPS为10(此例子表示看到的真实FPS为1,但效果上游戏中FPS为10)。同样地,同MaximumFPS,这边的FPS指的是milliseconds-per-frame 而不是frames per second。
作者将此数值设置为游戏可玩的最低数值,避免因FPS太低而引起的游戏出错。解决了帧数太低而导致玩家无法打到敌方的问题(主要原因为敌人在帧与帧切换时绕着玩家转,同时,玩家的控制又没效果了……因为时长太短,达不到游戏限定的反应时间)。

以下三个是4.1里面的

Show the Content

FPS_Management\iSmoothFrames (缺省: 0)
设置为0关闭smoothing logic(逻辑流畅化)功能。需要开启的话可以把数值设置为2。不过根据使用者的汇报,此功能没多大开启的意义。smoothing logic主要是用来避免因卡顿而引起的一系列问题。此项目在bAllowSlowMotion为0时无效。

FPS_Management\iSmoothMode (缺省: 0)
正确的数值应该为0, 1, 2, 或者 3. 设置为0或1可以开启特定的算法用来从时间流动中过滤掉卡顿现象。该算法运行的结果是,当你遇到了FPS骤降的情况下,你会发现游戏时间与实际时间不相等。设置为2或3则关闭此算法。0/2和1/3的区别只是帧在时间分配上的微小差别。

FPS_Management\bFPSConsoleSPAM (缺省: 0)
记录OSR完成每帧所需要的时间。每帧都会运行,所以会生成大量的日志事件。


FPS_Management\iSleepExtra (缺省: 2)
OSR会强制游戏每秒休息个几毫秒。好处是可以减少Oblivion后台线程或其他后台程序对资源的使用,减少电脑对温度与能量的消耗。明显的效果是后台线程可以额外获得主线程占用的资源,能够暂时控制该资源。
设置为-1,则不让Oblivion休息,如果游戏达到了MaximumFPS,OSR会浪费大量的时间在空循环……-1只是为了测试,不建议使用。

FPS_Management\iFPS_Frequency (缺省: 4000)
设置OSR记录日志的频率。如果设置为0,OSR日志功能将停止工作,如果设置为1,则OSR每隔一帧都会在日志中记录数据,如果设置为60000则会每隔一分钟记录。

FPS_Management\iSchedulingParanoia (缺省: 1)
单位为毫秒。控制MaximumFPS对scheduler(计划任务)的偏执/依赖度。如果数值太高,MaximumFPS将永远不会休息,会造成无用的空循环,设置为0,MaximumFPS则完全信赖scheduler从而在特定的任务时间管理主线程。
作者将此数值折中为1,从而对scheduler有少量的依赖度,但又允许大量的空闲时间来进行建设性的使用。

FPS_Management\iHardMaxFrametime (缺省: 200)
单位为毫秒。作者发现当在错误的时间运行时间调整功能,会发生奇怪的事,比如周围的NPC突然死去。此项目是用来避免这类事件发生的,主要是设定一个最大数值,从而不让OSR超过该数值。一般情况下你在达到此限定时会先达到MinimumFPS,但MinimumFPS在一些情况下会被遗弃避免一些类似于嘴唇与声音不同步的副作用,所以这个就像是MinimumFPS的第二类型。此数值太小会导致嘴唇与声音不同步,太大则会导致NPC随机“领便当”。作者折中,设置为200,除非你的FPS低到只剩5,否则不会出现嘴唇与对话不匹配的情况。当然,如果你的FPS低于5,那你就需要优化游戏了。

– 模块:CriticalSections{}
控制OSR对引擎CRITICAL_SECTION的调整。什么是 CRITICAL_SECTION ?引擎使用 CRITICAL_SECTION 以避免不同的线程互斥。微软有提供一些方案,Oblivion根据你系统的不同也有提供一些不同的方案。更多详情可以上MSDN学习。。。

CriticalSections\bEnableProfiling (缺省: 0)
设置为1可以记录critical section在游戏中关于时延(timing)/性能的信息。这么做会在性能上有微小但明显的降低。OSR把这些数据保存在log文档中,记录这些数据可以提供有用信息,方便用户了解为什么游戏卡了或者运行变慢了,借此可以用来调整Overrides部分。

CriticalSections\bEnableMessages (缺省: 0)
设置为1可以记录critical section关于时延(timing)/性能的信息。这么做会有很小的性能影响,不过会让日志文档内容太多,不容易找到有用的信息。

CriticalSections\bUseOverrides (缺省: 1)
设置为1可以让OSR使用下面的Override功能。

CriticalSections\iDefaultMode (缺省: 2)
如果Override列表中未设置时,默认下应该采取何种Mode处理critical section(列表中没有4):
1、Normal – 正常
2、Fair – 牺牲性能,追求公平。避免某个线程超负荷使用critical section,但也会降低事件完成率。比如:能减少卡顿,但降低FPS。
3、Stagger – 介于公平与性能之间,通常是优化性能但过段时间又去优化公平。
5、Suppress – critical section被抑制。抑制critical section可能造成CTD或者不稳定,但也能提高性能,不同的critical section会有不同的影响。
6、主线程获得该critical section的优先权
7、后台线程获得该critical section的优先权

CriticalSections\iDefaultSpin (缺省: 1200)
控制在请求计划任务让critical section休息直到critical section有效的这段过程中,线程需要等待多长的时间才进入critical section。理论上,太小的数值会导致计划任务超载,数值太大则会导致多余的CPU循环。1200为作者认为建议的数值 – 微软建议的数值为4000,但在Oblivion里设置得这么高的话会导致性能受到影响。理想的数值取决于你的内核或者硬件线程数,CPU构架以及是否开启了超线程(Hyper-Threading)。

CriticalSections\iStaggerLevel (缺省: 5)
此参数决定 iDefaultMode = 3 (Stagger)时切换操作的周期,具体信息查看iDefaultMode的说明,小的数值表示频繁的切换,大的数值则相反,理想的数值大概为3到6之间。

下面这个是4.1里面的

Show the Content

CriticalSections\iStutterLevel (default: 4)
This parameter effecst how often critical section mode 2 switches behavior. See iDefaultMode for more about critical section mode 2. A smaller number means frequent switches, a larger number means infrequent switches. The ideal value should probably be somewhere in the range of 3 to 6.
其实与上面的 iStaggerLevel 是一样的东西。。。有点诡异,表达的意思就是指iStaggerLevel,但这边他提到的是决定mode 2的切换周期,我比较了一下,4.1与4.2的 iDefaultMode 列表下的选项是完全一样的,所以这边应该是mode 2而不是mode 3。也许是作者笔误- -|||

– 模块:LightCriticalSections
(这个模块其实可以跳过不看)Fallout和New Vegas使用另一种Bethesda制作的CRITICAL_SECTION。当前的Hook支持Fallout但不支持New Vegas。但即使是在Fallout,当前也只支持少量的hook。

LightCriticalSections\bFullHooks (缺省: 0)
使用完整hook – 不建议,当前bug超多

LightCriticalSections\bEnableProfiling (缺省: 0)
看CriticalSections\bEnableProfiling

LightCriticalSections\bEnableMessages (缺省: 1)
看CriticalSections\ bEnableMessages

LightCriticalSections\bUseOverrides (缺省: 0)
看CriticalSections\ bUseOverrides。如果bFullHooks为0,这边无效。不过bFullHooks在此版本中应该为0.

LightCriticalSections\iDefaultMode (缺省: 2)
看CriticalSections\ iDefaultMode。如果bFullHooks为0,这边无效。不过bFullHooks在此版本中应该为0.

LightCriticalSections\iDefaultSpin (缺省: 800)
看CriticalSections\ iDefaultSpin。

LightCriticalSections\iStaggerLevel (缺省: 5)
看CriticalSections\ iStaggerLevel。如果bFullHooks为0,这边无效。不过bFullHooks在此版本中应该为0.

– 模块:Heap
原版的Heap(又叫内存管理、内存分配)很糟糕,尤其是在处理多线程运行上。同时,在mod数很多的情况下,游戏时间太长也会突然变得很卡。OSR替换原版的heap,从而解决这些问题。

Heap\iHeapAlgorithm (缺省: 5)
设置要替换为何种Heap:
1、FastMM4。要求 Data\obse\plugis\ComponentDLLs 里面存在文件BorlndMM.dll,否则游戏无法开启。此Heap速度快而且稳定。
2、Windows标准Heap。取决于你的系统。XP不行,Vista与Win7还行。
3、SimpleHeap1。作者自制
4、TBBMM或称TBBMalloc。 Intel制作。
5、ThreadHeap2。作者自制,速度快。
6、ThreadHeap3。作者自制,速度快。
特别地,注意3、5和6的size是静态(固定不变)的,具体大小由于HeapSize限定。1、2和4则是自己调整size的。
这几个里面最快的应该依次为 6、4 和5。不过不同的电脑会有不同的结果。

Heap\bEnableProfiling (缺省: 0)
设置为1,可以记录Heap对性能的影响到log文档。记住:是OSR提供的Heap,原版Heap的影响无法记录。

Heap\iHeapSize (缺省: 450)
仅影响 iHeapAlgorithm 为 3、5和6 的情况。其他的Heap则会自动调整Size。此数值表示Heap用来自动分配游戏物品时所保留的空间(单位:MB)。

Heap\bEnableMessages (缺省: 0)
设置为1可以随即地记录Heap的信息到log,但大部分情况仅对Algorithm 3, 5和6有效。

– 模块:Hashtables{}
Oblivion内建了一些哈希表,用来获取对象。引擎使用的是一般的哈希表,但真正的问题是他们从来不修改哈希表的尺寸,而且设置的默认尺寸仅适用于未安装任何mod的游戏。比这更糟糕的:当哈希表过载,游戏性能便会下降。当哈希表使用不足,大量的内存又会被浪费掉,缓存一致性(cache coherency)便会下降。可惜的是,大部分哈希表都是随处内建的,同时OBSE也在这方面做了大量的研究,而对OSR作者来讲,并不是所有的哈希表他都有足够的了解,所以只能做小调整。

Hashtables\bUseOverrides (缺省: 1)
从OverrideList中使用Hashtable入口

Hashtables\bEnableProfiling (缺省: 0)
类CriticalSections\bEnableProfiling

Hashtables\bEnableMessages (缺省: 0)
类CriticalSections\ bEnableMessages

下面三个是4.1里面的,不怎么建议开启 Hashtable 的说

Show the Content

Hashtables\bAllowDynamicResizing (缺省: 0)
如果将此数值设置为1,则OSR在哈希表超负荷时会自动增加其大小。但是增加大小的方式存在问题——可能会导致跳出或者其他故障,而作者用来解决跳出的方式又会导致部分卡顿或者其他的跳出、故障。老样子,作者认为现在还不是使用的时候。

Hashtables\iHashtableResizeScale1 (缺省: 2)
Hashtables\iHashtableResizeScale2 (缺省: 4)
如果 bAllowDynamicResizing = 1 ,则 iHashtableResizeScale1 控制哈希表大小变化的最小范围,iHashtableResizeScale2 则控制哈希表最高能达到何种范围。两个数值都为2的指数,即3表示8(2的3次方),5表示32(2的5次方)。理论上,把 iHashtableResizeScale1 降低到等于1可以获得更多的性能提升,因为这么做能够修改更多哈希表的大小。iHashtableResizeScale2 的数值则应该比 iHashtableResizeScale1 的大1或者2。

Hashtables\iHashtableResizeDelay (缺省: 20)
在修改哈希表大小时让OSR停止工作几毫秒。作者的想法是既然我不能阻止哈希表在其他哈希表工作时访问对方,那么我也许可以一开始就阻止其尝试访问。所以作者推迟了这个时长,也许,这样就可以实现仅当哈希表完成操作了,另一个哈希表才去访问。但不幸的,这个在 OBSE 下无法工作,因为 OBSE 与 Oblivion 的工作方式不同,甚至OBSE工作的时候并没有使用那些哈希表。不过目前作者猜测:或许是因为 OBSE 只能从主线程访问,所以如果我这个是在主线程上工作的,那么我就不需要担心OBSE了。大概能成功吧。


– 模块:Overrides{}
包含了一些特定的信息,用来让OSR找到作者已经找到的特定的可以修改/替换的对象。

副作用与兼容性 · Side Effects & Compatibility Issues

FPS管理功能会与其他mod(如Streamline)有小冲突,不过问题不大。
(笔者注:OSR与Streamline一起使用时,要么把Streamline的FPS范围调在OSR的范围内,要么关掉关掉StreamSight。如果是前者的话,这个范围大约为5%,比如OSR是20~60,则Streamline应为21~57)
当前不存在其他的兼容性问题。

其他性能工具与Mod · Other Performance Tools & Mods

PyFFI
Streamline
Quiet Feet(建议使用Wrye Bash代替)
Oblivion Script Optimizer(老旧失修,不建议使用)
Oblivion Optimization Project(老旧失修,不建议使用)

任何人分享的 Oblivion.ini 和 sr_Oblivion_Stutter_Remover.ini 都不要直接拿来用!!
关于 Oblivion.ini 这点你应该从夜光版被淘汰的经验中得出
而 sr_Oblivion_Stutter_Remover.ini 比 Oblivion.ini 的影响更大,因为系统的不同(尤其是显存与内存的不同),mod数量的不同,以及玩家对系统的追求不同(是稳定居首位还是流畅居首位)等因素,会导致 sr_Oblivion_Stutter_Remover.ini 千差万别,说个简单的例子:heap mode 里面我们提到 6, 4, 5 是速度最快,但就是有人是 2 最快 – –

icedream

About icedream

其实我知道的东西很少,只是翻译了一些东西,悲催的是翻译过后很快就忘了。

, ,

Trackbacks/Pingbacks

  1. 常见 OBSE 插件介绍 | 上古卷轴爱好者 - 2012 年 7 月 9 日

    […] Vegas或者Fallout那么找到更新的版本,其实关于Oblivion的部分没有差别。 使用详细说明 【存在的问题】 […]