Quick experiment with shorter turn lengths

[wraitii]

0 A.D. currently updates the simulation state every 200ms. This update usually takes 20-40ms, depending on the number of units doing things. This means even if you're running at 60 FPS graphically, when the sim is running, you'll get worse FPS, and worst you might get a lot of 'micro-freezes'.

Furthermore, the 200 ms turn length gives high input lag which would be nice to shorten.

I ran some quick experiments on Combat Demo Huge to see what changing the turn length would do to performance, and the results are somewhat more promising than I expected.

First, what to expect:

• We should run fewer JS timers each simulation turn, as they will tend to hit on different frames. This should 'smooth' the framerate.
• Movement might be a little easier and smoother since we're going less far away (in practice, I'd need to update Pushing, it's too smooth)
• Things like 'range queries' shouldn't change too much, as we still run all of them every turn.
• Overall the FPS should be lower, as we compute more things, but also smoother, as we don't stop as long.
  • Frames would go "16-16-30-16-16-30ms..." instead of "16-16-16-16-80-16-16-16-16-80ms..."

The results are quite interesting. The 'smoothing' effect is rather convincing.

I think if we adapted to not run all Range queries on all turns, and perhaps tweaked movement appropriately, it might be worth looking into running turns every 100ms for example.

In the profiling runs below, Red is 350ms turns, green is 200ms (normal), dark-blue is 100ms and cyan is 50ms turns. Remember that the red curve is farther ahead in time at any given time.

[causative]

Range queries can be heavily optimized.

• Do the target filtering in C++ not in JS.
• Use a quadtree instead of a fixed grid so that you can more quickly find the closest unit without having to iterate over all the units in a grid cell.
• Don't generate the entire list of units in range and then filter afterwards. Instead, filter as you iterate over the units, and return as soon as you have a matching one.

 

My own computer is too slow with the current turn lengths. A large battle becomes almost unplayable as it drops to 2 FPS and the camera stops scrolling properly.

Edited June 2, 2023 by causative

[real_tabasco_sauce]

I think most players (if they have to choose) would choose better performance into the late game than slightly less input delay at the start.Now I admit that is a bit of a false dichotomy, so if you think it will work out to increase turn rate after all those awesome optimizations you have been working on, then I would be happy to test it out.

[hyperion]

100ms isn't humanly noticeable anymore I'd wager, so is there a need for 50ms? As for networked games, where the issue is most prominent wrt input lag, we aren't bound by turn length but RTT.

Looking at your graphs, given your fast machine sim update is always well within turn length, so no issue. But the gain isn't proportional to the reduction in turn length, so on slow machines sim update might no longer fit into shorter turns lengths when it did before which would lead to variable turn lengths much easier I'd guess which probably isn't that nice. Maybe your proposed tweaks can make up for it.

[phosit]

Shorter turns will yield a smoother game play and less latency but add more "overhead": even if the range-queries are fixed there will be some constant factors.

Regarding smoothnes: IMO the biggest problem is that when the AI does recalculate their diplomacy, frames sometime take multiple seconds. If you reduce turn length this will be much more noticable. The AI in general does lead to long turns. Anolog to what you propose the AI could be run more frequent. I don't know if there are constant factors in the AI code.

Regarding latency: I don't think of 0ad as a fast paced game so I don't value latency that high. If we still care there are better solutions: make the "turn count untill the input take effect" dynamic in MP games.

I'm more in favor of split rendering from simulation. That would make the game a lot smoother by increasing latency (since the simulation or the draw commands have to be buffered somewhere).

[hyperion]

3 minutes ago, phosit said:

Regarding latency: I don't think of 0ad as a fast paced game so I don't value latency that high. If we still care there are better solutions: make the "turn count untill the input take effect" dynamic in MP games.

Dynamic input delay probably feels much worse than static somewhat lengthy one. At least for competitive play this seems a no go.

 

5 minutes ago, phosit said:

I'm more in favor of split rendering from simulation. That would make the game a lot smoother by increasing latency (since the simulation or the draw commands have to be buffered somewhere).

That's a good idea anyway, nothing to do with turn lengths.

[phosit]

Do you have a clue why there are the two spikes in `OnUpdate`?

[wraitii]

8 hours ago, phosit said:

Do you have a clue why there are the two spikes in `OnUpdate`?

Most likely these are turns during which a unit dies and all other units go in 'FindingNewTargets' mode, or some other event like that.