527 replies to this topic

[frankiemiddlefinger]

Thanks for reply!

[Lazic]

Looks awesome will download it soon !Kudos

Can anyone tell me if there are any bugs or crashes for this and how much exactly does it help? thanks

[DragonX]

I hope this works. Oblivion is even worse than Fallout 3 in the stuttering department and the FPS cap method I used in FO3 makes Oblivion even slower.

Maybe I should just get a new CPU? I expected my 9800 GT to perform quite well which it does with 2x AA and 8x AF but in the Imperial City it stutters to kingdom come.

[Beyonder]

Using 3 beta 4 and it makes the NPC's die, I tested it and it is this plug in, everything worked fine when I removed it from OBSE, tried Disabling all mods and going to earlier saves and they still died the same way, basically when I fast travel the NPC's fall into place, and they either die or get very close to, didn't happened with version 2.

[skyranger-1]

edit: Nevermind; this is confirmed to still effect the latest alpha

What??? First I've heard of that. Does it still happen in the latest alpha at ftp://71.115.199.25/sr_Oblivion_Stutter_Remover.dll ?

edit: Note that starting with either 3beta4 or the alpha immediately after it, a lot of strange issues appeared - reports of occasional fast-forwarding or CtDs. The reports I got didn't make it entirely clear which version it started in. This seems to be fixed in the latest alpha though. Can you check if your issue was fixed there or not? And tell me if your issue started with 3beta4 or an version from my ftp server?

Edited by skyranger-1, 22 March 2009 - 02:16 PM.

[skyranger-1]

The issue has been fixed, I think. The latest alpha at
ftp://71.115.199.25/sr_Oblivion_Stutter_Remover.dll
includes the fix.

I know that URL was down for a while earlier, I took it down when I found that my fixes weren't working, but now they seem to be work so it's back up.

[Akiostacie]

Jesus Christ.

SPINLOCKS?

Suddenly, it all falls into place.

EDIT: I'm pretty sure most Windows/360 synchro functions take spin time in milliseconds. I know WaitForSingleObject() does, at any rate.

EDIT 2: You're also probably going to want to adjust the counts based on number of cores present, as contention is going to be a bit different depending on how many threads are trying to access shared memory.

Edited by Akiostacie, 28 March 2009 - 04:52 AM.

[skyranger-1]

While the vast majority of Oblivion stuff seems to happen in 1 thread, there are numerous other threads lying around, and they occasionally do work. Oblivion uses a number of CRITICAL_SECTION objects for thread synchronization, plus a few other things (lockless queues, I've heard; all I've noticed in the disassembly besides CRITICAL_SECTIONs is a few interlocked_* calls). Microsofts CRITICAL_SECTION implementation includes a spincount to delay before putting the thread to sleep. The spincounts are in arbitrary units (numbers of cycles through some arbitrary loop in Microsofts code), Microsoft sort-of-almost suggests a value of 4000 for but user reports suggested that 4000 did not work well in this case. Milliseconds are an unlikely unit considering these are intended for specifying time units significantly smaller than the scheduling resolution; microseconds would be more likely.
In the readme I recommend 400 for spincount on dual-core, and 500 for spincount on quad-core. I haven't actually *measured* anything (not easy, under the circumstances), just a user reported that 500 worked well for him, and he had a quad-core, so I scaled down slightly for dual-cores. Spincounts are ignored when running on single-core CPUs, so it doesn't matter what the settings are there. Oblivion normally does not specify spincounts and ends up using the default value of 0. The observed behavior of spincounts in Oblivion does not match my understanding of the theory: by my understanding of the theory, setting spincounts too high should result in excessive CPU utilization by secondary threads spinning, but not degrade performance much until all CPUs are busy. In practice I have not observed spincounts having noticeable impact on CPU usage or framerate, but they are reported to increase stuttering when high and decrease stuttering when about 500.
Note that this also makes a number of other changes besides the spincounts, including changing Oblivion from running its main game logic timer off of GetTickCount (which increments at 64 Hertz on most computers, creating a nasty interference patterns with most refresh rates, aka microstuttering) to running it off of timeGetTime, wrapping Oblivion in a timeBeginPeriod(1) region, causing it to yield unneeded time with Sleep, and several changes to the way Oblivion game logic timing reacts to framerates and fluctuations in framerates.
edit: note that spinlocks & spincounts generally refer to loops that burn CPU time (typically in increments of ~100 clock cycles I think, on x86), which is rather different from WaitForSingleObject which works through the scheduler, which works in units of milliseconds and multiples of the timeslice size

Edited by skyranger-1, 28 March 2009 - 06:09 AM.

[skyranger-1]

Realize that I'm running around in the dark here. The theory is that more hardware threads = higher optimal value, but there's not a lot of conformance to theoretical predictions.

Try 600.

[Xtudo]

A FALLOUT 3 version is possible?

Thanks!

Edit: skyranger-1, thanks for the reply, I will wait then!

Edited by Xtudo, 10 April 2009 - 12:01 PM.