3 should perform at least close to as well as the others on Vista and later OSes.

Not exactly, but it might enable things that help performance.

I'll be around for TES:V. Probably.
http://xkcd.com/323/

The first alpha release of OSR 4:
ftp://71.115.222.171/sr_Oblivion_Stutter_Remover.dll

Uses a completely different ini file format. Uses the same codebase as Fallout Stutter Remover - in fact, at the moment the default ini it generates includes a section that has no effect for Oblivion at all, only for fallout.

The ftp link doesn't seem to be working.

Oops. Fixed.

this is absolutely fantastic. tried the new alpha with FastMM4 Heap and it KILLED stuttering for me compared to the latest beta

Skyranger-

Been meaning to thank you for the fallout3 release as well - so thanks for both.

In the F3 release you have fast exit as an option to turn on or off. IS that the case with the new OSR and if so can I now ditch the original Fast Exit 2?

Next ... do you have heap recommendations for Vista? The new format is still taking some getting used to for these untrained eyes.

Like what are the safer versus riskier settings - form what you figure.

thanks

Critical Section iDefaultMode = 5 completely hangs my computer when when I try to load a savegame. I switched to iDefaultMode = 6 and it works fine. Everything else works great, including dynamic hash table resizing.

I'm using your heap 5 and have no stutter at all. It's working great!

Yes, the FastExit option works on Oblivion as well. It's ini the ini file as Master\bFastExit - that is, it's the setting labelled "bFastExit" in the section labeled "Master". It defaults to disabled.

