logo
Main

Forums

Downloads

Unreal-Netiquette

Donate for Oldunreal:
Donate

borderline

Links to our wiki:
Wiki

Walkthrough

Links

Tutorials

Unreal Reference

Usermaps

borderline

Contact us:
Submit News
Page Index Toggle Pages: [1] 2 3  Send TopicPrint
Very Hot Topic (More than 25 Replies) [227j_35] FrameRateLimit cvar for XOpenGL (Read 3624 times)
shoober420
Betatester
Offline



Posts: 191
Location: US
Joined: Jun 17th, 2012
Gender: Male
[227j_35] FrameRateLimit cvar for XOpenGL
Apr 16th, 2016 at 8:27pm
Print Post  
Could someone please add the "FrameRateLimit" cvar for the new XOpenGL render? I don't use VSync in any games because of input lag.
  
Back to top
 
IP Logged
 
Smirftsch
Forum Administrator
*****
Offline



Posts: 7414
Location: at home
Joined: Apr 30th, 1998
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #1 - Apr 20th, 2016 at 6:33pm
Print Post  
someone? mmh...

I can add FrameRateLimit I think, but I can't say that I like the way it works. Did you try VSync=Adaptive already? Maybe it does what you want Smiley
  

Sometimes you have to lose a fight to win the war.
Back to top
WWWICQ  
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 496
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #2 - Apr 20th, 2016 at 9:46pm
Print Post  
Imho such a setting/feature should basically modify what UEngine::GetMaxTickRate() returns, and not be part of anything else but Launcher / this specific UEngine virtual.
  

HX on Mod DB. Revision on Steam.
Back to top
 
IP Logged
 
shoober420
Betatester
Offline



Posts: 191
Location: US
Joined: Jun 17th, 2012
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #3 - Apr 21st, 2016 at 2:14am
Print Post  
I have a couple questions to ask. So you're both saying the way the old OpenGL render handles the FPS cap is bad?

What is the correct max FPS to render Unreal at full speed without it being to fast or too slow? For example, the Goldsrc engine has a limit of 100 FPS before things start to render too fast/incorrectly. I thought this was the same for the Unreal99 engine, so I always set it too 100 as well.

Can this be achieved the right way without using VSync?
« Last Edit: Apr 21st, 2016 at 4:15pm by shoober420 »  
Back to top
 
IP Logged
 
Smirftsch
Forum Administrator
*****
Offline



Posts: 7414
Location: at home
Joined: Apr 30th, 1998
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #4 - Apr 21st, 2016 at 7:46am
Print Post  
https://www.opengl.org/wiki/Swap_Interval#Adaptive_Vsync
as said, this is supposed to fill this gap, although it seems not to work for everyone.

In 227 many things have been fixed and clamped so that it usually doesn't behave bad anymore. When benchmarking I often disable vsync entirely and I am getting 600FPS+ without noticeable side effects.

On the other hand, of course, if something works, it works- and it does so in the UTGLR's for years now, so it's hard to say it's all crap and even a "bad" solution is better than no solution.
  

Sometimes you have to lose a fight to win the war.
Back to top
WWWICQ  
IP Logged
 
[]KAOS[]Casey
Oldunreal MasterPoster
*
Offline


nedm

Posts: 3069
Joined: Aug 7th, 2011
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #5 - Apr 21st, 2016 at 3:24pm
Print Post  
shoober420 wrote on Apr 21st, 2016 at 2:14am:
What is the correct max FPS to render Unreal at full speed without it being to fast or too slow? For example, the Goldsrc engine has a limit of 100 FPS before things start tomrender too fast/incorrectly.


120 is where it starts to get a little wonky, but it doesn't necessarily go too crazy at that point.
  
Back to top
 
IP Logged
 
shoober420
Betatester
Offline



Posts: 191
Location: US
Joined: Jun 17th, 2012
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #6 - Apr 21st, 2016 at 4:19pm
Print Post  
I'm asking about this because when I started up the game with the new render with VSync disabled, it was running too fast.

I don't know how the frame rate limit cvar works, but from what you guys are saying, it's not the proper way to limit the FPS. So beside VSync, is there a decent solution to limit FPS to 120?

Here's the issue, if I want to play with 120 FPS, I'll have to set my refresh rate to 120hz as well, or my FPS gets capped to 60/75 because of VSync. I have a CRT, so if I want 120hz, I have to lower my resolution to something like 1280x960 for 120hz with maximum resolution. I play at 2048x1536 normally, which has a max of 75hz for refresh rate.

According to the UTGLR documentation, the frame rate limit cvar looks like it throttles the CPU to keep it at the desired FPS. I don't think that's a good way of limiting FPS either. There must be a better way to limit it too 120...
  
Back to top
 
IP Logged
 
[]KAOS[]Casey
Oldunreal MasterPoster
*
Offline


nedm

Posts: 3069
Joined: Aug 7th, 2011
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #7 - Apr 21st, 2016 at 4:51pm
Print Post  
See this topic about the water texture. http://www.oldunreal.com/cgi-bin/yabb2/YaBB.pl?num=1454440358

