TechAngel85

Make sure ENBoost is set up properly. If you're unsure you can post your enblocal.ini.

Okay here are my second round results: In this round I did the same runs minus spawning the dragon as it served no purpose from the previous runs; however, iPresentInterval was copied to the Skyrim.ini file. For good measure, I also left it in the SkyrimPrefs.ini file as well just to see if it would have any effect. It seemed to have no effect, whatsoever, being in the SkyrimPrefs.ini. I did add a bit to this run as I wanted to see any possible havok issues and issues with NPC paths. Therefore, after entering Honeybrew, I exited and walked to Whiterun, talk to the guard so I could enter, walked up to the market and observed for a while, and then walked up the stairs to the left and observed the cow for a while. Lastly, I added two scenarios that aren't on the results to specifically test claims of issues with iPresentInterval disabled. This consisted of forcing vsync via the drivers, no ENB installed, and doing one run with iPresentInterval disabled and a second run with it enabled in order to spot any differences. Results With iPresentInterval moved, all runs are now as expected. I didn't run into any "mystery runs" that were unexplainable or did not act as I would expected, so that is good news. Boris explaination of how ENBSeries is the faucet/valve now makes complete sense as that behavior was observed in these runs. As you can see from the results, there are only two cases for Nvidia users that vsync truly works: Driver=App Controlled + ENB=True + iPresentInterval=1Driver=App Controlled + No ENB Installed + iPresentInterval=1 Havok Issues With these results and testing I can definitively say that all havok issues are caused by too high frame rates. This was proved in the runs where I forced vsync in the drivers and toggled iPresentInterval on and off. I experienced no havok issues during these runs. In fact, the only runs I experienced havok issues are the runs which vsync did not work and the frame rate was too high; regardless of what iPresentInterval was set to. This rules out iPresentInterval as having anything to do with havok issues and places the blame solely on frame rates higher than 60FPS. NPC Path Issues One of the claims is that NPC paths are messed up by turning iPresentInterval off. I'm not 100% positive but I can say this is likely true. In the runs where I forced vsync in the drivers, I observed the NPCs walking around the market place in Whiterun as well as the Cow that is up the stairs and to the left. The cow was okay in both cases and was only affected by having no vsync which cause it to slide around rather than walk. The NPCs on the other hand did seem to be affect by setting iPresentInterval to 0. With the parameter on, the NPCs casually and smoothly walk around one another in a natural manner. With the parameter off, the NPC no longer walk around one another as smoothly and seem to "bump" into one another more often. These results would seem to confirm this issue but it needs more testing in this scenario to determine. To test this: Uninstall ENBSeries, force vsync to be on in the drivers, and do runs with iPresentInterval=0 and iPresentInterval=1. Look for differences in NPC walking behavior. My official recommendation remains the same, we should mention to have iPresentInterval set to 1 in all cases (and that is in fact belongs in Skyrim.ini under the Display heading). We could simply not mention it since iPresentInterval=1 is the default; however, you will run into users that have changed it from following advice from somewhere else and then there's the fact that we've been telling users to change it. Users should simply delete the parameter from there INIs and forget about it. That would force the default setting and prevent any issues.

I'm about half way done testing again. Nvidia stays true to not allowing vsync when forced off in the driver in all situations. I would say that setting is reliable if anyone really needs to turn vsync off as I can't find anything that overrides it (at least not with Skyrim). I can also tell you that run number 19 in your chart is working as Boris describes it would. I no longer get vsync on that run when moving iPresentInterval to Skyrim.ini. I'll finish up the testing and post my new results.

I noticed that as well. There is also a hard vertical line right down the center on the alpha channel. Mixing the channels you can see that the texture could use quite a bit of smoothing and a little better blending from shade to shade. There also seems to be some "overspray" in some area. Assuming that is the uncompressed texture and with all that in mind, I can see where you would be getting some noticeable artifacts with compression.

Just to a quick update here... I've tested the "mystery runs" on a completely vanilla game (launch through Steam to completely bypass any and all mods). I still get vsync with no ENBSeries installed and iPresentInterval disabled. This confirms on my system that there isn't a mod that is overwriting any INI settings. However, there is a catch.... Just for the hell of it and to satisfy my curiosity, I added iPresentInterval=0 to the Skyrim.ini file under display and BAM! No vsync in those mystery runs! This suggests that iPresentInterval=0 needs to be in the Skyrim.ini to disable vsync at the very least. Perhaps, it needs to be in both places? Perhaps in SkyrimPrefs.ini it controls the game timings and in the Skyrim.ini it controls vsync? I would certainly like more information on this. This probably also warrants a retest with the parameter in Skyrim.ini and not in SkyrimPrefs.ini.