The heap algorithms still use the same numbering scheme (1=FastMM4, 2=Microsoft, 3=SimpleHeap1, 5=ThreadHeap2), though that settings is now Heap\iHeapAlgorithm ("IHeapAlgorithm in the section "Heap"). I believe it is set to default to 1.
The main change is that there is now an additon on/off switch Master\bReplaceHeap. That setting must be set to 1 or all heap replacement code will be disabled.
Other changes to heap stuff include:
Heap algorithms 3 & 5 now have a settings Heap\iHeapSize which determines the number of megabytes they reserve (defaulting to 450 on Oblivion, 250 on Fallout). Vanilla Oblivion reserves about 200 MB IIRC. Algorithms 1 & 2 ignore this setting and dynamically change how much address space they use.
I think heap algorithm 5 also had a few more optimizations made to it.
They now a bit of text output that can be switched on/off by Heap\bEnableMessages, but most text output for them remains a compile time option.

The two main new features in this version are the "hashtables" stuff and the "overrides" stuff.

Hashtables:
You can turn on hashtable resizing by setting both Master\bHookHashtables and Hashtables\bAllowDynamicResizing to 1. This should improve performance, though I don't know if it will be enough to notice or not. The code involved is a bit of a hack though, so its defaulting to off at the moment.

Overrides:
In previous versions of OSR, certain critical sections were singled out for special treatment. In those versions though, WHICH critical sections were singled out for special treatment was hardwired. Specifically, the critical section I've called Renderer+0x180 defaulted to being suppressed, and a critical section used internally to Oblivions memory heap was tweaked to "stutter" (or did I call it "stagger"? whatever), and a few other critical sections (most importantly Renderer+0x80) could be suppressed but default to acting like all the other critical sections. Likewise, there were a few specific critical sections that you could manually set the spincounts for, all the rest used whatever you set the default to in the ini.
In OSR 4, you can specify any critical section you want in the ini file, and specify a mode and/or spin for just that particular critical section. If there is no override for a critical section then it will use the spin specified in CriticalSections\iDefaultSpin and the mode specified in CriticalSections\iDefaultMode. One of the modes will suppress the critical section. One will make it "stutter". The default configuration includes overrides to make it act like the previous versions (ie suppress renderer+0x180, make the heap critical section stutter).

Critical Section iDefaultMode = 5 means for it to suppress literally every single critical section in Oblivion except the two who have mode overrides in the OverrideList section (ie hundreds, maybe thousands of critical sections). It's supposed to crash on that setting, though it's not supposed to take windows down with it.
Is 6 better / worse / the-same-as the default value of 2?

critical section mode 5 crashes here as well when loading a savegame. 2 works fine.

They're just about the same. I can't really see any difference.

Am I right in guessing that 450 is the default heap size for OSR3, heap 5?

Will muddle around with the info you've provided and test things out. Hoping there is improvement re intermittent/stuck messages.

Thanks for the new alpha!

Heap size for OSR3 heaps 3 & 5 was 500 MB for the later versions IIRC. It was lower for earlier versions. Setting it to less would free up address space for... whatever other purpose Oblivion uses address space for.

The various bugs associated with heap replacement are unlikely to have been fixed. IIRC the main change to heap 5 was a tweak to improve... "temporal cache locality" or whatever you call it. I believe that the heap replacement bugs are associated with 2 or more of the following possible issues:
A. Oblivions heaps locking hiding race conditions that occur after memory operations.
B. Oblivion sometimes going past an allocated blocks end or begining or otherwise using a bad pointer in a manner that just happens to work out fine on their heap. Possibly during startup only.
C. I think Oblivion keeps track of memory available / used by pool internally, which I do not update properly... I think Oblivion only uses that for tdt purposes or something, but possibly some code reacts to some memory condition in there that I didn't notice.
D. Possibly bugs in heap modes 3 & 5. But not likely bugs in modes 1 or 2. And certainly not the same bugs across all of them.
E. Conceivably Oblivion doing something really strange with pointer comparisons, like assuming that larger block addresses always correspond to larger block sizes (which they do IIRC in Oblivions heap). That would be rather contrary to their general coding style, but maybe they could have done it by accident?
F. Something I haven't thought of. Or thought of and forgot.

Woah! :blink:

The new ini file is a bit different format-wise!

Thanks so much for this; you've made the game so much more playable for me and so many others. I am so glad I was an early adopter back when it was FPS Capper.

I'll be back with feedback and/or further thanks when I've experimented a little.

Vac

Totally funny! "Remember Windows ME? I knew it!" :lmao:

Oehh, gonna try this baby out. And ofcourse wondering how the ini can have a completely different format, I mean, an ini always uses the same format, right? Or do you mean it in regards to the buildup in sections and such? Then again, it doesn't really matter to me. Awesome work and thanks for posting it here, I don't visit the Fallout 3 forum much so I wasn't really aware of this new alpha.

[edit]Oh ok, I guess an ini can have a very different format. [/edit]

-kyoma

has the wrye bash fix for OSR been included in Wrye Bash V275? i swapped in the new file and now Wrye bash wont open.....

Wanted to say thanks for all your effort Sky Ranger. This has made Oblivion smooth and very playable. I was using the version posted on the TesNexus, but did some research and found that you are working on this again.

I can say that for my system, the dynamic option works like it is supposed to work. Bravil is a tough area usually. FrameRate goes from 60 (Vsync) down to low 30's. Which is playable, but it is jerky if you make a quick turn because of the abrupt change in frame rate.

With the dynamic option enabled and averaging feature of this new version, it is now much smoother when turning inside Bravil and Cheydinal as well. I am going to investigate the options for the dynamic portion to see if I can get that last bit of jerkiness out. But even if I dont, its already much better than the previous version for me, which is saying a lot, because prior to finding your original stutter remover I was ready to give up on Oblivion. Just too choppy.

Q6600@2.4 (stock)
3GB Ram
9800GT
Vista Home Premium
Latest stutter remover with default settings except for dynamic option and I have max FPS set to 64.

Seems to run a bit smoother at 64 compared to 60.

Thanks again for all your hard work. I found the original threads here when you started this and read over the past few months' posts from you and your progress. Then while reading I was afraid you had quit working on it, but luckily discovered this last thread. There really is no comparison to vanilla with your original plugin, this one makes it that much better though. Cheers!!

Donnie

P.S. Running QTP3 and it runs 10x better than vanilla with this plugin, nothing more to say.

If it runs smoother at 64 than 60, check your bFix64Hertz setting in the ini. It was set to 0 by default in beta 6 due to confusion on my part, it should be set to 1.

Something I've never got is when I lock the game at 30 fps, it feels more like 15. Any other game I play at 30 is smooth enough, but Oblivion gets very noticable jerky turning. It really shouldn't feel like this at 30. Is there any way to fix it?

It is set to 1 in the .ini that was created with the latest version. I moved my old .ini and the old .dll file and pasted the new one. Then started Oblivion and a new .ini was generated for the stutter remover. It is set to '1' in the created .ini. Could be perception only though because it runs smooth either way now, but "seems" smoother with it set at 64. The dynamic option really smooths out the transition from high FPS to lower for me. That was the only stutter I had left, even with the old version. But now, most of that stutter is gone as well.

You mentioned before about the difficulty in developing this in another thread I think. Citing "wild ass" guesses. Although I have not done a lot of play testing to look for bugs yet, I can say that your wild guess with regard to the dynamic adjustment was a great guess and you are definitely on the right track. Prior to this I was content with setting the frame rate to 30 so it was more consistent. But now the drop is not as noticeable and I prefer to leave it set to a high frame rate for the extra smoothness in the areas that I get high frame rates. It is like a completely different experience since discovering your stutter remover, and now it is near perfect, especially considering what all is being rendered and accounted for at any one time in Oblivion. Bethesda should hire you!!

I am going to experiment with the scale settings for the dynamic portion. Will report back if I find anything of note.

You're not the first to say it, but Bethesda keeps not hiring me for some reason. Possibly the fact that I end up doing this for free might be related.
Wait... you talking about the "smooth" settings? iSmoothMode and iSmoothFrames? They were added as an experiment but never seemed very popular... I think their impact may depend upon subtle issues of graphics driver settings.
Looking at the code it looks like:
Smoothing is enabled if iSmoothFrames >= 2 and iSmoothMode is 0, 1, 2, or 3 and, on OSR 4, if bAllowSlowMotion is 1.
When smoothing is enabled, frame time is low pass filtered, meaning that slower than average frames get a little bit of slow motion and faster than average frames get a little bit of fast forward, but it averages out to exactly the same amount of time that would pass normally (which helps keeps lips in synch on talking NPCs).
If iSmoothMode is 0 or 2 then the low pass filter is a geometric decay shaped convolution. If it's 1 or 3 then the low pass filter is a rectangle shaped convolution. I don't know which would be better.
If iSmoothMode is 0 or 1 then an addition effect is added that is a little like a dynamically determined MinimumFPS: frames that take significantly more time than the recent average will get a little extra slow motion applied to them, in addition to what the low pass filter likes to do. This will not be averaged out, and can thus pull lip animations out of synch with the voices in conversation if you have stuttering during conversations, but may be better than a simple low pass for dealing with single frame stutter events.

30 feels fine to me on my system. Without a better idea of why yours feels jerky I can't say much. Though, do glance at your bFix64Hertz setting, it should be one and some versions mistakenly default to 0... if left at zero Oblivions method of measuring time adds a little extra jerkiness to the game, mostly only noticable at higher framerates. You can try playing around with the smooth settings, but IIRC people mostly didn't think they helped.

Actually I was referring to the Hash table area. I assume those are valid for Oblivion too, not just Fallout? I hope so, because I changed it to 1 for allow dynamic resizing and it seems to have smoothed out the frame rate even more.

Oh, ah. Too many things in this plugin, I can't tell what's going on anymore, I thought I might have called some of the later additions to smoothing a dynamic MinimumFPS or something like that.

Yes, hashtable resizing is valid on Oblivion as well. I haven't gotten around to trying to test it yet on Oblivion beyond the does-it-crash-right-away stage, which is part of why it is off by default. It should help Oblivion a lot more than it helps Fallout, as Oblivion has worse default sizes for its hashtables than Fallout does. The locking I do on the hashtables to let me resize them while other threads may be accessing them is an ugly hack, but (fingers crossed) it may be good enough. Be warned that the locking process currently used may actually CREATE stutter during the resizing process, but resizing should mostly be limited to the first minute or so after Oblivion starts up.

edit: For anyone reading this, to (hopefully) get a performance boost from the hashtables code atm you need to have both Master\bHookHashtables and Hashtables\bAllowDynamicResizing set to 1.

Well, I haven't had time to really put this through its paces, but with the heap replaced by Borland and the dynamic hash table rezizing turned on I can say that I am quite amazed by the difference I observed. Or really *failed* to observe. I just didn't notice stuttering, though I wasn't in a challenging area by any means. I'll see what happens when I go somewhere with more to load between cells. Nevertheless, I had trouble noticing that there *was* any stutter and that's great!

Cheers!

Vac

On further thought, I'm pretty sure that dynamic hashtables resizing is impossible to do right, or at least impossible without tweaking OBSE and even then no guarantees. The current implementation may work well enough but I'm pretty sure there are a couple of OBSE script functions (GetFirstRef/GetNextRef, possibly others) that will yield strange results if called at the wrong moment while the wrong hashtable is being resized.

So, for the moment consider the hashtables code as more proof-of-concept that can show how much performance improvement larger hashtables would give Oblivion. I'll come up with a better approach for the next version.

Where can you edit the settings of OSR?