Fixed a couple of bugs today, as usual. Did some GUI tweaks. And also implemented stacked CPU profiler. This is a nice way of seeing where CPU time gets spent.
Profiling 8-players skirmish mission. Most of the CPU time is spent on updating units .. Not a big deal yet, whole update takes ~6,5msec (out of available 100). Still it would be nice to optimize later on, so that on x10 speed it did not take 65msec (leaving too few for render and such)
P.S. Alpha 8 will feature new skirmish mission for 8 players!
Great to see so much progress the past few weeks!
Just a question I have about the updating times: If there’s 100 ms available per frame, does that mean the game runs at only 10fps? Or do you solve this by multi-threading
Game logic runs at 10 fps (when at x1 speed). Game is rendered at whatever fps it can, by interpolating between game states. That is how most of RTS games do it.
How is this different from rendering at 10 fps? – smooth animations and camera controls.
Ah, thank you. That is pretty smart, learned something new
Apologies if my questions are too obvious, but I have no experience in game development.
If game logic update happens every 100 ms and rendering is interpolated, then it would be possible for the user to see a 100 ms delay in his actions, right?
t[ms]: 0———-100———-200———-300———>
I imagine that user input from 100-200 gets calculated and the result of his input is applied to the state at 200. But to interpolate and render anything after 100, we already need to know the state at 200. So the rendering of time 100-200 can only start after 200. As a result, pessimistically, there is a possibility to experience a 100 ms delay in your action. Is that correct?
Hi, good question!
First of all we need to separate game flow from user input.
Rendering interpolates between game’s states more than every 100ms for all visible game’s entities.
User input OTOH, happens roughly once a second. Out of those, only a fraction directly affects the game (due to indirect nature of the game).
So, said delay affects only a minor (though very important) fraction of what’s happening in game.
Also, again due to game’s nature, it is quite tolerant to such delays. Unlike FPS genre, in RTS we expect for units to receive order, process it, and only then execute it.
Delays up to 500ms are not a big deal, especially if player gets an instant order feedback (e.g. troops say “Let’s go!”), this only feeld more natural if they start walking with a short delay.
I thought about this a lot, and at the moment, the game does extrapolation (cos I wanted to avoid this delay). But this proved to be a bad idea, since extrapolation, by it’s nature, can not foresee changes in processes. Units will jitter when they encounter unexpected obstacles (this happens a lot in town traffic). Extrapolation logic is also much more complicated due to desire to foresee unforeseen.
OTOH there’s still a room for delays – For example, user gave an order at 1ms. it’s postponed till 100ms, when it is taken into execution – already a 99ms delay, no matter what we do.
I guess, best solution for now would be to change back to interpolation and up game’s update rate to 50ms.