1.8 meters. Here's the specs: https://www.gigabyte.us/products/product-page.aspx?pid=3616#sp

I was a log time fan of Logitech and still am. Although, for the several years years I've been using Gigabyte mice. I had two wireless mice of theirs for my laptop; the ECO600. This mouse was amazing for what I did with it. The adjustable DPI really helps in photoshop work. Battery life was also really great of which I could get 8-12 months out of it before having to change them. It also fit very comfortable in my hand for all-day use. The first one got dropped to many times and had to replace it. The second one work perfectly for about two years and then started having some lag issues. My recent build (March 2014) is a desktop and I wanted to get away from the wireless because wireless mouse often have issues with desktops due to various reasons. That and I wanted something a bit higher quality for gaming. To my surprise, I found another Gigabyte mouse that was nearly an exact copy of the design of the ECO600 so I knew it would be supper comfortable. It was sports adjustable DPI, programmable buttons, gaming grade footpads (which are still like new), a high grade optical sensor that could spit out up to 3200DPI, and it's made out of rugged materials that after nearly a years worth of use still looks brand new. No sign of wear on the finish, buttons, or anything else. This mouse is the Gigabyte M6900. One might look at the price and completely dismiss for being only $20US, but I wouldn't trade it for any other mouse that I've tried and I've tried several $100 mice over the years. The only thing is, if you're used to the weighted mouse, this one is not. It's slightly bottom heavy in its build, but still fairly lite. Lets face it, for $20 bucks you're not out much if you don't like it.

There's little point in using a manager unless you're changing out ENBs often.

You have runs 10 and 22 incorrect. Those runs are as expected. I explained this in my previous post. That is how Boris designed it when ENBSeries is present, so although it's not working as one might think it should work, it's in fact working exactly as it is suppose to giving how ENBSeries is designed. 1. It's well known that Boris develops for Nvidia first and then AMD second. This is mainly because he has an Nividia card and has no way to specifically test for AMD. Nvidia has the following settings via Nvidia Inspector: Force offForce onUse the 3D application setting1/2 refresh rate1/3 refresh rate1/4 refresh rateAnd then a couple of profile-specific choices made to use for specific games.2. As Boris states, iPresentInterval is the hose and ENBSereis is the faucet. I may not be 100% dependent on the parameter for vsync but in what Boris has said, we can conclude that iPresentInterval does in fact play some role that may not be completely spelled out yet. Also, your #3 here is explained from my explanation of the orange highlighted run above. Turning the "faucet" off, stops the flow so you no longer get vsync. That is in ENBSeries design for whatever reason. 3. Um...no. Again, Run 22 is as expected due to how Boris designed ENBSeries. Runs 11 and 23 are the real mysteries out of the runs as to why the FPS is still being limited. Maybe that parameter doesn't actually have much to do with vsync? By looking at those runs I would agree that iPresentInterval certainly seems to have no impact on Vsync....this doesn't mean that it wouldn't have an impact on other areas of the game as many many users are suggesting. 4. I agree and have said that from the beginning. Havok issues are directly caused by very high FPS. I think we've proved that and can put that to rest. 5. Actually, I have tearing in interiors only when there is no vsync. Exteriors are fine regardless of settings. Mine looks similar to this, but rather horizontal. You can see the frames not lining up exactly right on the interior walls. Your EDIT2: Yes, I was typing this as I read and am too lazy to go back and edit it so ignore some of my replying regarding iPresentInterval. I had study that conversation for a good 15-20 mins before I was able to piece together all that was being said so no worries. I summarized the jest of it in my previous post. I would agree with you that we should be telling users to keep it enabled. It seems to have no impact on performance anyway.

Here are my results: As you can see, with Vsync forced off in the drivers it actually stays off as expected. In fact, the result are all as expected except for the highlighted ones. In the orange highlighted run, it should have behaved as if vsync was enabled because with iPresentInterval set to 1, I should have had vsync. However, behave as if no vsync turned on. Due to the fact that the last run on the graphic was fine after taking ENB out of the equation, I can only assume that ENBSeries takes over the vsync functions of iPresentInterval whenever it is installed. This is explained below after some research on the ENB Dev Forums. In the yellow highlighted run, it should have behaved as if there was no vsync because without ENB installed and iPresentInterval set to 0, I should have seen very high FPS but I didn't. Instead it behaved as if vsync was still enabled. This one result I'm baffled about as well. I did a bit of searching and Boris did have a bit of a conversation about this very thing back in August which can be found here: https://enbseries.enbdev.com/forum/viewtopic.php?f=28&t=3322&p=54343 It's in Russian so use Bing Translator (it did a better job than Google). If I'm understanding it correctly, Boris is saying that iPresentInterval needs to be set to 1 when using ENBSeries. He also says that if vsync is disabled in ENBSeries, then it will ignore the iPresentInterval parameter regardless of what it's set to...thus, no vsync. This explains the orange highlighted result above. The user he's talking to mentions STEP and what we have it set to (turning off iPrensentInterval and enabling ENB vsync) mentioning that it doesn't work because it messes up the "game timings". Boris also responds that should not work and that only having both enabled will result in everything working properly. Gather the pieces from the whole conversation and tell me if you understand it the same. Boris also states elsewhere, that iPresentInterval is not "overwritten" by ENBSeries. From this and the other conversation above where Boris refers to iPresentInternal as the hose providing the water and ENB vsync as the faucet controlling the flow, we can assume that iPresentInterval's functions are still in tact and it's only "overridden" when ENB vsync is turned off. So there is the "word" straight from the creators mouth of how it should work and was designed to work.

