OR  Zero-K Name:    Password:   

Catching Up Speed

10 posts, 260 views
Post comment
Filter:    Player:  
What determines the rate at which a game "catches up" when rejoining an in-progress game?

I've noticed that larger, longer, and more unit dense games catch up slower. Additionally, after upgrading computers, catching up is generally faster.

While catching up in a recent game, I opened resource monitor to see what was being used. To my surprise, both CPU and GPU were well under 100%, both being in the 30-40% range. Additionally, there was ~7GB of free RAM at all times. This results that the "catch up" rate was not limited by CPU, GPU, or RAM.

What other factors might affect the "catch up" rate, or is there just a hard cap on how fast it can go?
+0 / -0

16 days ago
On further inspection, I noticed that 1 CPU core was maxing out at 100%, while the other 5 were much lower (10-15% range). Perhaps this is the bottleneck?
+0 / -0
Yeah, that sounds like a likely culprit. RTS games have apparently not had a lot of success when it comes to multithreading.
(And by that I mean I don't know if any game has successfully implemented that.)
+0 / -0
16 days ago
I suppose I might as well throw in an extra question: will avoiding graphic input lead to a faster catch-up? When catching up I usually zoom into a tiny corner of the map in the hopes of that it will make it go faster.
+1 / -0

16 days ago
What I know always helps when catching up long games is /luaui disable and do /luaui enable when finished.
The only problem is that even the catching up bar disappears... so good luck finding out when it finished.
+0 / -0

15 days ago
Catching up is limited by the speed at which you can simulate the game. I recently looked at some replays in Starcraft 2 and noticed that it essentially does the same type of catchup for replay seeking - with two big differences:
  • It is easier to simulate Starcraft, there is simply less going on.
  • The world is not drawn when seeking a position in the replay.

Disabling all the drawing in spring and in lua during catch up would make it a lot faster. This could be a nice PR for the engine. It would have to be an option because sometimes it is nice to get a quick overview of a game when you rejoin it as a spectator.
+9 / -0

15 days ago
There is a compromise that could be made. Instead of killing graphics output, maybe a better way is to zoom all the way out to icon range, and disable draw for everything except the unit icons. This would not tax the CPU all too-too much, but would allow rejoining person to get an idea of what's happening.
+1 / -0
+4 / -0
core 5 is why you use non conductive thermal paste.. he is defiantly not able to lift that kind of weight and core 8 is getting a bit burnt out too
+0 / -0
14 days ago
when it comes to multithreading

your machine is a complicated system and operate at speed of its slowest element;
But if we oversimplify things there is a bottleneck which is RAM speed - CPU operates on its own pace, it need memory access to at least fetch instructions (also read and eventually write data); yes it requires multiple cycles to complete one instruction, but it typically does multiple ones in parallel if possible; and with multiple CPU cores at work (operating in their own memory regions actually) RAM can be simply too slow. If you want for example make animated loading screen in a game (smooth and independent of % loaded) then you can do this with multithreading without even thinking about it, but it another story when it comes to solve memory heavy task like simulating game of ZK.
Or at least i think this can be one reason why multithreading not so successfully implemented in games in general.
+0 / -0