Oops... sorry, didn't pay attention to that new options! Just recompiling now... I'll re-upload the new file in a moment!

EDIT: Done! Updated new version compiled with that options turned on. Same http://www.4shared.com/file/JwFc0ebh/BorlndMM.html as before

with the new BorlndMM.dll
Memory performance:


Seems to be a little bit better, but needs more testing


Edit
found something additional
{$define UseCustomFixedSizeMoveRoutines} and/or {$define UseCustomVariableSizeMoveRoutines}
----> FastMove library for even better performance <--- I understand nearly nothing, but this sounds good too
http://www.fastcode.dk/fastcodeproject/fastcodeproject/74.htm
http://fastcode.sourceforge.net/

Hi guys!

can you tell me if the new BorlndMM.dll is smoother than Mode 5?

Thanks

Whoa! Totally over my head. Maybe skyranger1~ needs to come back and let us know if there can be an upgrade to this amazing utility!

Mode 5 still seems smoother to me.

I'm around. A little anyway.

I'm doing a (minimal) OSR port to Fallout New Vegas. The only non-new-vegas-specific stuff I've done while adding new vegas support is a change to the behavior of critical section mode 2 3... it might become the new default mode. Nothing much has changed since the 4.1 release. My ftp server is down, and will not be going back up in the foreseeable future (my internet connection is simply too [censored]).

Heap replacement algorithms:
I have not looked at the latest version of FastMM4. I generally consider heap algorithms #1, #3, and #5 as approximately equivalent since I can't tell the difference between them when playing, and user reports make it sound like perceivable differences between them vary from computer to computer with no apparent pattern.

Are you planning to update the critical section mode 2 in OSR, or is that just for New Vegas?

Regardless, it's great to see you back, even if it's only a brief visit!

:foodndrink:

There will probably be another WIP release to bring the latest revision of CS-mode 2 3 to OSR/FSR.

:goodjob: Looking forward to an update to a most incredible mod

I remember reading about some weird timing glitch that made the game feel like it was getting snagged on something every few seconds. Is that something that's going to get backported for OSR? Because I think I'm running into that now for some reason. Not the usual disk stutter, but every few seconds it's like the whole game just pauses for a very short bit before resuming again as though nothing happened.

I was confused when I said CS-mode 2, I meant CS-mode 3 (which documentation has sometimes referred to as staggering CS mode, other times as stuttering CS mode).

Arthmoor:
The only timing glitch I know of in Oblivion is the 64 Hertz issue, which has been fixed by default in OSR for forever. My default recommendation for performance issues that OSR fails to fix is to try updating graphics drivers.
In theory if you turned on all the profiling options in OSR and recorded a log of a game in which the problem occurred, and I could figure out when in the log corresponded to the problem (either because the log was short and the problem was large, or because you told me exactly when it happened), then I might be able to say something about the cause. In practice, I usually can't say anything useful however.

Is the 64 Hz issue the same as discussed in http://forums.nvidia.com/index.php?showtopic=183427&st=0 on the NVidia forums?

I understand that Nvidia may have a driver update to fix that issue (which I understand from the discussion is a Gamebryo engine issue).

Yeah, that's the issue. Fixing it from a graphics driver sounds like a bad idea, but is probably possible. Stutter Remover isn't the *only* thing that fixes it these days, as there's a 4 GB enabler for Fallout New Vegas that also addresses that issue. The correct fix to the issue would be for either microsoft to change the implementation of GetTickCount or Bethesda to change their main timing calls (it's hard to tell, but the disassembly of that code in Oblivion looks like it's Bethesdas instead of Gamebryos to me). Alternatively, a generic exe loader/patcher could be made to make arbitrary programs use OSRs GetTickCount and CRITICAL_SECTION tweaks apply to arbitrary programs.

It seems the technical rep from NVidia noted that this issue was also found it ATI cards, hence it is a Bethesda issue, not an Nvidia issue. I guess no fix from them then.

Well, I have OSR, so nothing lost for me :foodndrink:

There's a file up on the nexus named something like Tripple_WIP_4-1-4.zip.

It contains OSR/FSR/NVSR .dll files built from the latest code, including the modified implementation of CS-mode-3, which is now set as the default.

Is it stable to use?

On Oblivion, I've briefly tested it (I've started playing Oblivion again the last few days) and it seems to work.
On Fallout 3 it's untested, but likely not much different from the last FSR release.
On New Vegas it's totally untested, and the first NVSE-based release. Who knows?

