An update: I have been playing for hours now with resizing hashtables and I never crashed.

Hi all,

the strange "a" bug is not related to Oblivion Stutter Remover. It is a known bug in No More Annoying Messages. The fix is found at http://www.tesnexus.com/downloads/file.php?id=4988

thanks
a

iSchedulingResolution was accidentally being ignored in OSR4. Not just the setting but the feature itself wasn't enabled. I don't know if it's important or not, but it will be back in in the next OSR4 alpha.

alexkapi:
Whether or not you get problems from the current hashtables code depends, at least partially, on what mods you are using. The hook will, at the very least, cause the cell ref walking OBSE script functions to return incorrect values or crash - but only if called during a 20 millisecond window when OSR is resizing the particular hashtable that function looks at, and, I hope, only if OSR resizes it from a background thread.
In the next version I'm going to make OSR try to only resize hashtables from the main thread. That will make the stutter induced by hashtable resizing more noticable, but might, possibly, eliminate the conflicts.

Asesino:
Doh. I added a hook and all to suppress the display of that message if the message was 1 character long without realizing it was just a typo in the mod, not a flaw in Oblivion.exe. I will remove my hook prior to the next release.

Ooo... thanks for that! (mumbles... I still say that the sticky message problem showed up before I applied any no more message mod... who knows what went wrong. :shrug: )

I hope all I need to do is change something in the ini file.
My Conscribe log is filled with this type of info:

hook mode 1: using main GetTickCount callcrit_sec_mode 3MemoryHeap Optimization Mode 0: Not optimizing MemoryHeapcritical section b32b80 overriden to spin 1500critical section b32b80 overriden to spin 1500Memory       1    5063 0.198ns 1Special crit. sec. 1 (@ A000030, thread E34) spin 2000 -> 2000Special crit. sec. 2 (@ A001F60, thread E34) spin 1000 -> 1000Special crit. sec. 3 (@ C008F70, thread E34) spin 4000 -> 4000Renderer     1     62k 0.016ns 1initialize2() running in thread e34Suppressing CRITICAL_SECTION Renderer+0x180 (18985CB4)Game Instance : 1 | Time : 01-06-2010 08-22-31 PM==================================================Unk4         1    5722 0.175ns 1Memory     128   2342k 0.055ns 1Unk6         1    4121 0.243ns 1Unk4        68    180k 0.377ns 2Unk4        71    182k 0.390ns 3Other        1     11k 0.091ns 1Memory     256   4332k 0.059ns 1Unk4       128    530k 0.241ns 3Memory     384   6944k 0.055ns 1Renderer   108   1450k 0.074ns 44time  79981 thread 03cc:3 waited on CS 18985bb4 (spin 500) for   44 ms (init 0)Renderer   129   1496k 0.086ns 44time  80171 thread 03cc:3 waited on CS 18985bb4 (spin 500) for   21 ms (init 0)Renderer   256   4194k 0.061ns 44Renderer   384   6808k 0.056ns 44Memory     512   9618k 0.053ns 1qqqBye

Here is a copy of my ini:

