GUIDE ENB Guide

[alt3rn1ty]

Also editing section ENB Complimenting mods https://wiki.step-project.com/Guide:ENB#ENB_Complimenting_Mods

 

 

Fog section - There is an inaccuracy / confusion as to what does not go with what here

 

 

RGabriels Remove Interior Fog V2 ( which is a revamp of an older mod called "Remove Ambient Interior Fog" ) ..

 

.. IS compatible with Interior and Dungeon Fog Remover

 

The description on the wiki for the latter says "This mod is not compatible with Removed Interior Fog V2; use one or the other, not both."

 

 

I dont know where that info came from, but if you read RGabriels mod description it says :

 

"NOTE: This mod only removes the distant interior fog, it doesn't remove the floating mist particles. If you want to remove those, use the mod Interior and Dungeon Fog Remover"

 

I have been using the pair of them together since RGabriel made RIFv2, prior to that I was using "Remove Ambient Interior Fog" combined with "Interior and Dungeon Fog Remover"

 

I think what has got confused here is someone editing the wiki ( or the source of the information the editor had ), has mixed up "Remove Ambient Interior Fog" with "Interior and Dungeon Fog Remover" as to which one was incompatible with RIFv2.

 

 

Anyway long story short - Corrected it

[TechAngel85]

Thanks. That part has been on the Guide almost since it's creation...as a really, really long time. They probably weren't at one point when that was written but are now.

[DoYouEvenModBro]

Does anyone know how ENB reacts with Crossfire these days?

[TechAngel85]

I don't like the move of ENBlocal INI section under ENBoost. That makes no sense since only a couple sections of the INI file pertains to ENBoost and the rest pertains to full ENBs. I'll be moving it and leaving in duplicate parameters that only pertain to ENBoost in its place.

 

EDIT:

I've rearranged some things that make more sense for the flow of the Guide. Most of it has been updated for the latest changes in v0.265, but there is still some text that needs to be edited. I'll get to that in a bit.

[alt3rn1ty]

Sounds good, I wasn't sure about placement of that, though it did seem a bit out of place after the move. I think ENBLocal.ini advice needed revamping with new info and possibly expanding on for the full ENB setup too ...

 

I lack the first hand experience / detailled knowledge / common issues to be wary of on that side of the topic ( I have dabbled with making my own minimal performance impact preset from scratch with good success, but I still need better machines for full ENB so I just stick with utilising ENBoost ( I like fast fluid fights, not just good for screen archers performance ) )

 

 

Edit : Also might be worth mentioning a recent find - https://forum.step-project.com/topic/4985-memory-blocks-log-by-sheson/page-2?do=findComment&comment=108722 - See the Edit after the third quote box .. Onwards, reference :

 

ExpandSystemMemoryX64=true in enblocal.ini

 

If using Shesons memory patch in whatever form - set this to False

 

Personally having under 4gb and on a 32bit Win 7 I always run with it off, but have had my suspicions something was wrong with it having tried it on our family desktop before and experienced problems ( in combination with SSME ) .. I run with it set to false on that machine too without problems.

 

Think I mentioned this elsewhere in another ENB topic on this forum ages ago, but I guess most people are 64 bit with huge amounts of ram so thought it was not an issue worth looking into  .

https://forum.step-project.com/topic/2613-ctd-and-performance-patch-enboost-by-boris-vorontsov/page-13?do=findComment&comment=48681

Edited January 7, 2015 by alt3rn1ty

[TechAngel85]

Thanks, I'll look into it.

 

The advice and descriptions for enblocal mainly all came from Keithinhanoi himself and my own investigation on the ENB Dev forums. Because of this I find it to be mostly rock solid because it all came from him or Boris himself.

[TechAngel85]

Just an update. I'm about half way through the Guide. I like the changes overall and they needed to be done with the switch to the TOC layout. I've edited everything through the ENB Presets. I've updated headings to make more since, deleted some headings that were no longer needed and have updated information to v0.265. I still have the from the ENBlocal INI and down to read through....it's a big guide.

[hishutup]

Does anyone know how ENB reacts with Crossfire these days?

This is my experience. Im not going to go super in depth but I have been using mine for years now.

My cards are 6970

• DOF - doesn't work. You can kinda get it to work if you use a low fade time but it will flicker 1 white frame every now and then. Why? I have my theories. 
• Water ripples - they will flicker in both the Vanilla and enb
• Adaptation - can get out of sync and cause the game to be too bright or too dark and flicker really bad. You may be lucky and get it be perfectly synced. If it does get out of sync, you can toggle ENB and/or the adaptation on and off to get it sort of synced again. 
• If you have VRAM swapping that tiny freeze will be double the length. 
• Radeonpro + CFx + ENB = mustard yellow screen followed by a crash at startup

Any sort of CFx fix doesn't actually work. The effect it gives is both cards will be rendering the same frame and you will not see any performance boost.

I hope this makes sense and answers your question.

[DoYouEvenModBro]

It answers my questions but makes me sad :(. In order to run Skyrim, I have two options since I have a 1440p monitor.

 

1.) Run it with centered timings in 1080p with HUGE black boxes around the window.

 

2.) Run it in full screen at 1080p but then it looks blurry and slightly stretched.

 

GPU: r9 290 

 

- fully modded with Serenity ENB v12.5

