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 4322 times)
Masterkent
Developer Team
Offline



Posts: 864
Location: Russia
Joined: Apr 5th, 2013
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #30 - May 5th, 2016 at 9:59am
Print Post  
han wrote on May 4th, 2016 at 1:48pm:
This way one additional frame delay is already caused by mouse curser rendered by game using the prior position

Why does it use the prior position?
  
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 517
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #31 - May 5th, 2016 at 10:18am
Print Post  
Okay now I added some code to my OpenGLDrv to wait after the buffer swap is performed. Especially in case of default Unreal content on 226b this indeed reduces input lag and especially also seems to greatly reduce the variance of the input delay. It feels indeed better. Haven't tried on 227j without RawInput yet.

I assume this is a direct and less issue prone way of achieving roughly the same which utglr tries to do with it's frame rate limiting code.

Code
Select All
	// Unlock and render.
	check(LockCount==1);
	//glFlush();
	if ( Blit )
	{
		//CheckErrors( TEXT("Unlock") );
		STAT(Stats.SwapCycles=0); // Reset here.
		STAT(clock(Stats.SwapCycles));

		// Swap Buffers.
		verify(SwapBuffers(Context.hDC));

		// Fence to spent rest of the frame waiting here, to reduce input latency.
		if ( FenceBufferSwaps )
		{
			// Do some drawing which needs to wait for buffer swapping performed.
			glBegin( GL_LINES );
				glVertex2f( +1.0f, -1.0f );
				glVertex2f( -1.0f, +1.0f );
			glEnd();

			// Fence and wait.
			#define SWAP_FENCE_TIMEOUT 20000000
			GLsync SwapFence = Context.glFenceSync( GL_SYNC_GPU_COMMANDS_COMPLETE, 0 );
			Context.glClientWaitSync( SwapFence, GL_SYNC_FLUSH_COMMANDS_BIT, SWAP_FENCE_TIMEOUT );
			Context.glDeleteSync( SwapFence );
		}

		//glFinish();
		STAT(unclock(Stats.SwapCycles));
	}
 



Anothing thing which came to my mind is that maybe rendering to the backbuffer also would cause about a 1 frame delay, or am I mistaken?
  

HX on Mod DB. Revision on Steam.
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 517
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #32 - May 5th, 2016 at 10:20am
Print Post  
Masterkent wrote on May 5th, 2016 at 9:59am:
han wrote on May 4th, 2016 at 1:48pm:
This way one additional frame delay is already caused by mouse curser rendered by game using the prior position

Why does it use the prior position?

Because mouse position is grabbed before starting to render the frame. So if you change it during the frame, the game renders the cursor still at the position it was one frame before, but your custom mouse cursor drawing code already draws it at the new position.
  

HX on Mod DB. Revision on Steam.
Back to top
 
IP Logged
 
Masterkent
Developer Team
Offline



Posts: 864
Location: Russia
Joined: Apr 5th, 2013
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #33 - May 5th, 2016 at 2:23pm
Print Post  
han wrote on May 5th, 2016 at 10:20am:
Because mouse position is grabbed before starting to render the frame.

Depending on point of view, the input is always handled before or after rendering a frame (or particular objects within a frame). The question is when the mouse input is processed: between capturing the mouse input and rendering the udpated image or not (that is, the alternative would be: capturing the input takes place between processing the most recent captured input and rendering the update image - this doesn't makes sense, IMHO).

Quote:
So if you change it during the frame, the game renders the cursor still at the position it was one frame before, but your custom mouse cursor drawing code already draws it at the new position.

I don't get that explanation. Considering plain VSync model, we can do the following things after the back and the front buffers are swapped:

1) capture user input,
2) update the program state using the most recent captured input,
3) render the view of the produced program state,
4) wait for the next swapping of buffers.

These 4 operations constitute one program tick.

In the game, operation #1 includes determining mouse offset since the previous capture operation (performed on the previous tick), operation #2 includes determining the new rotation of the player or the new location of the in-game mouse cursor.

In my program, operations #1 and #2 are simulated by generating coordinates where the mouse cursor should appear.