Master = {	_comment = You can turn on or off each distinct feature from here.	bManageFPS = 1	bHookCriticalSections = 1	bHookLightCriticalSections = 1	bHookHashtables = 1	bReplaceHeap = 1	bLogToConsole = 0	bFix64Hertz = 1	iSchedulingResolution = 1	bFastExit = 0	bFlushLog = 1	iMainHookPoint = 1}FPS_Management = {	_comment = Basic FPS stuff, switches to slow-motion on low FPS; in the past this has occaisonally produced bugs like the NPCs-dropping-dead issue; the issues are believed to be fixed but if you suspect you are having related problems you can try disabling bAllowSlowMotion which is the main suspect for any problems relating to FPS management	bAllowSlowMotion = 1	MaximumFPS = 40	MinimumFPS = 20	iSmoothFrames = 0	iSmoothMode = 0	iSleepExtra = 1	bFPSConsoleSPAM = 0	iSchedulingParanoia = 1	iHardMaxFrametime = 200}CriticalSections = {	_comment = CS stuff helps both Oblivion and Fallout significantly	_comment = most of the benefit comes from the Renderer+0x180 suppression (see overrides below)	_comment = modes: 1=vanilla, 2=fair, 3=stuttering, 5=suppressed, 6=prioritize-main-thread, 7=deprioritize-main-thread	bEnableProfiling = 0	bEnableMessages = 0	bUseOverrides = 1	iDefaultMode = 3	iDefaultSpin = 500	iStutterLevel = 4}LightCriticalSections = {	_comment =LCS stuff is for Fallout only, no effect on Oblivion; most settings are similar to Critical Section settings	bFullHooks = 1	bEnableProfiling = 0	bEnableMessages = 0	bUseOverrides = 1	iDefaultMode = 2	iDefaultSpin = 500	iStutterLevel = 4}Heap = {	_comment = Heap replacement can produce MAJOR improvements in performance on Oblivion, only moderate improvements on Fallout	_comment = It crashes instantly on Fallout, is moderately buggy on Oblivion	_comment = Algorithms: 1=FastMM4 (requires external dll), 2=Microsoft (slow on XP), 3=SimpleHeap1, 5=ThreadHeap2	iHeapAlgorithm = 5	bEnableProfiling = 0	iHeapSize = 450	bEnableMessages = 0}Hashtables = {	_comment = This stuff is still new.	_comment = The dynamic resizing option is still buggy I think.  May be impossible to do right.  	bAllowDynamicResizing = 1	bUseOverrides = 0	bEnableProfiling = 0	bEnableMessages = 0	iHashtableResizeScale1 = 3	iHashtableResizeScale2 = 5	iHashtableResizeDelay = 20}OverrideList = {	CriticalSection = {		CallerAddress = 0x701748		comment = Renderer+0x180, recommendation=suppress (mode 5)		Mode = 5	}	CriticalSection = {		ObjectAddress = 0xB32B80		comment = MemoryHeap CS, recommendation=stutter (mode 3)		Mode = 3	}	CriticalSection = {		CallerAddress = 0x70172A		comment = Renderer+0x80, recommendation=???	}	CriticalSection = {		ObjectAddress = 0xB3FA00		comment = Unknown4, recommendation=???	}}[General]MinimumFPS=20MaximumFPS=30iSmoothFrames=0iSmoothMode=0iSleepExtra=5bFix64Hertz=1bFPSConsoleSPAM=0iSchedulingParanoia=2iSchedulingResolution=1iHardMaxFrametime=200iHeapMode=0iHookMode=1[CriticalSections]iCriticalSectionMode=3iCriticalSectionSupression=1iDefaultSpin1=500iDefaultSpin2=500iMemorySpin=1500iMemoryUnfairness=4iExtraDataSpin=-1iUnknownSpin1=-1iUnknownSpin2=-1iUnknownSpin3=-1iUnknownSpin4=-1iUnknownSpin5=-1iUnknownSpin6=-1iSpecialSpin1=2000iSpecialSpin2=1000iSpecialSpin3=4000

I've zero'd anything that looks like it allows or dumps messages, but still I get all that spam.
Is there an entry that can shut off the spam? It's a pain in the ass to wade through all that when you're trying to trobleshoot mod interactions via the console.
If not, I hope you'll consider putting some type of blocking entry in the next release.
Thanks for the great addon.

aellis:
You are using some version of OSR3 with an ini file intended for OSR4. To avoid those messages you need to use OSR4. Try redownloading ftp://71.115.222.171/sr_Oblivion_Stutter_Remover.dll

