Input feels delayed at 60FPS

[kolofsson]

Code: [Select]

if (SSSettings.FrametimeStatic) frameTime = SSSettings.FrametimeStaticValue;
Game.Update(frameTime);

What is SSSettings? What does Game.Update do with the frameTime?

Where exactly do you set the framerate limit for the window in case of static framerate?

[SuperV1234]

Code: [Select]

if (SSSettings.FrametimeStatic) frameTime = SSSettings.FrametimeStaticValue;
Game.Update(frameTime);

What is SSSettings? What does Game.Update do with the frameTime?

Where exactly do you set the framerate limit for the window in case of static framerate?

SSSettings is a static class holding some, well, settings for my library.
FrametimeStatic equals false in the example.

Frametime is a float variable that equals:
1 when having 60 FPS
2 when having 30 FPS
0.5 when having 120 FPS
... and so on

When I move my entities, I move them like this:
entity.Position += new Vector2i(100 * frametime, 100 * frametime)

So I ensure that the result is the same with any framerate.

[SuperV1234]

Where exactly do you set the framerate limit for the window in case of static framerate?

I'm just doing this currently:

Code: [Select]

RenderWindow.EnableVerticalSync(false);
RenderWindow.SetFramerateLimit((uint) SSSettings.FramerateLimit);


with SSSettings.FramerateLimit being 60.

[kolofsson]

Where exactly do you set the framerate limit for the window in case of static framerate?

I'm just doing this currently:

Code: [Select]

RenderWindow.EnableVerticalSync(false);
RenderWindow.SetFramerateLimit((uint) SSSettings.FramerateLimit);


with SSSettings.FramerateLimit being 60.

Somebody prove me wrong, but I think you should use either EnableVerticalSync or SetFramerateLimit. If you enable Vsync, there is no need to limit the framerate as it is limited.

[SuperV1234]

Where exactly do you set the framerate limit for the window in case of static framerate?

I'm just doing this currently:

Code: [Select]

RenderWindow.EnableVerticalSync(false);
RenderWindow.SetFramerateLimit((uint) SSSettings.FramerateLimit);


with SSSettings.FramerateLimit being 60.

Somebody prove me wrong, but I think you should use either EnableVerticalSync or SetFramerateLimit. If you enable Vsync, there is no need to limit the framerate as it is limited.

Input delay occurs in both the cases.

But I've played games (like Touhou) that are limited at 60FPS with VSync forced off, and they don't have any input delay.

[kolofsson]

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...

Just to make it clear, I managed to create a thread in Python, but I was having trouble to understand how to use sf::Window::SetActive (bool). I read the docs which state:

A window is active only on the current thread, if you want to make it active on another thread you have to deactivate it on the previous thread first if it was active. Only one window can be active on a thread at a time, thus the window previously active (if any) automatically gets deactivated.

Could you explain how to use the SetActive method? Is there a sample code somewhere that I could refer to (even in C++)? If I check the window input in the main loop and display the window in a thread, when should I call the setactive(false) and when the setactive(true). I mean, since the thread and the main loop run alternately, how to tell which thread should be the active one?

Also, I had to set the Window as global to be able to use it in the thread. Can the window object be passed somehow to the thread so that it's shared between the main loop and the thread? Again, can I find a code snippet in C++ somewhere that would demonstrate how sf:window and sf:thread can work together?

Thanks in advance for your help!

[Laurent]

Just to make it clear, I managed to create a thread in Python

That will probably be worse, because there's no true threading in Python. But anyway, you'll see the result by yourself, and it will be an excellent use case for Bastien, if I remember correctly he was waiting for feedback before possibly improving multithreaded performances of the Python binding
But keep this in mind, the result might be worse.

Could you explain how to use the SetActive method?

SetActive is only about drawing. A window needs to be active when you want to draw stuff. So:
- you must call SetActive(false) before launching the rendering thread
- that's all, SetActive(true) is called automatically by Clear/Draw/Display

[kolofsson]

Just to make it clear, I managed to create a thread in Python

That will probably be worse, because there's no true threading in Python. But anyway, you'll see the result by yourself, and it will be an excellent use case for Bastien, if I remember correctly he was waiting for feedback before possibly improving multithreaded performances of the Python binding
But keep this in mind, the result might be worse.

Well, before I set the setactive to false, the other thread would never get executed. As a result I had my display window white and frozen. Then I set the setactive to false, it draws the first frame and then stops drawing.

In C++, how can you make a thread which uses RenderWindow that is not declared as a global?

[Laurent]

Sorry, I don't understand the meaning of your last message. Do you mean that using SetActive correctly still doesn't make things work? If so, you should rather show your code.

[Razzeeyy]

Sadly, I have the same problem.
It's noticeable when I'm trying to make 'game' simulate the shots.
And if I make a shot delay 0, at 1000+ fps I see the natural solid 'line' instead of single shots.
But when I limit my fps to 75 or enable VSync then I get the unnatural half-sized 'bullet image' line.
(i can send sources and binaries to you if you want )

That means the input is pausing while waiting for vsync =( sadly...
And, yes it is not noticeable when you doing a simple quest or something like that, but it becomes noticeable when you trying to make a FPS or simulate things that moving fast and controlled by input.

P.S. I'm using SFML 1.6

[Laurent]

Things have changed in SFML 2, inputs are directly queried at the OS level rather than being a layer on top of events.

[Razzeeyy]

Things have changed in SFML 2, inputs are directly queried at the OS level rather than being a layer on top of events.

so we will never have that delay again?

little offtop:
also why (as I see)  sfml 2 switched from "float second = 1" definition of time, to "int second = 1000". That was made for any performance needs?

[Laurent]

so we will never have that delay again?

I'd say it differently: if you have a delay with SFML 2, it won't be SFML's fault.

also why (as I see) sfml 2 switched from "float second = 1" definition of time, to "int second = 1000". That was made for any performance needs?

http://www.sfml-dev.org/forum/viewtopic.php?t=4864

But it will change again soon.