Currently, the client renders at the same FPS as the FPS it will send movement commands to the server
This means if you want the game to render at 60 FPS (i.e look smooth at all), the server will die horribly as it has to handle all the verbs
ID:1557491
Apr 24 2014, 7:52 am
|
|||||||
| |||||||
The idea of logical frames goes out the window anyways when network lag comes into the picture
|
There's not really a functional difference between handling verbs at a 60 FPS rate and handling them at a lower rate; they're handled as they come in. If verb spammage is really an issue, that can be alleviated partly by redesigning some of them (like movement commands) or by putting in traps in the verbs to bail out if new commands are received too soon.
|
Theres also the scheduler, which seems to freak the hell out at too high FPSes
Theres a reason that most SS13 servers run at 11 FPS, any more and the whole thing likes to fireball under load |
I suspect SS13 is freaking out the scheduler largely because it's spawning a crapload of procs. But it's understandable that would be a concern.
|
All those spawns are extremely difficult to track down however, and lots of them are necessary in places to not accidentally step over the recursion limit in extreme cases, which for some bloody reason counts as a "critical error" and shuts down the entire server after 5 of them
|
It would be a lot nicer if the engine were able to queue verbs up and operate the scheduler using world.tick_lag, and was able to render according to world.fps.
Of course, that would create the issue of not being able to perform visual updates between logical frames.
We'd need some kind of proc/verb setting to differentiate verbs between logical and visual.
20fps:
40fps:
The trouble you end up running into is basically that there's no way to interpolate pixel movement cleanly. The animation either has to look a bit chunky, or you have to delay between movements causing a less-responsive control scheme.