Dude, I know you've probably been told this a thousand times, but I'll do it anyway: your work is brilliant, thank you! OSR really saved me from a heart attack: I built a new computer some 9 months ago (GPU Ati HD4890, nice AMD PhenomII X3 720 CPU, 4Gb of RAM, etc.), then installed a cocktail of QTP3 original&redimized (bearing in mind the 1Gb limit of VRAM), but the game was still sluggish, with drastic fps drops and horrible stuttering (mostly in the forested areas), some leading to CTDs... I did all the tweaks and tricks I was aware of, then decided to install OSR (note I've also installed OBSE especially for this!) - and it was the best decision I took ever since I decided to walk instead of crawl (and that's like almost 4 decades ago!).

I'm using the default settings, except for the max fps (which I changed to 40) and everything goes smooth and nice, with no CTD ever since installing OSR (nice side-effect, eh? ). So, thank you again for this excellent mod (as the rest of your work is as well)!

Cheers,
PKR.

DOH! :facepalm:
Thanks

ftp://71.115.222.171/sr_Oblivion_Stutter_Remover.dll
There is a new OSR4 alpha up. Several things have changed, though nothing major:
1. The dll file now has a version number (4.0.5 for this release). You can see this by right-clicking, selecting properties, somewhere in there. No guarantee that the version number will be correctly updated with each release though.
2. iSchedulingResolution was fixed. This used to work back in OSR3, but got broken in the switch to OSR4. I think this may have been responsible for some of the issues people were having with MaximumFPS acting like it was lower than it was.
3. Hashtable dynamic resizing was tweaked. It *might* not cause some OBSE script commands to malfunction anymore.
4. LightCriticalSections no longer shows up in the ini file (LCS stuff has no meaning on Oblivion, it's for fallout only).
5. Default heap algorithm changed from 1 to 5. No reason. Heap replacement still defaults to being disabled.



Painkiller_rider: Yep. OSR rocks.

Is this the same version you linked to for download in reply to my **not** problem?

It looks like the upload didn't work. It's the same version as before.

Whoops, sorry. The right version is there now.

Great,thanks!:)
I was experiencing some odd instabilities with OBSE functions, but had no clue it might be OSR.

The dynamic hashtable resizing stuff is disabled by default, but it does boost FPS or something so some users turn it on. If certain particular hashtables get resized during the same frame or so as an OBSE script calls some kind of ref walking function (say GetFirstRef or GetNextRef) then bad things will happen. I think there might be another variant of the same problem triggered by slightly different circumstances.

Hopefully that is fixed now, as I tweaked the resizing code to only run if it's in the main Oblivion thread, so I should only screw up OBSE stuff if it's running in a background thread, and I don't think any of the things this conflicts with runs in background threads. Maybe.

Not sure it's useful to anyone but me (or even to me), but I just attached some general profiling code to Oblivion and the results are:

In my test runs, Oblivions main thread unsurprisingly spent most of its time in Oblivions main function (40D800), which in turn seemed to want spend a large percentage of its time in a call to 40D4D0. 40D800 called 40D4D0 once per frame.

40D4D0 in turn spent 80+ % of its time in a call to 40C830. Oddly enough, it called that less than once per frame. The implication is that some frames are dramatically slower than others based upon whether or not 40D4D0 decides to call 40C830.

40C830 in turn spent 90+ % of its time in a call to 70C0B0. 40C830 actually calls 70C0B0 twice each time it runs, but only the first one consumes any time. 70C0B0 in turn spends most of its time doing some sort of vtable call.

None of those functions were called by any thread other than the main thread in my test runs. Overall that 70C0B0 call seemed to account for somewhere between 20 and 50 percent of my main threads execution time. I talked to ianpatt of OBSE, he said that that 70C0B0 call looks to him like it's doing some kind of visibility culling involving sorting the scene graph by alpha and Z or something.

That's odd..
So, if 40D4D0 calls 70C0B0 twice, but only spends time with the first one, it should be pretty much the same as 70C0B0, right?
Still it slows down the process..

