Oblivion Stutter Remover 3 beta 6

Oblivion Stutter RemoverがUpdateされていて、ついでにSource Codeも公開されている。前のVersionでは我が家の環境では、かなり怪しげなSide Effectsが出たので、Stutterは軽減できるけれど、Game Mechanismそのものがいまいち不安定というか不定な動作をするという、結構本末転倒気味な状態だったけれど、さてUpdateされたVersionではどうだろうと、Downloadしてみる。

DocumentsとSource Codeを追いかけていく限り、動作としてはOblivion.exe本体のHeap (Memory Allocation/Memory Table Management)のRoutineと、CRITICAL_SECTIONをIn-Memoryで乗っ取るというかそんな感じのPluginだ。いわゆるGame Trainerなどと同じGame Memory Hack系のPlugin。

MemoryのControlは本来OblivionのEngine本体が、OSから割り当てを受けて、一度獲得した(獲得できた)Memory領域は内部のTableに獲得Addressの一覧を登録して使いまわす、という感じの動作をしているんだと思う。だからGameを起動したら、使用するMemoryは基本的には増大していく。使いまわせる限りは使いまわすので、急激な増加ではなくある一定のラインからは緩やかに増加して、PeakのMemory使用量を保持し続けるという感じ。Peakがどこに来るかは、それこそMODで追加されるObjectsやらいろんな要因があるので、なんともいえないところ。

最終的にはApplicationの使用できる上限(2GB)にあたって、Memory Map Errorが発生することになる。どうも感覚的にはこれ以上Allocate出来ない、という事態は想定されていないようで、その辺でCrashしている感じ。普段あまり長時間連続でPlayはしないけれど、休日に長い時間Playすると大体どこかで落ちちゃう。その時にTask ManagerでKillしようとするとMemory使用量は大体1.95GBとかそんな感じのときが多い。

以前、Visual Studio付属のeditbin.exeを使って、LARGE ADDRESS AWAREのFlagをSetしてみたことがあるけれど(いわゆる、3GB Enablerというやつ。出所の知れないBinaryをDownloadしてくるよりはVisual Studio付属のものを使うほうがいいだろう。)あまり状況は改善されなかった。2GBを超えてMemoryをAllocateしているような感じではあるけれど、Crashする頻度が増大する。あんまり確信のある推測ではないけれど、BethesdaのMemory Managerで、Allocate済みMemoryのAddressを扱う変数が、どっかSigned Intで定義されていて、Addressの値が怪しいことになっているのかもしれないという感じだ。

話を戻すと、このHeapのModeを定義するのがINI File中のiHeapModeの値、

この値に、それぞれ以下のModeが割り当てられている:

0: Vanilla (OriginalのHeap Routine)
1: FastMM (BorlandMM.dllが必要)
2: Windows heap (Windowsにお任せしちゃう)
3: SkyRanger-1氏による “Simple Heap Manager”
4: FastMMのDebug Mode (BorlandMM.dllが必要)
5: SkyRanger-1氏によるyet another “Simple Heam Maanager”

OriginalのHeap Routineは何か問題を抱えているような気もするので、残りから個人的に選ぶとすれば1(FastMM)か2(Windows Heap)だろうか。Windows HeapはXPではSlowとされているけれど、Vistaではそれなりに早いとReadmeには書いてある。

どっちにしようかちょっとだけ悩んで今回はFastMMを使用してみることに。ということで、iHeapModeは1に設定。[General] Sectionのほかの設定では、iSleepExtraを-1に設定。Main ThreadをSleepさせるのはいまひとつ不安だ。

続いて、[CritialSections] section。ここでは、Critical Sectionの挙動を定義する。これはiCriticalSectionModeの値で定義されて、それぞれの値は以下のとおり:

0: Vanilla – OriginalのCritical Sectionをそのまま使用。
1: Spin CountsのOverride
2: Spin CountsのOverrideとCritical Sectionの最適化
3: Debug Mode

ResourceのLockをする前に試行する回数の設定というか、Multi Threading関連の設定だと思えば間違いないところ。OblivionがMulti CoreなCPUの恩恵を受けないと一般的に言われているけれど、これは恐らく、Spin Countsが基本的には0、Single CoreなCPUを対象としたLockingをしているからじゃないかというところ。

今となってはかなり珍しいと思うけれど、Single CoreなCPUを使っているなら、ここはOverrideしても意味はないので、設定は3以外どれを選んでも同じだと思う(Mutli Coreでなければ、どんな値をSpin Countsとして設定しても結局は0となる)。少なくともDual Core、あるいはHyper ThreadingなCPUを使っているならば、それなりに意味が出てくるところか。

Spin Countsが設定されていれば、Lock待ちでKernel Modeに突入せずにSpin Loopを試行して、試行した回数以内にLockの獲得に設定すればそのままLockを取りに行くという動作をするはずである。Spin Loop中にLockが取れれば、わざわざKernel ModeでWaitせずにすむので基本的に動作は軽量になる…という理屈のはず。ということで、ここはとりあえずDefaultのまま2としておく。

続いて、このSectionで重要なのは、iCriticalSectionSupressionの設定となる、ここはどのBitを立てるかで判定しているようなので、設定に影響を与える値は0,1,2,4,8,16,32となる。(それぞれのBitの組み合わせも可能なので、0-63の範囲でBitの組み合わせを計算した値をSetする)Critical Sectionへの移行を抑制するかどうかの設定で、高いビットを立てるほど、抑制されるCritical Sectionが多くなり、Critical Sectionへ突入しないことにより、Performanceは上がるという仕組みだ。ただ、Critical Sectionに入ってResourceをLockすると言うのは、Multi Threadingの安全性を担保するひとつの手段でもあるので、個人的にこの設定は0、一切Supressionしないという設定にしておくことに。

で、FastMMを使う部分、そしてFastMMそのものをざっと見た限り、Addressを格納する変数は当たり前ながらUnsigned Int32で定義されているので、これなら何も問題はないだろうということで、Oblivion.exeのLarge Address Aware Flagも立ててみることに。64 bit OSなので、LAA FlagがSetされていれば、4GBまで使えるようになる。

INIファイルの設定はこんな感じ。この3つ以外はMinimum/Maximum FPS程度を気にしておけば大丈夫だろう。そもそも、設定として存在していても、まだ意味の無い設定値とかもあるし。

とりあえず、この設定で今日ちょっと遊んでみた限りは怪しい動作にはまだ遭遇していない。来週末あたりもうちょっと時間をかけて遊んでみないと何ともいえないところではあるけれど。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中