i believe it has, i ran into the problem with oblivion crashing on start, then i updated to the newest wrye bash and it launches again

I am experiencing this very thing. BUT I know, that for me at least, OSR didn't cause it. I've had this bug before I started using this mod. 40 minutes into playing the game, I experience a very sudden and drastic FPS drop (were talking like 5 FPS, where it previously was around 30) Only reloading the game will fix it, but 40 minutes later it happens again. Pretty darn frustrating...

If it is correctly installed, it will create a file named sr_Oblivion_Stutter_Remover.ini the next time you run Oblivion. This file will be located in the folder Oblivion\Data\obse\plugins.

That might explain why I was unable to find a cause.

Ah i need to install and run the mod first
Thanks mate



Btw what does this mean exactly?
If you go above the max framerate often, will this be harmfull for your computer and what is the exact effect ingame?

"If Oblivion tries to rise above this framerate for even a single frame then this plugin will force it to slow down by putting Oblivions main thread to sleep and/or burning CPU cycles in a loop that does nothing."

It means that you will not go above the max framerate. If Oblivion would otherwise do so then this either free up CPU time for background threads and other programs, or it will waste CPU time doing nothing. Don't worry about that.

Hi, SkyRanger1 and thanks for one of the best gamesmoothing tools this game has ever seen!
bet you can't improve it!
ATM it is 99.9% perfect (at least in my game )
THANKS!!!!!

Unfortunately the first alpha release of OSR 4, isn't working for me.

Removed the OSR3b6 and its ini. Put OSR4 in and launched the game. The FPS was limited to 24. Exited the game and checked the newly created OSR4 ini, it has MaximumFPS=30 & MinimumFPS=10.
Edited the ini to use iHeapAlgorithm = 1 and bHookHashtables = 0, left everything else as generated. Again in game the FPS was limited to 24. Did the same with iHeapAlgorithm 3 & 5, the game was still limited to FPS 24. Edited the ini back to iHeapAlgorithm = 1 and changed bUseOverrides = 0, game still limited to FPS 22 to 24. Did not play long enough to judge stability or smoothness.

For me OSR3b6 with iHeapAlgorithm = 1, MaxFPS=35, MinFPS=15 and all other ini values as generated provides a stable and smooth game with FPS at 35.

OS XPsp3, vsync on.

Does the difference on video card type (ATI vs Nvidia) have any effect whatsoever on the results?

I haven't checked out the latest versions, but it's certainly interesting to find out.

Hm. "FPS was limited to 24" sounds a lot like the FPS management. Which was revised slightly in this version in preparation for making it able to work at submillisecond precisions. But... FPS management is working correctly for me. Dunno what else it could be.

Unknown. OSR/FSR does not know or care anything about video cards or drivers directly, but it may interact with things that do in ways that might change when switching video cards or updating drivers. The most likely candidate for interaction with video cards & drivers would be the suppression of the critical section at Renderer+0x180 ("Renderer" in this case refers to a Gamebryo class with RTTI that labels it as a renderer) and on some settings Renderer+0x80.

Yes the FPS_management got me since the generated default has 'bAllowSlowMotion = 1', setting to 0 got the FPS back to 30.

Obviously I'm a little setting challenged, so to make sure of my settings.
For the CriticalSections = , having bUseOverrides = 1 : means it will use the 4 CriticalSection (below) in the generated OverrideList. With the iDefaultMode = 2 : means it is using the Fair mode base.

Having no clue on the syntax. Is this saying it will use these 4 as overrides?
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=???
}
}

Hm... bAllowSlowMotion=0 fixed it... that's supposed to do more about minimum FPSes that maximum. I'll take a look at it.


It's intended to work fine out of the box, and is clearly failing in your case.

The overridelist you pasted there tells it how to find 4 particular critical sections, but only 2 of them have any effect. Each of the four tells OSR how to recognize a particular critical section. The two with "Mode =" lines in them tell OSR what behavior to change from default settings for those two critical sections. For the other two OSR just uses the defaults (iDefaultMode, iDefaultSpin) just as if that critical section was not mentioned in the override list at all. If you wanted to, you could add a "Mode = 5" line to them to suppress them (which might crash, but might improve performance; some people prefer Renderer+0x80 suppressed, doing so is equivalent to iCriticalSectionSuppression=3 in the old ini) or a "Mode = 6" line to make them give priority to the main thread (which should not crash), or a "Spin = 1000" to increase their spincount. You can add more critical sections to the override list, though to get the information needed to identify them you'd need to turn on profiling first.

