The performance of the calculations to determine the optimal name position is still pretty bad even after a few rewrites, taking about 30% of a ticks time
Link: PlayerNameRenderingManager
Current behaviour
Whenever a tile is conquered it has to be removed from the possible name area for the player who lost the tile and added to the the player who conquered the tile.
This is done by keeping track of the maximum square starting at a tile going north/west. In the best case, tile updates don't affect the name position, making adding them into this datastructure very cheap (most tiles only require a few neighbor updates).
In the worst case (the player expanding north/west), most of the territory needs to be updated (potentially millions of tiles).
A small example (Before adding the tile 0 and after)
0111 1111
1122 1222
1223 1233
1233 1234
Target behaviour
should remain sequentially (modifying position as tiles are conquered instead of a calculation every tick)
a lot better worst-case, meaning at most a few layers of the territory require updatin
Possible solution
negative values could be used when extending north/west
this might require shifting the marker value 0 ("do not use for border") to -2^15
the actual size of an area would need to determined by searching the diagonal for the highest and lowest value
The performance of the calculations to determine the optimal name position is still pretty bad even after a few rewrites, taking about 30% of a ticks time Link: PlayerNameRenderingManager
Current behaviour
Whenever a tile is conquered it has to be removed from the possible name area for the player who lost the tile and added to the the player who conquered the tile. This is done by keeping track of the maximum square starting at a tile going north/west. In the best case, tile updates don't affect the name position, making adding them into this datastructure very cheap (most tiles only require a few neighbor updates). In the worst case (the player expanding north/west), most of the territory needs to be updated (potentially millions of tiles).
A small example (Before adding the tile 0 and after)
Target behaviour
Possible solution