I think ianpatt implied that the difference between the two calls to 70C0B0 is it's applying two different culling algorithms or something to the scene graph or visibility list or something - the vtables that 70C0B0 spends its time calling are different for the two different calls, so it's not terribly surprising that they take different amounts of time, though the magnitude of the difference seems a bit large (about 500 to 1). Other calls besides 70C0B0 account for about 7% of 40C830 execution time on average.

Further details: The frames where 40D4D0 does not call 40C830 correspond roughly (but not exactly) to the frames spent at the main menu. When I spent most of my time in-game, unpaused, etc, the percentage of time spent in 70C0B0 rose to about 60%. When I spent most of my time at the menu and loading, only playing the game for a fraction of a second, it fell to 0% exactly.

I've just installed the Oblivion Stutter Remover, and now my game crashes at startup. I'm not sure if i was meant to do anything special? I just extracted it into my oblivion directory. (I checked everything is in the right place). Was I meant to do anything else? (And i have the letest version of obse).
Edit: Just read the mainpage, and it says something about changing streamline's settings. Is this neccesary for this mod to work?

It's not necessary to change streamlines settings. Are you using OSR 3 beta 6, or an OSR 4 variant? Can you post the contents of your OSR log file (sr_Oblivion_Stutter_Remover.log in the Oblivion folder)?

It says this:

hook mode 1: using main GetTickCount call
crit_sec_mode 2
MemoryHeap Optimization Mode 0: Not optimizing MemoryHeap
critical section b32b80 overriden to spin 1500
critical section b32b80 overriden to spin 1500
Special crit. sec. 1 (@ C0015D0, thread 1A98) spin 2000 -> 2000
Special crit. sec. 2 (@ C001510, thread 1A98) spin 1000 -> 1000
Special crit. sec. 3 (@ E008DB0, thread 1A98) spin 4000 -> 4000

And I'm using beta6. First time I've installed it.

I can see no reason for you to have any trouble there. Does removing OSR (moving the OSR dll out of Data\obse\plugins is sufficient to disable OSR) fix this?

yes it does. That was the first thing I did to make sure that it was actually that causing the problem.

Edit: So no advice then? :brokencomputer:

I would really like to use this ...

I can't recall ever hearing about anything like this. I'll pull up the OSR 3 beta 6 source code...
Any chance you're using an exotic version of Oblivion? It shouldn't make a diffference, but just in case.
Any chance you've put BorlndMM.dll in to Oblivion\Data\obse\plugins? It's supposed to be in Oblivion\Data\obse\plugins\ComponentDLLs, if it gets directly in to the plugins directory then OBSE would try to load it as an OBSE plugin, which would probably just silently fail but could conceivably cause problems.

You could try changing iCriticalSectionSuppression from 1 to 0 in the ini file. No one has ever reported an error caused by setting it to 1, but in theory it's possible for it to cause problems if you have sufficiently unusual graphics drivers or something. That can be found in Oblivion\Data\obse\plugins\sr_Oblivion_Stutter_Remover.ini

You could try changing iCriticalSectionMode to 0. If that fixed it, it would at least narrow down the possible problems. Likewise, you could try changing iHookMode from 1 to -1, disabling other pieces of OSR. Those are also in the OSR ini, Oblivion\Data\obse\plugins\sr_Oblivion_Stutter_Remover.ini

You could try downloading an early version of OSR4. Since I have no clue what's causing your problem I have no real reason to believe that would help, but it is a fairly different codebase so there's a significant chance that whatever is causing the issue would be have changed. edit: OSR4: ftp://71.115.222.171/sr_Oblivion_Stutter_Remover.dll

I changed iHookMode to -1 and left the other one as it is. It now seems to work. What does that do then?

Try iHookMode=0 then. iHookMode=-1 disables FPS management and has the side effect of disabling 2nd stage initialization, which in turn prevents critical section suppression from working. Given the iHookMode=-1 with no other changes prevents crashes for you means that one of those is failing catastrophically. iHookMode=0 will turn 2nd stage initialization & critical section suppression back on while leaving FPS management disabled.

edit: I'm going to have to create a new thread soon