Well I posted with my solution too soon. Starting a new game gets the FPS 30. But if I save and exit. Then restart the game and load the save I get a FPS 24. Without changing any of the osr.ini values or anything else.
Tried with bAllowSlowMotion = 1, still reloads to FPS 24. So I changed to bManageFPS = 0, reloaded and got FPS of 60 which matches with having vsync. Put bManageFPS = 1, reloaded and got FPS 24.
Reinstalling osr3b6, I get FPS 30 in a new game and after reloading.

This is still working nearly perfect for me. I have one suggestion that would make it even better. However, I dont know if it is even possible. How about two distinct max frame rates? One for interiors and one for exteriors.

I do not know if it is even possible, but here is my reasoning. If I set it to 60 FPS and use VSync, everything looks great, as long as I am getting 60 FPS. But when I stand still and turn when outside, it gets jerky due to the sudden "change" in FPS. I have found that 30-40 FPS outside is plenty smooth enough for me. So, I have been doing tests with the max FPS. I thought I was going to settle on 30-40 FPS.

However, inside caves, ruins, houses, etc. 30-40 FPS seems jerky to me, especially when turning. I guess because everything is so much closer to your player it seems more jerky when turning.

Of course without Vsync, 30 FPS is a bit smoother for me, indoors and outdoors. But I cant stand screen tearing.

So would it be possible for the engine and your mod to recognise interiors and exteriors and set the FPS accordingly?

Ooops, double post.

Hey Skyranger! I think that this alpha version caused a crash for me.
It seemed ok, but the crashing started to appear. First I thought that it was because of some new mods in my load order, but it still happened and after I reverted to former version and deleted the OSR's ini the crash was gone.
I haven't edited anything in ini file, it was default.
Here's what weocps log says:

Sat Dec 12 20:31:50 2009	OCPS build 2009-03-28 prevented crash at offset 0x0008e7f4 (eip: 0x0048e7f4, sub_48E740).	0x0048E819. Link is faulty (0x00000014)!					eax=226bcb90 ebx=00000000 ecx=226bcb90 edx=00000001 esi=20724d38 edi=160bc4b0 esp=0012f7b8 ebp=226bcbacSat Dec 12 20:31:50 2009	OCPS build 2009-03-28 prevented crash at offset 0x0001e232 (eip: 0x0041e232, BaseExtraList::GetExtraData).	Invalid _THIS_ pointer: 0x226bcb80 (vtbl: 0x226bcb70)					eax=00000000 ebx=00000000 ecx=226bcb80 edx=00000001 esi=226bcb80 edi=160bc4b0 esp=0012f7a4 ebp=226bcbacSat Dec 12 20:31:50 2009	OCPS build 2009-03-28 prevented crash at offset 0x0008e7f4 (eip: 0x0048e7f4, sub_48E740).	0x0048E811. Link is faulty (0x6abf12a3)!					eax=6abf12a3 ebx=00000000 ecx=6abf12a3 edx=00000000 esi=1d5cdeb0 edi=00000000 esp=0012f7b8 ebp=20a52965Sun Dec 13 01:51:16 2009	OCPS build 2009-03-28 prevented crash at offset 0x0008e7f4 (eip: 0x0048e7f4, sub_48E740).	0x0048E819. Link is faulty (0x00000014)!					eax=27bec938 ebx=00000000 ecx=27bec938 edx=00000001 esi=22d321ac edi=160bc410 esp=0012f7b8 ebp=27bec954Sun Dec 13 01:51:16 2009	OCPS build 2009-03-28 prevented crash at offset 0x0001e232 (eip: 0x0041e232, BaseExtraList::GetExtraData).	Invalid _THIS_ pointer: 0x27bec928 (vtbl: 0x27bec918)					eax=00000000 ebx=00000000 ecx=27bec928 edx=00000001 esi=27bec928 edi=160bc410 esp=0012f7a4 ebp=27bec954Sun Dec 13 01:51:16 2009	OCPS build 2009-03-28 prevented crash at offset 0x0008e7f4 (eip: 0x0048e7f4, sub_48E740).	0x0048E811. Link is faulty (0xccc300b3)!					eax=ccc300b3 ebx=00000000 ecx=ccc300b3 edx=00000000 esi=27bec928 edi=00000000 esp=0012f7b8 ebp=00a04b48Mon Dec 14 00:41:36 2009	OCPS build 2009-03-28 prevented crash at offset 0x0008e7f4 (eip: 0x0048e7f4, sub_48E740).	0x0048E819. Link is faulty (0x0000003c)!					eax=243ed7dc ebx=00000000 ecx=243ed7dc edx=00000001 esi=229bd7e4 edi=160bc640 esp=0012f7b8 ebp=243ed820Mon Dec 14 00:41:36 2009	OCPS build 2009-03-28 prevented crash at offset 0x0001e232 (eip: 0x0041e232, BaseExtraList::GetExtraData).	Invalid _THIS_ pointer: 0x243ed340 (vtbl: 0x243ecea4)					eax=00000000 ebx=00000000 ecx=243ed340 edx=00000001 esi=243ed340 edi=160bc640 esp=0012f7a4 ebp=243ed820Tue Dec 15 20:14:30 2009	OCPS build 2009-03-28 prevented crash at offset 0x0008e7f4 (eip: 0x0048e7f4, sub_48E740).	0x0048E819. Link is faulty (0x00000494)!					eax=242f5e10 ebx=00000000 ecx=242f5e10 edx=00000001 esi=22740974 edi=170bec80 esp=0012f7b8 ebp=242f62acTue Dec 15 20:14:30 2009	OCPS build 2009-03-28 prevented crash at offset 0x0001e232 (eip: 0x0041e232, BaseExtraList::GetExtraData).	Invalid _THIS_ pointer: 0x242f5974 (vtbl: 0x242f54d8)					eax=00000000 ebx=00000000 ecx=242f5974 edx=00000001 esi=242f5974 edi=170bec80 esp=0012f7a4 ebp=242f62acTue Dec 15 20:14:53 2009	OCPS build 2009-03-28 prevented crash at offset 0x0008e7f4 (eip: 0x0048e7f4, sub_48E740).	0x0048E819. Link is faulty (0x00000008)!					eax=2626a0c0 ebx=00000000 ecx=2626a0c0 edx=00000001 esi=237f7d1c edi=170bec80 esp=0012f7b8 ebp=2626a0d0Tue Dec 15 20:14:53 2009	OCPS build 2009-03-28 prevented crash at offset 0x0001e232 (eip: 0x0041e232, BaseExtraList::GetExtraData).	Invalid _THIS_ pointer: 0x2626a09c (vtbl: 0x26269ff4)					eax=00000000 ebx=00000000 ecx=2626a09c edx=00000001 esi=2626a09c edi=170bec80 esp=0012f7a4 ebp=2626a0d0

