More fps during fast forward

[ceeac]

This patch makes the target fps during fast forward configurable via simuconf.tab - now the fps may be anywhere between 10 and 100. I also increased the target fps from 10 to 25, which results in much smoother movement of vehicles during fast forward.
Furthermore, there was a bug which caused a permanent fps drop when opening the settings window when using a frames_per_second value of >25; this is now fixed.

[prissi]

I think 10 is still a sensible default across the wide variety of devices. Moreover, the rendering will produce more artefacts in fast forward, since a faster code is used. Finally, a fast forward speed with 25 fps may be not very fast on slow computers with large screens (like mobile phones/tablets).

Why did you remove the fps check for the server? I had people trying -fps 1000 on the command line, and then wondering, why the game was freezing.

Did you check fps below 5? It does not make any sense, since this means a mouse movement every 200 ms. I do not see a point making this configurable. Also increasing after dropping to 5 is soo slow.

Finally, I think that code needs a lot of checks to verify. I spent a long time getting the code working on many different computers (especially low end), and it took many iterations. You can somewhat simulate this by increasing the time flow "," and "." keys in some bindings. Then when the simloops drops just close to 5 fps (or whatever you set a minimum), decrease acceleration again and see, if it comes back reasonably fast.

To conclude, the configurable fast forward_fps is a good idea. About the rest, well, it may be ok, but it will need further testing.

[Mariculous]

I had people trying -fps 1000 on the command line, and then wondering, why the game was freezing.

I don't think it's simutrans job to protect serveradmins from themselves tbh.
Anyone using the commandline, especially serveradmins should know what they are doing, otherwise they schouldn't be a serveradmin.
The new ingame "start server" option is a different thing.

In any other point, I totally agree.

[Ters]

I don't think it's simutrans job to protect serveradmins from themselves tbh.
Anyone using the commandline, especially serveradmins should know what they are doing, otherwise they schouldn't be a serveradmin.

In an ideal world.
In the real world, they come here demanding our attention because things broke. (I guess that is why technical support in many cases have become impenetrable barriers. They need to protect their competent staff from all the users trying something like "-fps 1000".)

The main issue is however that higher frame rates makes fast forward less fast. The two compete for the same CPU resources. While computers have gotten more powerful since Simutrans came along, people have been compensating with playing bigger maps. Making it configurable and with a low default means that it doesn't immediately ruin the experience for players with low-performance machines, and Simutrans seems popular with people who don't have high-end machines, but it also means that it is one more axis of freedom to account for when testing changes to the game.

[prissi]

I had a look at this. The configurable part can go in without problems, and the rearrangement of code, I do not care (it was following an old coding rule (from the last century) that premature return is as evil as goto. I wonder what thy would say to todays try and catch everywhere but in simutrans ...)

Printing the error message using env_t:: variable will only get the default values, since the config files are not loaded at this point.

The lowest limit of fps allowed was set to 5, because below that no interaction is possible: Any command would take more than 200 ms.

I am not sure, when the return false branch from reduce_frame_time is ever called. I my experiements it never happens. I suspect it is a remainder from older times, when the window timer were totally unreliable that such big deviations could occur.

So a slightly modified version is now in in r9040, thnak you.

[Ters]

I wonder what thy would say to todays try and catch everywhere

I think that was only popular in the 1990s. Now we're partially stuck with it because a lot of things are made using things from the 1990s.