[quote=RoyBatty]
xQdcss no you need to set the vram setting too and turn use effect off.
I tested it and it causes the same stuttering and poor performance when moving the camera around as it always has, so I removed it again.
[/quote]
How bad is the stuttering your experiencing? Is it when turning and looking from different directions? or constant?
In my experience, there is only constant stutter when turning the camera if [n]DisablePreloadToVRAM[/b] is set to true.
Conversely, having [b]EnableUnsafeMemoryHacks[/b] set to true greatly reduces both stuttering and cell loading hitching that is present in vanilla (i.e, no ENB installed).
[quote=MajinCry]
In my experience, there is only constant stutter when turning the camera if [n]DisablePreloadToVRAM[/b] is set to true.
Conversely, having EnableUnsafeMemoryHacks set to true greatly reduces both stuttering and cell loading hitching that is present in vanilla (i.e, no ENB installed).
[/quote]
I've noticed when quickly turning in various directions that if ReservedMemorySizeMb was set too low I get a short, consistent lag. Setting this at 512Mb (atm) eliminates the problem; this particular card has enough memory to set that value fairly high.
MajinCry maybe you could make a short guide for ENBoost with UseENBoostWithoutGraphics because there is so much conflicting information and misinformation about the use of ENB it's massively annoying to try and get it setup correctly especially since boris doesn't give any decent documentation.
Also it was UseOriginalPostProcessing for the image spaces and stuff right?
@MajinCry
Can I follow the STEP Enboost guide for skyrim with TTW?
According to it, I have to disable almost every option in the enblocal.ini but you say enableunsafememoryhacks should be enabled. I too would appreciate a short enboost guide. (no need to rush of course)
@Mystical Panda, that is the default setting, so no surprise that it works best.
I'll share a couple different ENBLocal.ini files, each for different situations to give an idea on what users ought to have.
[quote=MajinCry]
@Mystical Panda, that is the default setting, so no surprise that it works best.
I'll share a couple different ENBLocal.ini files, each for different situations to give an idea on what users ought to have.
[/quote]
Thanks for the ENB knowledge! Especially when 'banking' textures in VRAM as opposed to boosting it through multiple copies of ENBBoost; I've tried both, but eventually just went with the multiple copies. I'll change that this afternoon and see how just caching it in VRAM does.
I tried settings 64mb, 128mb, 256mb with stuttering being more apparently towards the low end when quickly turning about; 512mb seemed to provide the least (which is why I suggested bumping it up and seeing if it resulted in any gains, since many guides on the internet suggest lowering it to 64mb or 128mb- apparently the newer versions were 'better' coded than the original ones requiring more, thus the suggestion to reduce it and often times there's no indication of what someone was using as their 'default'). I read where it was used as a 'buffer', of sorts for 'bursing'? IIRC.
I'm glad Boris is providing more support for FO3/FNV (though he really doesn't seem to care for them), his 'boost' feature really does come in handy at times.
You have to watch the dedicated size for integrated video. AMD APUs only get 384M of ram to use as VRAM, so setting to 512 won't work. Not sure what limit Intel sets on their integrated video.
@ MajinCry
I'm wondering, after this initial test, if disabling the video driver is actually required- I've read where Boris recommended it for older 'buggier' drivers (not more recent ones), but this is the lastest one and I have no idea if that's required for 'disabling' texture caching in older versions of DX. He had it set to true by default. If so, it would make that setting required if just buffering textures. It also makes me wonder if it's required to prevent FNV interaction with the graphics driver period, though going through the enb dll should do that or if he's patching something on the 'fly' which disables or NOPs code that would call the 'shadowing' functions.
For this test, I disabled ReduceSystemMemoryUsage=false. I also dropped the 'reserved' vram down to 128mb.
If you notice the ENB settings (enbconfig.txt), with just EnableUnsafeMemoryHacks=true within a very short time (game log at the bottom- game-test.txt), I start getting "out of memory" hits which eventually crashed the game. Up until that point, everything seems to be working ok for about 7+ hours of testing.
This might be because of I didn't disable the graphics memory driver also, but last time I tested that particular feature (just a few weeks ago), I picked up a slight performance hit; so I opted to use the newest video driver for my card (NVidia GTX 1060 6g- it's fairly modern so the driver should be relatively good). Using MSI Afterburner (which doesn't cause a problem for me, at least from what I've been able to tell- no crashes in countless hours using it on FNV unless caused by bad or missing assets or memory issues), the total ram usage never really goes over 2.5+ or so gb with the highest hitting around 2.9gb.
Let me switch back to ReduceSystemMemoryUsage=false and give it another quick test run. Windows just updated a day or so ago and it couldv'e caused a problem with one of the existing memory 'tweakers'.
What happens if you set [b]ReservedMemorySizeMb=512[/b]?
Edit: Also, what operating system are you using? If it's Windows 10, I wouldn't be surprised if shit's just wonky because it's, well, Windows 10.
