If there's too much JS processing on a game tick, the game will stutter.
How much time should JS processing be limited to on a game tick (across all players) to avoid end-users noticing stutter?
Also, what sort of JS processing tasks seem to take the most time?
Game stutter - when does it become apparent?
Game stutter - when does it become apparent?
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
-- https://warzone.atlassian.net/wiki/display/GO
Re: Game stutter - when does it become apparent?
Under ~40ms is usually fine on my machine i think. Not sure how much sound drivers affect that.
Maps | Tower Defense | NullBot AI | More NullBot AI | Scavs | More Scavs | Tilesets | Walkthrough | JSCam
Re: Game stutter - when does it become apparent?
ISTR you did some profiling of your functions in nullbot - what sort of times were you generally getting for, say, processing an event or a function triggered by setTimer()?
Reason: I'm making a library that will spread code execution over game ticks and I'm trying to determine initial thresholds, etc., before getting in to the fine tuning stage.
I can see straight away that my current allowance of 150ms per game tick (for 2 player games, dropping down to 40ms in 10 player games) is somewhat exuberant!
Reason: I'm making a library that will spread code execution over game ticks and I'm trying to determine initial thresholds, etc., before getting in to the fine tuning stage.
I can see straight away that my current allowance of 150ms per game tick (for 2 player games, dropping down to 40ms in 10 player games) is somewhat exuberant!
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
-- https://warzone.atlassian.net/wiki/display/GO