Yeah. , we can see on the After half that there’s almost no stuttering when on 20 FPS we’d already experience stuttering.
FPS isn’t everything and this is why it’s hard for some people to understand. You can have like 30 FPS by having some really fast 0,5s rendering and another 0,5s blocking event because FPS is an average measurement.
On this case I just said the game would be an unplayable slideshow even at 30 FPS.
Seems that most of these blocking events were either moved to another thread or changed. Fixing this doesn’t mean double FPS but only a slightly higher average while the gameplay effect is considerably better, because there’s less time spend waiting other things to be processed first.
We still have some misconception about where the game’s bottleneck is. It’s not on the graphics processing side. Lua (just like Java) is a little slower (but usually acceptable) than native code performance, on top of that there’s its limitations, the engine design and technology used (which comes from 2012, when the game was being developed).
The delays and lags are mostly within the code ran by the CPU. For example, if we look at the previous Client Optimization posts we can see their charts here:
https://treeofsavior.com/page/news/view.php?n=785
Majority of the game’s lag is probably on the main loop.
By moving things elsewhere and removing the blocking code from the game’s main loop you can have faster rendering, higher FPS and better gameplay since everything there affects each single frame, which is directly related to CPU code, not GPU.
