Issue with Camera and FPS

[ShiningLea]

I've just finished the chapter for the Camera, and I'm running into 2 major issues.

The first one is that if I unlock my FPS (so I don't use V-Sync and I don't limit my FPS at all), the camera movement with the mouse (and with the mouse only) is very unresponsive (like, 99% of the time it doesn't register any input from the mouse), however, it's perfectly fine when using the keyboard.

And the second one is about the FPS. Essentially, the game renders 30 frames (TARGET_UPS), and the problem is that I have a 144 hz monitor so it doesn't feel smooth at all. However, if I increase that to 144, the speed of the game is increased significantly.

At the end, I would simply like to have enough frames to be rendered to feel smooth, yet having unlocked FPS and having smooth camera movement. I hope I was clear enough!

[ahbejarano]

Hi,

Let's tackel your issues:

• First one: I see your problem, basically is thay the mouse displacement is consumed in each render loop, so at the end your are procesing small displacements in the update method which is called many less times. Quick solution, in the GameEngine class, call the input method prior to the update one:

            while (accumulator >= interval) {
                input();

                update(interval);
                accumulator -= interval;
            }

By the way, in order to uncap completely the rendering, a call to glfwSwapInterval(0); in the Window class is needed (I think this was not required in previous versions of GLFW).

• Second problem: You should use the interval parameter in the update method to be independent of the FPS (render should be done according to TARGET_FPS and update to TARGET_UPS).

I'm in the process of refactoring the book, so I will not release a fix for this. However, let me ask you a question.

I was thinking in just using vsync to limit rendering to the refresh rate supported by the monitor in order to simplify the code. Do you think it is worth to add support for custom FPS or even uncapped mode?

[ShiningLea]

Second problem: You should use the interval parameter in the update method to be independent of the FPS (render should be done according to TARGET_FPS and update to TARGET_UPS).

I'm aware I should use that parameter, but even when I use the custom sync() method (or even V-Sync), it just feels like it's rendered at 30 FPS (if TARGET_UPS is 30). It does not happen when that field is set to 144, but then as said before, the speed of the game is altered.

By the way, in order to uncap completely the rendering, a call to glfwSwapInterval(0); in the Window class is needed (I think this was not required in previous versions of GLFW).

Yup, I did exactly this to uncap my FPS.

I was thinking in just using vsync to limit rendering to the refresh rate supported by the monitor in order to simplify the code. Do you think it is worth to add support for custom FPS or even uncapped mode?

Well, in my opinion, the user should have a choice between unlimited FPS and V-Sync. And since Minecraft can do it, why wouldn't our game be able to? And as far as I'm aware, Minecraft's game loop is pretty simple (in fact, I think the one used in the guide is similar to it if not the same).

[ahbejarano]

Regarding FPS, it seems strange. I've tested (disabling vsync) and seems to try to match TARGET_FPS.

In any case, let me ask you another question. Choosing between vsync and uncapped FPS is simple, but do you think that adding suppor for a target FPS (different than the one that you should get by vsync) addes value? This complicates a little bit the code, having to include specific code to control the timing.

[ShiningLea]

Regarding FPS, it seems strange. I've tested (disabling vsync) and seems to try to match TARGET_FPS.

I mean, even with V-Sync it renders 144 FPS, and in unlimited FPS it renders like 12-13k FPS, but that's not the problem. Like, interacting with the environment just feels like it's being rendered at TARGET_UPS rather than 144 or even TARGET_FPS.

In any case, let me ask you another question. Choosing between vsync and uncapped FPS is simple, but do you think that adding suppor for a target FPS (different than the one that you should get by vsync) addes value? This complicates a little bit the code, having to include specific code to control the timing.

I don't see that being a problem. The game loop is something that the user will simply write once, and probably never touch again. So in my opinion it's probably a good thing to include both, at the cost of complexity.

[ahbejarano]

I think I get your point, this is because the update method is in fact called with afrequency equal to TARGET_UPS. If you want to process input at a higher rate you need to split input processing and other game update logic.

I will try to provide a more complete example in the new version. Thanks for your comments.

[ahbejarano]

Closing this, since this should be covered in new version.