Jump to content
  • 0

Fix for Tearing/Stuttering with RCRN



Hi all,


I recently discovered a problem and a fix that I would like to share. I'll try to keep it as simple as possible.


A) Problem:

  • When using Nvidia's Adaptive Vsync, tearing would occur at the same place on the screen, every frame, at 60FPS.
  • When using Nvidia's Standard Vsync under the same conditions as #1, framerate would drop to around 40FPS with what felt like small stuttering.
B) Additional information:

  • The problem was most noticeable and easily reproducible when moving around the world map with WASD keys. (The only map mods I use reduce the size of markers and remove the HUD.)
  • Both problems would only occur when RCRN was being used. Everything was perfectly smooth when I used the Pause button to switch to vanilla.
  • Maximum Pre-Rendered Frames was set to 1 via the Nvidia driver.
C) Solution:

  • When I set Maximum Pre-Rendered Frames to 2, 3, or Application-Controlled, the problem disappeared and everything was perfectly smooth with RCRN enabled. I don't have the option to set it to 0. Mouse lag was not noticeably affected, and VRAM usage has only gone up a few megabytes, if at all.
Edit: Actually, after more play, I realized that some mouse lag was introduced when increasing pre-rendered frames from 1 to 2.  See my update.


D) Other thoughts:

  • I suspect this may be a problem with post-process injection altogether and not just RCRN. I had the same problem as #A.1 when using the SMAA injector and framerate limiter (60 FPS cap via Nvidia Inspector). I don't use SMAA anymore but I may go back to it for further testing. Basically, I suspect that vertical synchronization is designed with the expectation that post process injection will NOT be used and that it can throw the frame buffers out of sync even though it still limits the framerate. This is just an educated guess.
  • I don't recall having this problem when I used a post-process injector that simply limited the framerate to 60. It showed up when I ditched that injector for the SMAA injector, and again when I ditched SMAA for RCRN. Perhaps controlling Vsync via post-process injection will ensure that the frame buffers are synchronized?
E) My Specs:



1) Hardware:

Core 2 Duo E8400 @ 3.6GHz

4GB DDR3 1600

GTX 460 768MB @ 825/1100

1920x1080 resolution


2) Software:

Windows 7 x64

Nvidia 301.42 WHQL

Skyrim 1.5.26

RCRN 3.0.1 with FXAA and all sharpening disabled


3) Nvidia Settings:

AO - Quality

AF - 16x



4) Skyrim Settings:

Ultra with tweaks

AA - Off

AF - Off

uGrids - 7

Can provide .ini details if necessary.


5) RCRN Settings:

Legacy preset

FXAA disabled

All sharpening disabled


6) Possibly relevant mods:

RCRN (of course)

Hi-Res DLC Optimized - Hybrid + Vanilla normal maps

Static Mesh Improvement Mod

Several other texture mods that improve nordic ruins, dungeons, armor, and NPC detail

Shadow Striping Fix

(Will list more if I remember them.)


7) Average framerate at top step of Dragonsreach with view centered on Gildergreen: 41 FPS



Link to comment
Share on other sites

6 answers to this question

Recommended Posts

  • 0

Thought I'd post an update.


After some more testing, I determined that the problem is specific to the HDR feature of RCRN. The problem is there even if I just use single pass HDR. Disable HDR completely, and it goes away. So, if I want my game to run perfectly smooth, I need to do one of the following:


1) Yes Vsync, Yes HDR, 2 Pre-rendered frames.

2) No Vsync, Yes HDR, 1 Pre-rendered frame.

3) Yes Vsync, No HDR, 1 pre-rendered frame.


Just thought I'd throw this out there for other RCRN users.

Link to comment
Share on other sites

  • 0

maximum number of pre-rendered frames shouldn't be set to 1 in the first place. I think 1 was a tweak for FPS's but either way it DEFINITELY will increase stutter if your system is struggling to keep up. default is 3 i believe, which allows the video card to have a small buffer of frames to prevent stuttering. (or I may be confusing this with double/triple buffering on vsync, but I believe it works in the same way)


also, I think RCRN is only related to this because the post processing may be pushing your GPU over the edge due to the performance hit of the injector/shader. (though it should be very minimal)

Link to comment
Share on other sites

  • 0

The stutter is definitely not due to something as simple as a straight-up FPS drop due to more demanding graphics.  I've ruled that out.  FPS is almost exactly the same between items #1, #2, and #3 listed in my last post.


By the way, using 2 pre-rendered frames gives me small but noticeable input lag, so I've simply opted out of vsync.  I find this to be the least annoying of all three options - tearing seems to be rather uncommon at my current settings.


The DirectX substitute for "triple buffering" is to use just 1 pre-rendered frame.  The default of 3 is overkill, though it is still best for SLI (for very different reasons).


I still suspect that post-process injection does something to muck with frame buffers - perhaps requiring a third buffer over the standard two (making 1 pre-rendered frame an absolute requirement while 2 is the NEW replacement for "triple buffering" -  not just 1 as was previously the case).


You may want to read these two articles:

Triple Buffering: Why We Love It

Exploring Input Lag Inside and Out

Unfortunately, all other implementations that call themselves triple buffering are actually one frame flip queues at this point. One frame render ahead is fine at framerates lower than the monitor refresh, but if the framerate ever goes past refresh you will experience much more input lag than with vsync alone. For everyone without multiGPU soluitons, we recommend setting flip queue or max pre-rendered frames to either 1 or 0. Set it to 1 if framerate is always less than monitor refresh and set it to 0 if framerate is always greater than or equal to monitor refresh. If it goes back and forth, only NVIDIA's OpenGL triple buffering will provide the best of both worlds without tearing and will further reduce input lag in high framerate situations.

Improperly handling vsync (enabling or disabling a 1 frame flip queue at the wrong time) can degrade performance by at least one additional whole frame. But with multiGPU options, we really don't have a choice. With more than one GPU in the system, you will want to leave maximum pre-rendered frames set to the default of 3 and allow the driver to handle everything. Input lag with multiGPU systems is something we will want to explore at a later time.

Link to comment
Share on other sites

  • 0

Hmm, interesting. If 1 pre-rendered frame means it's kind of tripple buffering WITHOUT vsync on, then that must mean it uses by default two pre-rendered frames. possibly the front buffer, back buffer, and then the 1 pre-rendered. but this still doesn't sound right. what then does D3DOverrider do? i know it hasn't been updated in ages but it's supposed to make DirectX triple buffered. or maybe it just overrides the flip-queue sort of.


And regarding vsync, if I read that correctly, a 1-flip-queue buffer means the system has to skip an additional frame when the fps drops below refresh in order to sync back up again? I remember reading something posted by a nvidia developer about vsync something along the lines of this: "when your VSYNC'd fps drops below the monitor Hz, you experience a stutter as a frame is dropped (the fps momentarily drops to 1/2 or 1/4 your refresh), and then another stutter to sync up the back-queued frames." they were working on a fix for this so it would gradually sync up again instead of all at once.


personally I can't tearing so I could never play with vsync off. tearing will always happen, it just is more noticeable to some people.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...

Important Information

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