I'm looking at your result and from what I can tell, when everything is off you're getting over 60FPS which is what should happen. The rest of the time you're getting ~60FPS. Nothing seems off about your results unless I'm missing something. I but will test in a bit. EDIT: I see what you're saying now. You are getting some funky results on your AMD. It would seem your "always off" settings doesn't really apply. As for iPresentInterval, I'd like to hear from some more knowledgeable figures in the community that have more familiarity with how the game works. I'll see about getting some comments on the subject from powers that be. EDIT: Will be posting my results shortly which is much more the expected behavior than what Z is experiencing.

I will not be able to fully get to this until this even but what do you mean here? Could you expand upon what you're saying and asking? Also, just so you know if you're not aware, hitting Shift+F12 in game will not disable the enblocal settings so it will not disable vsync. When testing you'll have to exit the game change it in enblocal.ini and launch the game again. You're also using AutodetectVideoMemorySize=true, which is not advisable. Sometime it works, sometimes it doesn't. Since you're experience was smooth, it might be working for you; even so it might still be assigning retarded amounts of memory to ENBoost as it has done for other users. iPresentInterval is not set anywhere else in an other mod to my knowledge. I'll try to copy your run this evening.

I do know that can happen, yes. But as long as the correct power is given to the card, the motherboard has the correct amount of bandwidth, and the drivers are all up to date...then it's a non-issue. Put all of those factors into play and it rarely matters what system the card is installed in. The performance will be the same. We can't account for every variable such as user error of choosing poor components. At the very least users should have adequate components to run their hardware as it's meant to be ran. That is mainly the point I'm attempting to make that those things shouldn't matter in this testing. You seem to want to take every variable into account and that's just not realistic. Some assumptions will have to be made such as users having their systems set up properly, having the game and ENB/ENBoost install correctly, not having rogue edits in their INIs, etc. iPresentInterval being disabled does not cause havok issues in and of itself. Having it disabled and no other form of vsync or frame rate limiter is what causes the havok issues due to the high FPS that results. The main issues with having iPresentInterval disabled is that other aspects of the game rely on it. NPC paths, some quests, time of day events, etc. All you have to do is a bit of research to find the issues documented across the net. If all you are wanting is for users to test the combinations, then there is no need for myself to do that. It's been done and the setup I'm using now works perfectly fine. One thing that hasn't been mentioned is that before this testing is done, users will need to ensure they have ENBoost set up properly and that doesn't mean just setting it to auto detect and calling it a day. That feature has been well tested and documented to not be reliable even on our own forums. This is important because without ENBoost set up properly, user can experience stuttering and other issues that they may think is vsync but is in fact ENBoost not being optimized for their system. This alone could skew the results. Testing should be done with: The latest video drivers installedThe latest ENBSeries binary (v0.264 and if you already have it, download it again. Boris makes updates without version changes quite often.)Properly configured ENBoostNo rogue INI edits presentNo ENB Managers installed (these have been causing users issues as of late)On a STEP:Extended profile to emulate a modded game and achieve the same load order for testing across different platforms (no extra mods active to control the variables)

Yes. Although I don't know which ENB Manager was being used, but we just did a bit of troubleshooting with a user that parts of the ENB wasn't working (vsync and frame rate limiter to be specific). They were using a manager and as soon as they stopped using it and cleaned their Skyrim root directory of all the crap it put there, the ENB features started working perfectly.

Can anyone here experiencing issues with blocky faces state if they are using the HRDLCs or not? Also, state whether or not those DLCs have been optimized or if you're using an optimized version from an author. Finally, state whether or not you're using Bethesda Hi-Res DLC Optimized or not. We're trying to determine if the blcoky faces are fixed by the HRDLCs or not. We thought they were, but may be mistaken. TIA