In both cases (game / my test program) a view of the resulting program state will not be displayed until operation #4 is completed. Is this that one-frame delay you're talking about? It's present in my program too then.
  
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 517
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #34 - May 5th, 2016 at 10:08pm
Print Post  
Oh I was somehow assuming you put that code into some RenDev code and using it inside the game, not that it is a standalone program.
  

HX on Mod DB. Revision on Steam.
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 517
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #35 - Aug 7th, 2016 at 6:48am
Print Post  
Some update, I stumbled upon an article about Triple Buffering: http://www.anandtech.com/show/2794 (I have not read it in detail, thought it appears that they assume that rendering for vsync starts at the beginning of the time slot for a double buffered scenario, which is in fact not true, so take it with a grain of salt.)

The basic idea is to have three buffers. One for outputting the image, so you won't get screen tearing, one for rendering into, and one you previously rendered. The idea is that you can continue rendering and won't need to wait for the buffer swap to happen in a double buffer scenario and you might finish rendering another frame by the time the monitor gets refreshed.

My thoughts on this technique that it is probably a solution which a good share of people will prefer on a scenario with very high fps.

On a scenario with fps beeing barely over the refresh rate, like lets say it takes 16ms between screen refreshes and 15ms to render the frame. For the wait for buffer swap scenario, the input latency will stay nearly constant at 16ms. For the triple buffering scenario, the point of grabbing the input (modulo 16ms) will move 1ms backwards every frame. So in the absolut worse case of missing barely the swap before finishing the frame, the latency will increase to 15ms+16ms=31ms. For the next frame the latency will be about 16ms, 17ms on the next one, 18ms, up to 31ms again. So in this case, the latency varies periodically (!) between ~15 to ~30ms. And is on average 1.5 times higher and has an increadible large variance of up to 15ms (!). Even worse, as the latency varies peridically one might even notice this behavior.
This makes triple buffering an infeasable option for frame rates slightly above the refresh rate.

On a scenario with fps beeing a few times higher, lets say it takes 16ms per frame and the rendering takes 5ms per frame the situation changes. When waiting for buffer swapping the latency will stay constant at 16ms, but for tripple buffering the latency will vary between 5ms and 10ms, so one gets an average latency of (7.5+-2.5)ms, which greatly reduces latency and adding some slight variance to the latency. In this case, cerainly a good share amount of users would prefer the triple buffering.


Availibitly/Control over it seems to be very IHV-API combination specific. Haven't researched details yet.
  

HX on Mod DB. Revision on Steam.
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 517
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #36 - Nov 14th, 2016 at 6:54pm
Print Post  
  

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 #37 - Feb 23rd, 2017 at 4:59pm
Print Post  
Any word on implementing this CVAR? I could just use VSync, but I would be limited to my refresh rate for FPS. I play UT99 engine games at 200 fps, and my monitor doesn't go up that high. It's max is 170Hz for the CRT. Most LCDs are 144Hz when they are gaming grade. Thats limiting fps to 170/144 instead of the engines max which is 200. An fps above 200 will cause glitches in UT99 engine games.
  
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 517
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #38 - Feb 25th, 2017 at 9:53am
Print Post  
Limit frametime to 5ms isn't really a job of the render device, in fact it shouldnt even dare to touch that, but rather of the launcher.
  

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



Posts: 7534
Location: at home
Joined: Apr 30th, 1998
Gender: Male
Re: [227j_35] FrameRateLimit cvar for XOpenGL
Reply #39 - Feb 26th, 2017 at 11:51am
Print Post  
yeah, indeed should take a look to add it there.
  

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 #40 - Mar 22nd, 2017 at 2:08am
Print Post  
I've been comparing XOpenGL and the original OpenGL with VSync enabled, and for some reason, XOpenGL is alot more sluggish when VSync is enabled.  I made it fair and limited the FPS to "75" so it would match the refresh rate of my monitor and limit the FPS to 75 when it was enabled, and XOpenGL felt way more sluggish and ghosty. The character movement was definitely not as responsive, and even mouse movement and the mouse cursor in the menu wasn't as snappy as the original OpenGL render with VSync enabled.

It's very similar to the feeling when you set "Maximum Pre-Rendered Frames" to a high value in the Nvidia control panel.
  
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