Hey I just installed this along with Streamline

I get this console message in game even though I didn't press the console button

Creating new .ini file at path C:\Games\Bethesda Softworks\Oblivion\Data\obse\plugins\sr_Oblivion_Stutter_Remover.ini
Looking for old settings in C:\Users\Jae\Documents\My Games\Oblivion\Oblivion.ini
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 (@ C001D00, thread 1164) spin 2000 -> 2000
Special crit. sec. 2 (@ C001C40, thread 1164) spin 1000 -> 1000
Special crit. sec. 3 (@ E007130, thread 1164) spin 4000 -> 4000
initialize2() running in thread 1164
Suppressing CRITICAL_SECTION Renderer+0x180 (188D4890)

What does this mean? My iHeap is at 1

The download link for the alpha no longer works. At least, not for me anyways. And could somebody please quote to me this "wyre fix" for heap mode 1 that you've been talking about? I searched around but couldn't find anything. It's been awhile since I've been on the forums.

Ravin

The fix is found here:
http://www.gamesas.com/bgsforums/index.php?showtopic=1029359&view=findpost&p=15057839

and here is that fix:

 change bosh.py line 1022 from:out.packSub0(self.subType,null1.join(record.__getattribute__(self.attr)))todef dumpData(self,record,out):		"""Dumps data from record to outstream."""		strings = record.__getattribute__(self.attr)		if strings:			out.packSub0(self.subType,null1.join(strings)+null1)

@SkyRanger-1
What is the maximum number for iHeapSize?

Something is consuming more heap- memory than there is heap- memory available


with iHeapSize=250 (test- setting) I got this log
http://www.4shared.com/file/176381890/7b023c8b/sr_Oblivion_Stutter_Remover.html

65536 byte * 3999 = 262078464 bytes = 249 MB (heap- memory ?) (10 minutes Anvil with a little fight near the castle and ctd)

Hm...
The default setting for iHeapSize is supposed to be 450 on Oblivion (though 250 on Fallout).
Most of those messages should only show up with Heap\bEnableMessages set to 1 (defaults to 0).