Unless your driver implements something like AMDs frame rate target control (supposedly doesn't work on openGL), which I use to limit some games which physics are tied to framerate, far as I know there's no way right now.
  
Back to top
 
IP Logged
 
Masterkent
Developer Team
Offline



Posts: 797
Location: Russia
Joined: Apr 5th, 2013
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #8 - Apr 21st, 2016 at 6:40pm
Print Post  
Smirftsch wrote on Apr 21st, 2016 at 7:46am:
https://www.opengl.org/wiki/Swap_Interval#Adaptive_Vsync
as said, this is supposed to fill this gap, although it seems not to work for everyone.

How could making vsync adaptive help to cope with input lag in case of Unreal?

Proper handling of input without additional tricks should be sufficient for making input lag barely perceivable. Use of triple buffering could then reduce it to minimum.
  
Back to top
 
IP Logged
 
[]KAOS[]Casey
Oldunreal MasterPoster
*
Offline


nedm

Posts: 3069
Joined: Aug 7th, 2011
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #9 - Apr 21st, 2016 at 7:22pm
Print Post  
han wrote on Apr 20th, 2016 at 9:46pm:
Imho such a setting/feature should basically modify what UEngine::GetMaxTickRate() returns, and not be part of anything else but Launcher / this specific UEngine virtual.


This is actually probably a great idea, or at least something to experiment with.

I could make a UGameEngine shim interface (for 227i) that allows us to tweak the tick rate for testing. I am sure Epic put in proper max tick rate code, i.e. to sleep to create the proper frame rate instead of letting the renderer do it. This will also likely get a better framerate limit control in general and obsolete the ones in d3d/ogl.

from what I understand the getmaxtickrate returns 0 (No control) on clients and <=120 (controlled), where < is your tick rate settings on servers.
  
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 496
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #10 - Apr 21st, 2016 at 8:34pm
Print Post  
Default code does something like to try to match approx the desired framerate. The question is if that is actually what is intended in this situation.

But from my experience I can just tell that I never had the need for limiting the framerate in any UE1 game other then to make that it won't go below 1/200sec a frame, so the clamp in ULevel::Tick() won't mess up stuff.
  

HX on Mod DB. Revision on Steam.
Back to top
 
IP Logged
 
Smirftsch
Forum Administrator
*****
Offline



Posts: 7414
Location: at home
Joined: Apr 30th, 1998
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #11 - Apr 22nd, 2016 at 6:24am
Print Post  
Masterkent wrote on Apr 21st, 2016 at 6:40pm:
Smirftsch wrote on Apr 21st, 2016 at 7:46am:
https://www.opengl.org/wiki/Swap_Interval#Adaptive_Vsync
as said, this is supposed to fill this gap, although it seems not to work for everyone.

How could making vsync adaptive help to cope with input lag in case of Unreal?

Proper handling of input without additional tricks should be sufficient for making input lag barely perceivable. Use of triple buffering could then reduce it to minimum.


From what I've learned over all the years, there are endless ways to how someone can experience lag. It's only logical to me eliminate this possibility first.

Both Windows and Linux (SDL2) implementation offer "RawHID" input, although it is not called that way in Linux its very much the same and shouldn't be affected by DesktopEnvironment.
One other factor is also "MouseSmoothing", which should be turned off perhaps by default, but this is a different topic.
I doubt it is the input system itself causing a problem here, especially not under consideration that the method used by FrameRateLimit seems to solve this issue.
Han's idea seems to be worth a look in any case.
  

Sometimes you have to lose a fight to win the war.
Back to top
WWWICQ  
IP Logged
 
Masterkent
Developer Team
Offline



Posts: 797
Location: Russia
Joined: Apr 5th, 2013
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #12 - Apr 22nd, 2016 at 10:33am
Print Post  
Smirftsch wrote on Apr 22nd, 2016 at 6:24am:
From what I've learned over all the years, there are endless ways to how someone can experience lag. It's only logical to me eliminate this possibility first.

If the input system is implemented properly, max input lag should not exceed 1/FPS seconds, and 16 ms lag is barely perceivable. As far as I can see, the input lag in Unreal can be much higher than the delay caused by postponed displaying a frame.

Quote:
Both Windows and Linux (SDL2) implementation offer "RawHID" input, although it is not called that way in Linux its very much the same and shouldn't be affected by DesktopEnvironment.

I do have a quite well perceivable input lag with enabled VSync and RawHIDInput and disabled Mouse Smoothing, hence there is a bottleneck in the entire input system that introduces the lag. It may be either a problem of how input capturing with RawHID is implemented or a problem of how the captured input is processed further, or both.

Quote:
I doubt it is the input system itself causing a problem here

I don't see any other theoretical possibilities. What else could introduce the lag?

Quote:
especially not under consideration that the method used by FrameRateLimit seems to solve this issue.

When VSync is enabled, FrameRateLimit indeed helps to reduce input lag somehow, but this only means that it negates the influence of bugs in the input system.

Quote:
Han's idea seems to be worth a look in any case.

Yes, but that won't do anything with the root of the problem.
  
Back to top
 
IP Logged
 
Smirftsch
Forum Administrator
*****
Offline



Posts: 7414
Location: at home
Joined: Apr 30th, 1998
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #13 - Apr 22nd, 2016 at 10:49am
Print Post  
unlike the closed windrv system all SDL2 is free as it's an adaption of the old SDL system. I can hand it over if you want to have a look.
  

Sometimes you have to lose a fight to win the war.
Back to top
WWWICQ  
IP Logged
 
shoober420
Betatester
Offline



Posts: 191
Location: US
Joined: Jun 17th, 2012
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #14 - Apr 22nd, 2016 at 3:06pm
Print Post  
To clarify,  I have input lag in all games when I enable VSync. Im very sensitive to it and notice it immediately. I play Counter-Strike 1.6 at 640x480 with a whopping 170hz refresh rate. So it's super smooth. It's practice for me to keep VSync disabled in all my games.
« Last Edit: Apr 22nd, 2016 at 5:44pm by shoober420 »  
Back to top
 
IP Logged
 
Page Index Toggle Pages: [1] 2 3 
Send TopicPrint
Bookmarks: del.icio.us Digg Facebook Google Google+ Linked in reddit StumbleUpon Twitter Yahoo