question about rts movement

anyway i have in my game small ships with rts movement, they are 32x32 pixels and use 30x30 grid.

About 20-30 of them can fly around without almost any decrease in fps whatsoever. I also tested 50 of them which is a lot more than you will actually ever encounter, and fps hardly even changed.

But as i have made bigger ships that also use rts movement, they are 230x150 with 200x200 grid(i tried 300x300 aswell). Fps falls down to 20-30 from the max 60 and thats with only 4 of them moving.

I did however noticed that if they do not avoid themselves the fps is at maximum.

Probably i am doing something wrong or bigger objects dont work well with rts pathfinding.

Now the question is since avoid moving over something ussually means move right into it. Would there be a better way to set up the rts movement when it comes to bigger objects.

Its probably got nothing to do with the movement behavior, but more from the size.

Think about it, you've more than quadrupled the size, so the system has to calculate all those rotations, collisions, etc at an almost exponential rate.

If you must use that size, I would suggest not using path finding, and set collisions to point or have a smaller collision mask.

yeah but isnt it faster to calculate a bigger grid size than a lower one...?

this is written in construct wiki:

Note that the smaller the cell size, the more CPU intensive the pathfinding calculations will be.

If those boss ships aren't animated set their animation speed to zero, that should reduce the number of times the collision mask needs to be recalculated, which will give you a speedup.

Rojo, could you maybe submit another bit of code that either disables that feature or automatically sets whatever if there is only one frame or for paused animations?

I could submit a bug report or feature request but I think it would be on the backlog, whereas you may already know exactly where the issue is.

The following isn't a rant, just making my case for you to take the time:

Even when it doesn't affect caps to the point where people notice. Its cutting down the effeciency of almost every game since most game have single frame backgrounds, platforms, ui elements, etc.

It was a necessary fix, but its created another problem. The little bit of maintenence it seems to require becomes a problem with older caps when people wanna upgrade, or with noobs who don't know about it, or when you're building up a cap and it suddenly manifests itself, as there is no easy way to go through a crowded layout and make sure you got every last one. The alternative to manually set 1 frame animations to 0 speed every time is inconvenient and easy to forget

yeah but isnt it faster to calculate a bigger grid size than a lower one...?

this is written in construct wiki:

Note that the smaller the cell size, the more CPU intensive the pathfinding calculations will be.

Yes, I should have said graphics size. The rendering of all those extra pixels will take its toll.

actually i thought it's graphics aswell after i posted about cpu, but it just seemed a bit strechted, since it's not that big of a sprite. And i went checking out, and did some extensive testing and its the cpu. I even tried in a new cap with large objects and they are lot more cpu consuming than the smaller ones.

And its all mostly just because of the collision type, changing from per pixel to bounding box, made a huge difference, now it's only a small drop in fps, completely unoticable even with 20 big ships moving at the same time.

thought now i have a problem because the ships are not a big box, and i need per pixel collisions for bullets, so i will probably have to have another object attached to it for movement.