Hardware: Please enlighten me as to what any of that has anything to do with vsync operation besides the display adapter (aka Video Card for any user using STEP). System Bus? Really? I don't even know how to respond to that one... the system bus hasn't been an issue in computers for the last 10 years... Other expansion cards, which would most likely be a sound card or NIC, have nothing to do with vsync... Reaching here? Software: We should only be providing testing with the latest stable drivers for Skyrim as I pointed out earlier. There are too many drivers to test and if users don't want to update, that is their problem. We can't cater to every possible scenario or we'd be here for years. We test on the latest drivers for the respective brand (AMD and Nvidia) and provide those results with those drivers. Making it too simple? Possibly, but you're making it way too complicated which is why no one else tested the last time. If you want users to test, don't make it overly complicated or develop an easy way to test what you're wanting to test; otherwise, you'll end up with only one or two testing which is in no where near the data pool you need to find any consensus. I know full well all the interactions within a computer system and how different programs can affect one another. You know I have a lot of knowledge from both schooling and field experience in computers and networking as well. I can tell you, very little to none of those things you've mention is going to have any meaningful impact on the operation of vsync here. If you prove me wrong, I'll eat my words. If you come up with a testing method, I'll be happy to test as long as it's not too complicated. I won't be logging every inch of my system just to test a few combinations out though. I already know what works on my system and am fairly confident it'll work for others because I've passed out the advice a lot and it's always seems to work. Of course nearly all these users were Nvidia users. If something isn't working right for AMD users, it needs to be reported to Boris and he might fix it...if you're lucky. Haha! Yeah, that is all going to have to be retested. Boris has done quite a bit of work since you did all that testing. We really didn't even know that much about all the parameter like we do now when you did that.

Usually I'd be right there with you, but not when it comes to Chrome. Die-hard Firefox fan here.

No clue, I just know that we've been getting reports of some issues. I didn't think to as if those users were using the HRDLCs or not.

The shadows on the underside of grass is usually do to the SSAO settings as well as shadows. Have you messed with any of the ENB parameters?

The mod page needs some updating with better instructions. AutodetectVideoMemorySize=true really shouldn't be used. You can use the ENB Guide: https://wiki.step-project.com/Guide:ENB#tab=ENBoost

I totally forgot about this during the previous release, but we should add "No More Blocky Faces" back into STEP. XCE says it's included; however, the files are missing from the mod. I confirmed this here: https://forum.step-project.com/topic/1392-xenius-character-enhancement-by-xenius/?p=93308 It should be installed directly after XCE.

Boris confirmed that the parameter still works and was added back in v0.209.

I have no idea where you're getting "so many variations of hardware and software" from. Hardware = Video card; either AMD or Nvidia. Software = Skyrim + ENBoost/ENB (makes no difference which because they're both the same) Memory, monitor, hard drive...none of that matters when it comes to the topic of discussion. If anyone is thinking that the monitor matters, it doesn't. Vsync syncs the video card to the monitor's refresh rate regardless of the monitor so that it isn't running faster than what the monitor can display which is commonly called "tearing". That's all there is to it. The monitor itself matters not. The only variation that might not fit into this perfectly is whether the video card is a mobile version or not, but even then it should work the same (this comes from having experience using mobile for over three+ years for gaming). So all we have to figure out is what works best for AMD and what works best for Nvidia on the latest stable drivers (if users don't want to update their drivers that's not our concern). That's it. I see now other variables that would make a difference. As for iPresentInterval, it shouldn't even be in the equation. It should be left on for all users due to certain aspects of the game relying on that parameter to not be changed from its default. The only way we can get 100% confirmation that it isn't needed is to talk to the developers themselves. What we have to rely on is the numerous reports of some things breaking with it off which can be found all over the internet and word from Boris himself which I consider to be one of a few people in an elite class that know how Skyrim functions better than most (others would include Sheson, the SKSE Team, the unofficial patch team, etc). This should be reason enough to leave it enabled. Also, since leaving it enabled does absolutely no harm and has no negative effect on performance (that I have experienced) then it shouldn't even be in question that leaving it enabled is the "best" recommendation.

You have a ton of unneeded and unused permeters in your INIs. The only change besides taking a lot of those parameters out would be to set iPresentInterval=0 to 1. Glad everything is working now!

I can go about the same about of time but it's a complete bogus testing method. You'll never stress the game to that point at any time during normal gameplay. Does crashing doing this test mean your game is unstable? No. It simply means you're pushing the engine to do something that it was NEVER designed to do. The engine is flaky enough without users doing dumb stress tests on it. I don't really care if Vurt can do it without crashing. From my understanding from interactions with him on these forums, his game isn't as heavily modded as most player's games are anyway. I put no merit in that test of his simply because I can crash after 5 minutes of doing it but yet can play all day long, for hours on end without a single issue or crash and can do this time and time again.