[Aiyen]

Or you know.... tone down the quality of some of the effects in the preset so you can actually run it at that resolution! Cant have it all! 

[DoYouEvenModBro]

Aiyen, what you say does not compute.

[phazer11]

He's saying to modify the ENB files so you can get more performance out of it so you can run ENB at that resolution. Look at the ENB guide on the wiki or Aiyen's ENB guide PDF from Skyight ENB's page.

[Aiyen]

I am fairly certain he was joking! Prod have done magical work with serenity.... but it also has the most costly shaders around. (not counting super silly DoF files that will cripple even super computers.)

 

Slight tweaks to his bloom and DoF settings will most likely yield quite a few FPS.... along with the obvious, reduce grass densities etc. :P 

[keithinhanoi]

Thanks, I'll look into it.

 

The advice and descriptions for enblocal mainly all came from Keithinhanoi himself and my own investigation on the ENB Dev forums. Because of this I find it to be mostly rock solid because it all came from him or Boris himself.

Hey Tech - alt3rn1ty was actually referring to a recent post by me on the thread about Sheson's Memory Blocks Log and despite what I've said before regarding ExpandSystemMemoryX64, I now believe that the STEP ENB Guide's recommendation should be to set it to false.

 

The reason for this is that STEP also recommends increasing the "Block 1" heap allocation in the SKSE.ini, and with help from hishtup, I have confirmed there is direct relationship between the ExpandSystemMemoryX64 setting and using Sheson's Memory Patch fix (with either implementation - SSME or SKSE) to increase the "Block 1" allocation.

 

If ExpandSystemMemoryX64 is set to true, after the "Block 1" allocation is set above a certain number, Skyrim will crash just before the main menu. For me, this happens when "Block 1" is over 512MB, though I've read user reports of it happening closer to or just past 768MB.

 

Before hishtup told me about his findings, the only way that I knew of to allow Skyrim to run after the "Block 1" allocation causes it to crash is to increase the "Block 2" allocation to 512MB. However, using Sheson's Memory Blocks Log and other tools, I and other people have observed Skyrim still never actually uses over 256MB for "Block 2". So that additional 256MB allocated to Block 2 is essentially wasted.

 

Then, after I posted an explanation of how the Memory Blocks Log tool works with a bit of history regarding Sheson's Memory Patch Fix, hishtup told me that if ExpandSystemMemoryX64 is set to false then Skyrim won't crash based on the "Block 1" allocation. From this, I realized that increasing the "Block 2" allocation should not be necessary.

 

So, I did some tests and can confirm that this is correct. With ExpandSystemMemoryX64, set to false, I can set my Block 1 allocation even over 1GB, and Skyrim doesn't crash when started, and I do not need to increase the "Block 2" allocation.

 

In retrospect, this make complete sense, because based on the source code of the ExpandSystemMemoryX64 feature that Boris posted on the ENB forums, it uses a system memory allocation function call (MEM_TOP_DOWN) to change the allocation of memory from the "bottom" of the memory space of a program to the "top" of its memory space. The MEM_TOP_DOWN call is intended to be used for testing when converting a 32-bit application to 64-bit.

 

I did quite a bit of research about MEM_TOP_DOWN, and although my findings were inconclusive, I never found any evidence to fully support the idea that it would allow memory to be used more efficiently. For an enlightening and interesting article on MEM_TOP_DOWN, you can check out this blog post by Bruce Dawnson, a programmer at Google (who used to work for Valve). Scroll down to the bottom of the page, and you will see my questions to him that I asked back in March last year.

 

So I highly recommend changing the ENB Guide to suggest setting ExpandSystemMemoryX64=false in enblocal.ini as the default, and adding an explanation about its effects on the Sheson Memory Patch fix.

 

For the explanation, my suggested edits:

 

T When set to true, this parameter changes some of Skyrim's memory allocation code to put write some cached data at the beginning top of Skyrim's memory space, instead of the default write to the bottom of the memory space method used for almost all Windows programs. The According to the author of ENB, this can greatly reduce memory fragmentation and make better use of the Skyrim's available memory, especially when running on 64-bit Windows. It is highly recommended to enable this parameter for all 64-bit systems; however, it can generally be left enabled even for 32-bit systems as some users have reported it working well for them on these systems. If using a 32-bit system and having issues such as CTDs, disable it. However, it has been found that this feature conflicts with the Sheson Memory Patch fix by causing Skyrim to crash if the memory patch fix is used to increase Skyrim's initial heap ("Block 1") allocation higher than 512MB. Therefore, if using the Sheson Memory Patch fix, then it is recommended to set ExpandSystemMemoryX64 to false. Note: For this parameter to work, ReduceSystemMemoryUsage must be set to true and EnableUnsafeMemoryHacks must be set to false below.

(9 Jan 2014, 3:52PM GMT -7: I edited my explanation of what hishtup told me, for clarity, and added some interesting, relevant and factual links.)

Edited January 9, 2015 by keithinhanoi

[darkside]

keith,

 

I am on 64 bit system. I use both ENB and Sheson's fix. My "Block 1" never goes over 512MB.  

My current setting is ExpandSystemMemoryX64=true

 

- What is the downside of setting ExpandSystemMemoryX64=true?

- What is the benefit of changing it to ExpandSystemMemoryX64=false?

 

Thanks for a great information