Fix and improve fast-forward (frame skip)

[jwt27]

Turns out I inadvertently broke frameskip (fast-forward) in #4919. Oops. This will fix it again, and even make it better than before: it now increases the game speed linearly, which makes it work properly with interpolation.

[rainlizard]

edit: nevermind, compiled the wrong branch

[jwt27]

Multiplayer is fine as before. But there are various considerations with how the speed feels. For example having interpolation enabled during fast forward might make it run slower than before, it doesn't seem like it's going very fast in multiplayer (if you weren't aware, you can fast forward in multiplayer if both players do it).

I didn't realize that. Huh. Surely that's not an intentional feature?
It can't go very fast since process_turn_time is clamped at 2.0 (1 turn ahead) in multiplayer.

And in the first level of the campaign if you set it to 2x it feels like it's going faster than 2x. Or maybe it isn't, I'm not sure. I don't really care about fast forward that much, so @Loobinex might want to review this.

You can verify the game speed with !ft. Logic FPS should read 40 on 2x, 80 on 4x, etc.

[Loobinex]

Multiplayer is fine as before. But there are various considerations with how the speed feels. For example having interpolation enabled during fast forward might make it run slower than before, it doesn't seem like it's going very fast in multiplayer (if you weren't aware, you can fast forward in multiplayer if both players do it).

I didn't realize that. Huh. Surely that's not an intentional feature? It can't go very fast since process_turn_time is clamped at 2.0 (1 turn ahead) in multiplayer.

And in the first level of the campaign if you set it to 2x it feels like it's going faster than 2x. Or maybe it isn't, I'm not sure. I don't really care about fast forward that much, so @Loobinex might want to review this.

You can verify the game speed with !ft. Logic FPS should read 40 on 2x, 80 on 4x, etc.

In the past, multiplayer frameskip did work fine, to any value. If two turtles fight, they might want to fast forward through training.
Also, since you cannot save during MP, being able to use frameskip to get to an ending quickly might be important there.

[rainlizard]

ok I tested the right branch this time.

Singleplayer fast forward is actually perfect.

Multiplayer stutters are all still good. (I also found out compiling with DEBUG=1 increases them by 4%)

And here's the state of fast forward in multiplayer (using 1920x1080w32 which affects performance):
input_lag_turns=0: on a nearly empty map it goes as fast as singleplayer, as high as 75x speed. But if there's a lot of stuff on the map it'll only go ~10x speed.
input_lag_turns=1: on a nearly empty map it only goes as high at 4x speed.
input_lag_turns=2: on a nearly empty map it only goes as high at 3x speed.
At higher values it goes even slower.

Of course, if you have trouble fixing this I don't personally mind, the smoothness of the micro stutter improvement is worth it.
But Loobinex probably minds so see if there's anything you can do.

[jwt27]

And here's the state of fast forward in multiplayer (using 1920x1080w32 which affects performance): input_lag_turns=0: on a nearly empty map it goes as fast as singleplayer, as high as 75x speed. But if there's a lot of stuff on the map it'll only go ~10x speed. input_lag_turns=1: on a nearly empty map it only goes as high at 4x speed. input_lag_turns=2: on a nearly empty map it only goes as high at 3x speed. At higher values it goes even slower.

Of course, if you have trouble fixing this I don't personally mind, the smoothness of the micro stutter improvement is worth it. But Loobinex probably minds so see if there's anything you can do.

I'm trying this now on alpha 5192 (the one before #4919). With 1v1 on an empty map, I don't think it even reaches 2x (do note: "Logic FPS" is meaningless here). The speed is very inconsistent too. When returning back to normal speed, the client clock is out of sync and it gets stuck drawing ~40 fps. So, all the findings you posted are an improvement already.

Although personally I don't think this "feature" should even exist, at least not in its current state. To make it reliable, there would at least need to be some coordination, and the packet rate needs to remain steady (1 packet per 50ms). So, the whole input stage and packet exchange would need to be skipped.

For now though, this patch just fixes the regression.