Jump to content

STEP v2.2.9 Official Bug Reports


EssArrBee

Recommended Posts

Maybe it'll be beneficial if you ask precisely what you want tested so that a conclusion can be found using the community

 

like in this case:

hardware requirement: AMD/nVidia gpu

Any load order (doesn't matter which mods are used)

minimum: ENBoost

inis not needed

 

iPresentInterval=(1/0)

enblocal.ini Vsync=(true/false)

driver Vsync setting (app controlled/always off)

 

If you want something (re)tested just ask and try to account for all the variables for each person.

Id even do a quick test like that...

It takes what 10 minutes but in this case there is only 7 combinations

Link to comment
Share on other sites

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 installed
  • The latest ENBSeries binary (v0.264 and if you already have it, download it again. Boris makes updates without version changes quite often.)
  • Properly configured ENBoost
  • No rogue INI edits present
  • No 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)
Link to comment
Share on other sites

@Tech

I am glad you are doing the research on ENB settings ... just read the latest on the wiki for ENBoost, and I think that you should update the STEP notes in accordance with your findings.

 

Now, regarding iPresentInterval and other settings we are discussing here, the testing regime is very obvious, and you and hishutup nailed it (it really goes without saying IMO). Here are my results for STEP Core 2.2.9 ... I tested by COCing to whiterun with a brand new character. I ran from the bridge to outside of Honningbrew Meadery, summoned a dragon, then entered the meadery and threw around some plates. I noticed that in some runs --when looking away from Sabjorn and otherwise remaining still-- I could hear the havok noises of the stuff I threw around as if someone else were walking all over them. Since nobody else was moving around, these noises represent a havok glitch ... (see specs in sig):

 

vsync%20testing.JPG

 

This tells me some important facts regarding my own unique system:

  1. iPresentInterval has absolutely no impact at all on any of the variables in the context of my testing.
  2. ENBoost vsync settings are the sole determinant of vsync toggle when ENB is installed.
  3. When ENB is not installed, vsync appears to function irrespective of either iPresentInterval or driver settings
  4. havok sound bugs are caused by high FPS or other source, and not vsync directly
  5. on my system in the context of this testing, there is no reason to use vsync at all, because I get none of the graphic glitching that calls for it
  6. My video drivers seem to have no impact on vsync, except to

My overall interpretation is that ENB is the main player in any wierdness of my past testing, and as was mentioned a few posts up, Boris' releases each have variable effects that are not well understood, documented, or observed (let's face it, each release is a beta). I am perplexed by the limiting of my FPS to my frame monitor refresh rate when I have no apparent app forcing vsync and by the lack of impact of my video drivers on vsync. There is obviously more at play here that I am not at all aware of (any ideas?)

 

Regarding variation in user environments: Even if all is set up correctly and all drivers updated accordingly, user variation still exists due to differing environments, and these diffs can cause different results for just about anything, including vsync/FPS behaviors.

 

It is all still pretty unclear to me, but I would really like to have corroboration from other AMD card users as well as from Nvidia users.

 

Question: is iPresentInterval set in any STEP mods or other INIs? (I checked skyrim.ini, and it was not there) ... my enblocal.ini is attached

enblocal.ini

Link to comment
Share on other sites

I am perplexed by the limiting of my FPS to my frame rate when I have no apparent app forcing vsync and by the lack of impact of my video drivers on vsync. There is obviously more at play here that I am not at all aware of (any ideas?)

 

Question: is iPresentInterval set in any STEP mods or other INIs? (I checked skyrim.ini, and it was not there) ... my enblocal.ini is attached

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.

Link to comment
Share on other sites

If you look at my results, you will see that --even with no software defining vsync-- I am effectively getting vsync behavior (FPS limit) ... I cannot say if this is just on my system or if there is some other setting somewhere (a mod INI, fe) that is setting iPresentInterval=1.

 

(I said "frame  rate" but meant "monitor refresh rate" ... corrected in my post)

 

 

translates to:

I am puzzled that my FPS is limited to my monitor refresh rate even though I am not toggling vsync in any of the applications able to set it. This happens specifically when ENB is totally disabled, so there must be something else either limiting my frame rate or toggling vsync, and this behavior stops if ENB is enabled with EnableVSync=false

 

 

I did not use KB shortcuts to toggle ENB ... I made all changes directly to the INI.

Link to comment
Share on other sites

I find the iPresentInterval comments to be intriguing.  I haven't played Skyrim recently due to the Better Quest Objectives mod not being compatible with the most recent versions of Extensible Follower Framework.  Been waiting a while for the patch for that mod to be updated.  But, back when I was playing the game, I had issues with the Run for your Lives mod - NPCs often not going indoors following a dragon attack.  I probably always had iPresentInterval set to 0 - I just checked my skyrimprefs ini and that's what it says...  I'm wondering if that was what was breaking the NPC behavior or not...  Just a thought, if anyone wants to experiment with that or consider it.  Maybe it means nothing.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Here are my results:
2UdMRcp.png
 
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.

Link to comment
Share on other sites

With those results, I can only assume that iPresentInterval doesn't control the internal VSync switch of the game.

 

Without any means of external VSync it is still enabled regardless of it's value. Is there any source from the devs that this parameters actualy controls VSync ?

 

