Input feels delayed at 60FPS

[SuperV1234]

VSync is off, framerate is constant and I'm getting input using the Keyboard class.

At 60FPS, the input feels delayed (I don't have any better word for it).
At 150+FPS it feels just fine.

What could be causing this?

[kolofsson]

HAHA welcome to the club. Im really puzzled that nobody had problems with it before .

Check this: http://sfml-dev.org/forum/viewtopic.php?t=6237

With vertical sync you get a framerate pegged to 60/75/100 Hz. This is because each frame the window.display() pauses the whole application until the graphics card decides it is safe to fill the video buffer without the risk of tearing.

So, in 60 FPS 1 frame lasts 1 / 60 = 0,01667 seconds

Now, imagine you press a key just after the display method was called. It waits and waits, and your input stays unregistered. The worst case is getting 0,0166 delay because of Vertical Sync.

Laurent, maybe it would be possible for you to put the window.display in a thread, so it would not freeze the whole application? I really don't see why limiting DISPLAY framerate should limit the CALCULATION framerate.

A partial solution to your problem could be sth like this. It's in python but you may use the sf::Clock instaead of time:

Code: [Select]

     if time.clock() - last_display > 0.016:
         window.clear(sf.Color(200,   0,   0))
         window.display()
         last_display = time.clock()

It calls the window.display right before the Vertical Sync

[Laurent]

SFML is very low-level, it provides building blocks but then it's up to you to decide how to use these blocks. If you want display and input to be separated, then separate them

But to be honest, I've never had problems with input at 60Hz, I think it is responsive enough for most applications. What kind of app are you developping? What are inputs used for?

[kolofsson]

SFML is very low-level, it provides building blocks but then it's up to you to decide how to use these blocks. If you want display and input to be separated, then separate them

But to be honest, I've never had problems with input at 60Hz, I think it is responsive enough for most applications. What kind of app are you developping? What are inputs used for?

I created an app that measures response time. Since typical human response ranges between 0.2 and 0.3 second, I would need better granularity than 0.0166 of a second. Without it my app is showing 0.233 all the time (exactly 14 frames out of 60).

Here is my app (windows, but runs on wine):
http://grebocin.com/upload/screenway11.zip

My final goal is to make an online racing game and I think it would be useful to shave off these extra 16 ms of lag that the display generates.

I agree about the blocks thing, but unfortunately I can't create some blocks myself. If SFML could at least retrieve refresh rate of current video mode, I would know when to call window.display to cause the least delay. Also, I think it's not possible to get a list of supported refresh rates at given resolution or to set a video mode with a desired refresh rate, right?

[Laurent]

Also, I think it's not possible to get a list of supported refresh rates at given resolution or to set a video mode with a desired refresh rate, right?

It could be possible, but It's so rarely used that I don't want to complicate the API with this kind of detail.

My final goal is to make an online racing game and I think it would be useful to shave off these extra 16 ms of lag that the display generates.

Instead of measuring response time, why don't you simulate what you need (inputs for a racing game) and compare with/without the 16 ms lag to see if it actually makes a difference? I don't like to solve problems that don't exist

If SFML could at least retrieve refresh rate of current video mode, I would know when to call window.display to cause the least delay

The simple solution is to use two threads. If your language doesn't allow this easily, it's not my fault

[kolofsson]

Sure thing, Laurent, I don't want to complicate SFML or convince you to do useless work. But would this addition be a big complication:

Code: [Select]

current_mode = sf::VideoMode::GetDesktopMode()
refresh_rate = current_mode.RefreshRate

or

RenderWindow::GetScreenRefreshRate()

 :?:

[Laurent]

would this addition be a big complication

Yes

[kolofsson]

would this addition be a big complication

Yes

Really? If you say so...

I just found how to get it in python and on windows:

Code: [Select]

import win32api

device = win32api.EnumDisplayDevices()
settings = win32api.EnumDisplaySettings(device.DeviceName, 0)
print 'DeviceName:', device.DeviceName
print 'DeviceString:', device.DeviceString
print 'BitsPerPel:', settings.BitsPerPel
print 'DisplayFrequency:', settings.DisplayFrequency
print 'PelsWidth:', settings.PelsWidth
print 'PelsHeight:', settings.PelsHeight

Returns:

Code: [Select]

DeviceName: \\.\DISPLAY1
DeviceString: NVIDIA GeForce GTX 260
BitsPerPel: 32
DisplayFrequency: 60
PelsWidth: 640
PelsHeight: 480

It looks pretty simple to me, but it's only for windows...

[Laurent]

The implementation is very easy on all systems. I just said that I didn't want to complicate the public API of SFML.

You're the first user to request it in 5 years, and only to implement a workaround for the lack of real threads in Python, so you can understand that I don't want to modify the API for that

[SuperV1234]

But my vSync is off. I still don't understand how to solve this

[SuperV1234]

I tried checking for inputs in a separate thread, but the delay is still there with 60 max FPS (and disabled VSync). Can anyone explain how this can be fixed? I'm making a bullet hell game and precision is absolutely required. There are also a lot of entities on screen so FPS will drop below 100.

[Laurent]

Can anyone explain how this can be fixed?

It depends how you manage it. For example, if you get input and move your sprite at 150 Hz, but still refresh your screen at 60 Hz, the user won't notice the difference. It's completely useless in this case.

You should try to explain your problem better. Maybe provide a simplified code that shows the problem, if possible. 60 Hz is a lot, if things feel delayed at such a frequency there's probably something wrong in your game logic.

[SuperV1234]

Can anyone explain how this can be fixed?

It depends how you manage it. For example, if you get input and move your sprite at 150 Hz, but still refresh your screen at 60 Hz, the user won't notice the difference. It's completely useless in this case.

You should try to explain your problem better. Maybe provide a simplified code that shows the problem, if possible. 60 Hz is a lot, if things feel delayed at such a frequency there's probably something wrong in your game logic.

Code: [Select]

public void Run()
        {
            while (Running)
            {
                RenderWindow.Clear(Color.White);

                float frameTime = RenderWindow.GetFrameTime()/16f;
                if (SSSettings.FrametimeStatic) frameTime = SSSettings.FrametimeStaticValue;

                RunInputs();
                Game.Update(frameTime);
                Game.Draw();

                RenderWindow.Display();
            }
        }

This is my main loop. I clear the window, calculate the delta time, get inputs from Keyboard object and update the game logic.

If I set my FPS limit to 60, input is slightly delayed. If I set my FPS limit to 200-250 input feels perfect.

[Laurent]

Where is the thread that manages input?

Code: [Select]

RenderWindow.GetFrameTime()/16f

Any reason for this "16"?

[SuperV1234]

Where is the thread that manages input?

Code: [Select]

RenderWindow.GetFrameTime()/16f

Any reason for this "16"?

This is the unthreaded version, as the threaded version had the same outcome. For the threaded version I just created a new thread that constantly called "RunInputs();" and sent recieved inputs to the Game.

The 16 is just for convenience, I use it for calculations in game logic. At 60 FPS, the framerate divided by 16 is 1. So if I'm running at 30 FPS, the framerate divided by 16 is 2. That means I have to move my objects twice as far.