If total heap size is an issue then...

First of all, I should point at that once it prints that message, it falls back to heap mode 2, which isn't too bad on vista and later, though it will svck hard on XP.

If the issue is simply that you have iHeapSize set to small you can increase it. There's no real upper limit in my code, but it does require that the windows default heap manager be willing to give it a single contiguous block of address space of that size. I've had no problem with 500 or so MBs on Oblivion, but Fallout gives me trouble around 300 MBs IIRC.

If you're running out of address space after what the log file claims is 250 MB on OSR at default settings (450 iHeapSize) then possibly there's a bug concerning how iHeapSize is read or used. Or how the log is printing things.

If your Oblivion is seriously using a lot of heap allocations, then possibly you might need more than can fit in the largest available contiguous memory region. In which case, one possibility would be to switch to a heap manager that can deal with non-contiguous memory regions, like (maybe?) FastMM4 (heap algorithm 1). That might let it access a little more address space that my stuff couldn't use because of fragmentation. But that little more might still not be enough. If you need a lot more instead of a little more, the only solution is to enable large-address-aware mode on oblivion.exe. If you're not on a 64 bit OS then you would also have to enable /3GB mode for your OS, which can create its own problems.

Nice work thanks

Sounds like something is wrong with the maximum FPS setting. Several things in that area changed, I'll look over for likely candidates.

You're not the first to suggest that. I don't know how to tell interiors from exteriors in this context, but there's a better than even chance I could figure it out in 10 minutes of reading OBSE/FOSE source code. I'm not thrilled with the idea though. That last time the issue came up I added some extra "smooth" modes to create a little slow motion in response to any sudden drops in FPS regardless of what the new FPS or old FPS was. My conception of MaximumFPS is as the highest framerate beyond which you just don't care much, and MinimumFPS as the lowest framerate below which you can't really fight or play much. If more complex FPS management is needed that can be added, but I'd like have a clearer understanding of exactly what and why, to avoid cluttering things up with too many FPS management settings.

Some claims of bad pointers and corrupted linked lists. No clue yet how OSR could cause either in its default configuration.


That text itself is normal for OSR going about its business. What's not normal is the console popping up without you pressing ~, unless you have debug text on (the tdt console command). Another detail that's not normal is that you say you're using heap mode 1 but it says you're using heap mode 0.

The link should now work again.

@SkyRanger-1

iHeapSize=450 is the normal setting

Oblivion fills the heap until it's full and then ctds (min. ~ 30 minutes, max. ~ 1hour 10 minutes).

iHeapSize=250 (bEnableMessages = 1) was for testing, I want to know why the game ctds and how I could play more than ~ 1 hour (most less than 1 hour)

I tried iHeapSize=1000

=> more possible allocations (~ #15200 ?), more time for gaming


I am using Windows 7 64 bit and oblivion.exe, obse_loader are patched with "large adress aware flag". Oblivion can use 4 GB (and sometimes it needs so much, older OBSE 18 beta).

FastMM4 is less stable.

You are in to WTF territory. I don't know how heavily modded your Oblivion is, but my presumption is that something is leaking. I haven't watched my Oblivion install too closely, but I think it tends to go to something like 350 MBs of heap in longer game sessions. My game is relatively lightly modded for this forum but still has a more mods that I can easily keep track of, including a few fair sized ones (mainly OOO).
Your log file with the 250 MB heap shows most of the memory allocated to pools for size #12, #13, and #14. I believe those currently correspond to 513-768 bytes, 769-1024 bytes, and 1025-1536 bytes respectively. I don't know what Oblivion objects would fall in that size range, so maybe that's not useful information.

The CTDs might be my fault... overfull heaps are not a condition I test much, so there could easily be bugs there I haven't noticed. It's supposed to mostly just act like heap algorithm 2 at that point. Though if you run out of space in my heap due to an appetite for an infinite amount of memory then eventually even the windows heap algorithm won't be willing or able to give you any more allocations, and then you will CTD anyway.

Anyway, my suggestion is that you either figure out what is gobbling memory (maybe a particular mod or something is responsible?) and kill it, or you get used to restarting Oblivion every half hour or so.

edit: In theory at least, with a LAA Oblivion.exe and a 64 bit OS, you should be able to go up to about 2000 for iHeapSize. Past 2047 I think some of my code will malfunction, though that could be fixed if there was a reason. But the address space itself only has room for 4096 total, and much of that will be unavailable because it will get used by oblivion.exe and other dlls, or just because of fragmentation.