Spring RTS Engine

I just noticed a strange thing while having about 1500 fighters patrolling my base. While they were on patrol command the game lagged horribly, it was roughly 5 fps. but once i canceled the patrol and set on queued move or attack the fps jumped back to 50 fps. The question arises, is something wrong with the patrol command? Maybe it could be redone to improve performance.

Pathfinding uses a lot of resources, we've known that a while. What mod were you playing? Some mods make aircraft able to fly through each other, reducing the performance penalty significantly.

Also, why the hell are you here complaining about a scenario that will never come up in a game? 1500 fighters? No developer would be stupid enough to make that necessary under normal gameplay. Play a real game and you'll not have things like this to complain about. It's like complaining that iTunes would fill your hard drive if you were to download every song ever made.

/me goes and plays a 64-player game... wait, might these 1500 fighters have a valid reason for existing?

also, the point of his post: patrol seems to have performance issues.

Caydr wrote:Pathfinding uses a lot of resources, we've known that a while.

airplanes don't pathfind

they shouldn't

los calculations

1500 airplanes, all moving, all recalculating los constantly

On patrol they look for targets to chase. On move they don't.

Would there be a big difference in their behavior or performance if they were just stuck on repeat on move or repeat on fight?

On move they don't look for targets, fight shouldn't make a difference from patrol.

units don't look for targets when they automatically attack things in range while moving?

I meant pathing and LoS... I'm used to spouting this off to people that /give 5000 armflash and suddenly their game slows down even though the units are low-detail.

In any event it'll never get seen in a real game. There are all kinds of hypothetical situations that might cause problems but that doesn't mean devs need to start wasting their time on eliminating them.

I guess the performance hit could be reduced a lot by implementing some kind of caching of nearby enemies, but there is a risk it will make the fighters react more slowly to incoming bombers. Anyway, I will look into it.

KDR_11k wrote:On patrol they look for targets to chase. On move they don't.

This. (Confirmed in my own test, patrol of 1500 BA armhawks reduces FPS by 50% compared to repeat-move with roam.)


On fight/patrol, CGameHelper::GetClosestEnemyUnit is called for each unit every SlowUpdate (every 16 frames).

GetClosestEnemyUnit iterates through all units in all quads within maximum range of the units weapons.

If the common case is that less enemies are nearby then friendlies (I bet it is), it may be advantageous to iterate over CQuadField::Quad::teamUnits for all enemy teams instead of CQuadField::Quad::units.

zerver wrote:Anyway, I will look into it.

Will leave it to you to confirm it is this and implement the change then

EDIT: I don't think caching will really be feasible, at least not without making the algorithm an approximation only. (ie. GetNearbyEnemyUnit)

zerver wrote:I guess the performance hit could be reduced a lot by implementing some kind of caching of nearby enemies, but there is a risk it will make the fighters react more slowly to incoming bombers. Anyway, I will look into it.

Or maybe the engine can detect when a certain number of planes are on a patrol path, and then stop calculating LOS for each plane and instead give permanent LOS for the patrol area.

HectorMeyer wrote:

zerver wrote:I guess the performance hit could be reduced a lot by implementing some kind of caching of nearby enemies, but there is a risk it will make the fighters react more slowly to incoming bombers. Anyway, I will look into it.

Or maybe the engine can detect when a certain number of planes are on a patrol path, and then stop calculating LOS for each plane and instead give permanent LOS for the patrol area.

Some optimization is needed, but this seems like a bad idea. The degenerate case of 1-2 fighters patrolling a large area in front of your base, for example.

LOS might need to be optimized...

HectorMeyer wrote:

zerver wrote:I guess the performance hit could be reduced a lot by implementing some kind of caching of nearby enemies, but there is a risk it will make the fighters react more slowly to incoming bombers. Anyway, I will look into it.

Or maybe the engine can detect when a certain number of planes are on a patrol path, and then stop calculating LOS for each plane and instead give permanent LOS for the patrol area.

[ ] you have read the thread
[X] you just give unhelpfull advice

So how does acquiring targets in move+fireatwill mode work?

I know Tobi and zerver were talking about something different. The LOS thing was just an idea.

lurker wrote:So how does acquiring targets in move+fireatwill mode work?

It doesn't chase units as in patrol in this case.

Just the weapon's SlowUpdate checks for enemies, and this uses CGameHelper::GenerateTargets, which apparently uses exactly the speedup I suggested for CGameHelper::GetClosestEnemyUnit. I don't know why the code isn't reused between those two, haven't investigated much tho.

Only if the unit is idle (no orders in queue) it also seems to call CGameHelper::GetClosestEnemyUnit, but I guess the slowdown caused by this isn't really noticeable because other slowdowns from moving aren't present (like LOS) and/or because when e.g. planes are idle they often land, and when landed they all do take a free spot of ground. In other words, when idle there are possibly less other units nearby then when patrolling in a single blob of 1500 planes.

how does having the units on "roam" affect it?