:liplick: Bolt out of the blue.... ? Is the format/content of the 4.1 ini still good with this (no ini included in the tripple WIP)

If so I am guessing from previous posts above we just need to try CriticalSections iDefaultMode = 3

alt3rn1ty: Yeah, that will work. You can also delete your .ini file, and it will generate a new one with the new defaults, though if you like heap replacement enabled or some other non-default configuration you'd have to re-do that.

Kept the ini for my previous settings and just changed idefaultmode .... All seems well here (been running it since about 5 mins after my last post - it was too tempting not to go ahead and try), laptop hasn't gone into meltdown anyway

Thanks SkyRanger-1, will continue running this I have previously had an un-usually stable setup for quite some time now, so far it looks like its going to continue.

Oh, when keeping an old ini with the new version, you're supposed to change the name of CriticalSections\iStutterLevel to CriticalSections\iStaggerLevel, it had its name changed. Nothing bad will happen if you don't though, it will just ignore your iStutterLevel and use the default value for iStaggerLevel (which is likely the same as what you had set anyway).

It's working fine here. Thank you!

After seeing this decided to backup and delete my ini to generate a new one and compare side-by-side old/new ini. Noticed theres a few more options, and wonder if you could give us a run down of the options enabled with these two....


bExtraProfiling = 0
bExperimentalStuff = 0

Experimental = {
bMonitorBSShaderAccumulator = 0
iPrintSceneGraphDepth = 0
bReplaceRawRandom = 1
bReplaceExtraRandom = 1
bSuppressRandomSeeding = 0
}

Edit: P.S. - Alls well still, I have been running around the countryside quite a lot since installing, prior to this post had just over 4 hours non stop session .... no stutter anywhere so far, and no CTDs as is usual for me so it seems to be working well. I am going to have a similar run around for approx the same duration with the default settings next.

Those were present in the last WIP before this, though they didn't do much good. And some have changed since then. They are all Oblivion-only, though they show up on all versions.

Master/bExtraProfiling - this enables/disables the performance monitoring code that measures what amount of time oblivions spends in a wide variety of functions, mostly concentrating on the functions the main thread spends most of its time in - this is Oblivion-only so far
Master/bExperimentalStuff - master enable/disable for the Experimental section, which mostly is only implemented on Oblivion so far. These settings appear on all versions IIRC, but are only meaningful on Oblivion so far

Experimental/iPrintSceneGraphDepth - useless, but kinda awesome. Can produce VERY large log file. Set this to a high number, and the ENTIRE scene graph will get printed to the log file during rendering. EVERY FRAME. Actually, it might not be the entire scene graph, it may skip things that get culled (due to being behind you or obviously occluded). Setting this to smaller numbers will truncate the scene graph depth... that is if set to 1 it prints the root, set to 2 it prints the root and the roots immediate children, set to 3 it prints the root and the roots children and grandchildren, etc.
Experimental/bMonitorBSShaderAccumulator - IIRC this is some code related to bExtraProfiling, but it monitors something or other that was important but that my normal methods of profiling don't work very well on so it had to do special hooks. And I think the reporting on this is a bit ugly, printing lines multiple times per frame.
Experimental/bReplaceRawRandom - This replaces the libC functions rand() and srand() with better equivalents. Since the last WIP I think I replaced the RNG I was using with one a little faster. Also, I think I have some slight strangeness in here I was meaning to fix but forgot to, because the RNG there occasionally gets used internally by the stutter remover... need to fix that...
Experimental/bReplaceExtraRandom - This replaces the Bethesda wrappers around rand() that Oblivion sometimes uses. Some of them are very strange, looking as if Oblivion uses rand() as a sort of procedural noise generator for some textures or something
Experimental/bSuppressRandomSeeding - just to play around, this lets you screw with Oblivions head when it comes to its stranger uses of rand() by suppressing all srand() calls after initialization. This may reveal what Oblivion uses rand as a procedural texture or whatever for. I think someone reported that it made the sky or fire or something look weird, but improved FPS in some areas a bunch for some reason

how exactly do you install it with OBSE? because it seems as though every time i load with the OBSE launcher none of the stutter remover effects have been turned on? Im returning to OBlivion after a couple years off by the way so im not as familiar with all the modding and data changes. any help would be greatly appreciated.

-foo