Maybe it just controls timing events, which will make more sense when taking the name of the parameter.

 

I switch it on, like Boris said and no more glitches with npcs and events. Or it's a placebo effect.

Link to comment
Share on other sites

Thanks for the data, Tech.

 

based on your and my findings together, I have aggregated our results (attached for edit and shown below):

 

2014-11-20_13-20-17.png

 

Observations:

  1. Driver Settings:
    1. NVIDIA software effectively controls whether or not Skyrim and ENB apps can control vsync ... are there other settings besides "Force off" and "App controlled"?
    2. AMD driver settings don't seem to affect other apps' effect on vsync, given all of the evidence (at least ENB seems agnostic of AMD driver settings ... see trials 1 & 2). AMD allows app-specific 3D settings independent of the 'master', which adds a layer of complexity (I tested using my custom-defined TESV.exe-specific driver settings and confirmed that they override the master settings, but AMD dirivers bundle app-specific profiles into the drivers, and this is supposedly overridden by my custom profile, so that adds a layer of control that confounds the driver settings). This all points to ENB not originally (or as successfully) being implemented for AMD-based GPUs. AMD has four vsync settings:
      1. Always off
      2. Off, unless app specifies
      3. On, unless app specifies
      4. Always on
  2. ENB settings:
    1. Work dependably and consistently to control vsync (when allowed by NVIDIA)
    2. Are NOT dependent on iPresentInterval=1 as Boris has stated (at least not in v264, which is what I used or in whatever version Tech used if more recent). This is evidenced by trials 7 & 19.
    3. Whenever ENB vsync is set to 'false' (irrespective of driver or skyrim INI settings), we have FPS/havok issues. Since this is not necessarily the case when ENB is disabled (removed from ./skyrim), we must conclude that ENB has some impact on FPS limits/vsync when enabled with vsync turned off (compare trials 10 & 12 and 22 & 24).
  3. iPresentInterval Setting:
    1. No conclusive evidence exists that this setting has any impact at all.
      1. Where it may seem to have an impact (see trials 12 & 24), it can be explained away by its obvious lack of impact in trials 10 & 22
  4. FPS >> 60 is the most likely explanation of any havok issues unjustifiably attributed to iPresentInterval=0. The INI setting only possibly affects havok issues indirectly by allowing FPS to greatly exceed monitor refresh rates on systems with powerful video cards. Given the evidence of the actual impact of this INI setting, I would say that this evidence debunks that hertofore spurious theory.
  5. Tech and I have powerful GPUs, so we are possibly not seeing graphics glitches like screen tearing and microstutter because of this (but high FPS issues are apparent).

These kinds of inexplicable results are what lead me to attributing the "black box" to unknown hardware/software diffs among systems. There is more to be done though before i accept the black box nonsense.

  • Test again under minimal Skyrim install with just ENBoost mod instead of STEP:Core to reduce the possibility that unknown FPS limiting is caused by some other mod-specific parameter.
  • Test again in mid/lower-end systems
  • Test additional AMD driver settings

 

 

EDIT: in response to Freyrgjurd's last post, you should test only the impact on the supposed havok issues by turning on/off iPresentInterval in a minimal setup without any other vsync control enabled. If the issues are not consistent, then a definitive test is not posible and the role of iPresentInterval on havok issues remains in question.

 

EDIT2: looking more closely at that Russian conversation, it would seem that iPresentInterval does not set vsync at all but rather sets game-character-event sync and this may somehow influence the ENB vsync (and other vsync) implementation. That explains why our FPS impact is still affected when Enablevsync=true and iPresentInterval=0 (i.e., some other aspect of ENB must be influenced and not vsync per se). I think that it is sensible then that we recommend iPresentInterval be set to 1, which is default, so we should get rid of that recommendation.

Book1.xlsx

Link to comment
Share on other sites

You have runs 10 and 22 incorrect. Those runs are as expected. I explained this in my previous post. :ermm: 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 off
  • Force on
  • Use the 3D application setting
  • 1/2 refresh rate
  • 1/3 refresh rate
  • 1/4 refresh rate
  • And 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?  :psyduck:  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  ::P:  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.

Link to comment
Share on other sites

OK, I understand the hose/faucet thing now ... that analogy is not so clear though and why I did not really get it at first. A better way to say it is that iPresentInterval is the supply and Enablevsync is the valve.

 

The real mysteries are trials 5, 11, and 23 (no supply, no valve, should be no FPS limit) as well as trials 7 and 19 (no supply, valve open ... should be no FPS limit according to Boris if we understand him correctly).

 

I think it is safe to say that iPresentInterval does NOT control vsync as almost everyone thinks. It probably does control time-event sync, but I have never noticed myself. Also for the record, this setting does not belong in [Display] section of skyrim.ini as so many people suggest on many forums. It belongs in skyrimprefs.ini. It probably would not hurt any, but such advice really drives a wedge into troubleshooting issues that may be related to the setting when the value is set in 1+ places.

 

As I said before, we need to test against vanilla to confirm 5, 11 and 23 and on lower systems in order to get more of an idea about optimal settings for microstutter and screen tearing (I get no tearing or microstutter at all indoors or out in all cases). I will get to vanilla and various AMD driver settings that remain untested this weekend. If anyone out there has a low-mid range computer and would not mind running the trials, that could be enlightening.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.