Fallout 3 / New Vegas 0.278

[ENBSeries]

Fallout New Vegas / Fallout 3

ENBSeries graphic mod / ENBoost patch 0.278

Added AutodetectVideoMemorySize parameter. Changed ENBoost memory manager by forcing memory statistics of the mod only to reduce issues with bad drivers. Fixed bug when ENBoost compression was always enabled. Added profiler statistics for ENBoost.
New statistics may help to detect why stuttering happens. Performance reduced by two factors: 1) number of textures created in video memory; 2) total size of textures created in video memory. When not enough video memory, ENBoost deleting resources by their usage priority, also removes unused after 5 seconds. When you have heavy stuttering while looking at certain direction, check how many memory for textures created per second, if it's big, then your memory manager config is not optimal for amount of video memory available or mods have too many big textures at same area (unfixable basically).

[stevennightfall]

Thanks for the new update, Boris! It's cool to see the autodetect feature in Fallout. Is it true the next one will revolve around weathers? If so, have you seen the new Realistic Wasteland Lighting Enhancement by xCamoLegend? ( /newvegas/mods/59591/ )

[ENBSeries]

stevennightfall
Not sure, probably.
Haven't seen it and i do not use mods, because don't play games which i modify.

[Maeldun]

New statistics may help to detect why stuttering happens.

Boris, is there any point in adding these statistics to the Skyrim version? I would imagine it could be a useful diagnostic tool to find optimal settings.

[ENBSeries]

They are added already, i don't know when will publish new version, it's not done yet.

[Maeldun]

They are added already, i don't know when will publish new version, it's not done yet.

I'm looking forward to it. I might even put together a guide with screenshots to help users troubleshoot their setups, assuming that makes sense after I use it myself.

[number6]

If I want to test correctly, I should really take my own advice and test on a totally vanilla install.

But for comparison sake with v0267. First, the FPS with EnableUnsafeMemoryHacks=true was about the same between v0267 and v0278. v0278 might feel slightly smoother or more consistent FPS. Could this be attributed to EnableCompression=false working as intended now?

With EnableUnsafeMemoryHacks=false the lag is present in both versions. With the profiling, I can see the Deleted, Allocated, and Created Textures profiling numbers occasionally jump from zero to values in the 100s for Created Textures and up to 5000 Mbytes per sec for Deleted and Allocated. However, it doesn't always correspond with the lag. Sometimes the numbers jump and there is no lag. When there is lag, after the freeze, the values are sometimes zero and sometimes low in the 100 Mbytes per second range.

Either way, USMH(UnsafeMemoryHacks) still works and seems to perform with +5 FPS on average. Also with USMH=true the memory usage of the game is the same as when it's false; around 750MB. When USMH=false, enbhost.exe is using around 1500MB. When ReduceSystemMemoryUsage=false, loading the save game freezes when the game's exe is around 2200Mb with both versions. Also, regardless of the USMH setting or ENB version, the VRAM usage for the save game I am testing with is always at 2400MB when the save game loads and doesn't change much while wandering the local area.

I am curious, where does the 1500MB get stored when EnableUnsafeMemoryHacks=true if not in enbhost.exe and why is it unsafe?

Thanks for the new version. Maybe some others will report in with more conclusive results.

[ENBSeries]

number6

the FPS with EnableUnsafeMemoryHacks=true was about the same between v0267 and v0278

Don't understand why do you think fps must be different. Textures can't be created and can't be rendered faster, it's a hardware performance factor. Compression do not works in both versions when this parameter enabled.

up to 5000 Mbytes per sec for Deleted and Allocated. However, it doesn't always correspond with the lag.

Because it's per second statistics, it's displayed longer than it actually occurs. For example in one frame it may transfer 20gb of textures and nothing in next frames, only displaying per second or as graph curve.

Sometimes the numbers jump and there is no lag.

This means textures are not used yet.

When there is lag, after the freeze, the values are sometimes zero

No idea

and sometimes low in the 100 Mbytes per second range.

Then it's too many textures spawned (number of textures have same impact as their size) and they are used in frame, loading them immediately means broken parallelism of rendering, it's driver side optimization.

Also with USMH=true the memory usage of the game is the same as when it's false

This is always the same in all versions, if ReservedMemorySizeMb is low.

When ReduceSystemMemoryUsage=false, loading the save game freezes when the game's exe is around 2200Mb with both versions.

Obviously ENBoost disabled.

regardless of the USMH setting or ENB version, the VRAM usage for the save game I am testing with is always at 2400MB when the save game loads and doesn't change much while wandering the local area.

You don't have more textures in there. But if you try to look at the sky for longer than 5 seconds with EnableUnsafeMemoryHacks=false, this number should be lowered, because of removing outdated textures from video memory.

I am curious, where does the 1500MB get stored when EnableUnsafeMemoryHacks=true if not in enbhost.exe and why is it unsafe?

I don't understand. Where did you find these 1500 mb? They are not exist in ram anywhere when unsafe hacks enabled, everything is located in video memory without unloading. It's unsafe, because when you switch alt+tab in fullscreen mode all data in vram is lost and it do not have copy in ram (that's why performance is higher), the crash is result of this. Also on out of video memory condition performance will be awful and game may crash.

[Marcurios]

Thanks for yet another great update Boris !

[number6]

Don't understand why do you think fps must be different.

I thought the compression improved it. But if compression is not working with USMH then it must be the same.

Because it's per second statistics

Ok, that explains the delay with my observations

Obviously ENBoost disabled.

I know, I was just stating my non-ENBoost mem usage for reference

I don't understand. Where did you find these 1500 mb?

It's the amount enbhost.exe is using when USMH is false.

It's unsafe, because when you switch alt+tab in fullscreen mode all data in vram is lost and it do not have copy in ram (that's why performance is higher), the crash is result of this.

Yeah, I do get crashing when alt+tab sometimes, not always. Also, alt+tab always seem to work when in borderless fullscreen windowed mode but I usually don't use that.