What is the quickest way to find a sprite inside a container and work on it?

[caymanbruce]

In my game I have a lot of foods spread on the map and when my player moves around it should be able to see some of the foods and can't see the others. But every time I update my player's position I have to look for the index of the sprites representing foods around my player based on food id. I am using findIndex at the moment. It returns the index of the sprite of the food I need to add or delete and use 

 container.children[index]

 to get the sprite. but this could be very expensive if I have thousands of foods. Is there any smarter way to do this?

[ivan.popelyshev]

The easiest optimization here is that you can add buckets! Multiple containers, each has foods in certain range, y1 <= Y <= y2. People often use square chunks, but buckets are much easier to code.

Also you can set "renderable=false" for buckets which aren't in your Y range, its simple culling. If its not enough, inside them you can manage "renderable" of single instance of food.

[caymanbruce]

2 hours ago, ivan.popelyshev said:

The easiest optimization here is that you can add buckets! Multiple containers, each has foods in certain range, y1 <= Y <= y2. People often use square chunks, but buckets are much easier to code.

Also you can set "renderable=false" for buckets which aren't in your Y range, its simple culling. If its not enough, inside them you can manage "renderable" of single instance of food.

Do you mean hash grid spatial partitioning? Or simpler than that? Actually what I do is using spatial partitioning on the server and get the current available foods of the player's interested area. But on the client after I get the foods info I still need to use findIndex on every one of them. If I have 300 foods in the interested area in previous frame/update and I have 60 new foods added and 60 foods disappear in the interested area in current frame/update. The number of time I need to check is 36000 in the update, in this process I may need to create new sprites and add them to the container or set "renderable=false". If pixi.js can handle much bigger than that number I think I may just leave it as it is now. But if this is still too heavy I might need to do bucket partitioning on the client too. 

[ivan.popelyshev]

@caymanbruce Default implementation of Container works with array, indexOf, and all there are no optimizations there. Pixi cannot magically accelerate this, because otherwise we would have to add data structures (which is monstrous in JS) in a open-source library. Adobe Flash DisplayObjectContainer also works like this.

I'm trying to do something about it in my own fork of pixi, but so far I dont have any general solution that can be recommended to everyone.

The way is to either use buckets, either chunks or may be even simpler: every frame pass through all children and remove/add all elements you need through one pass, not using "removeItems", "indexOf", "addChildAt" e.t.c., just perform basic array operations yourself . That way it will cost you O(N) each time and not O(N^2) in worst case, you wont get lags from it. 

SUMMARY: you can speed up it yourself if it'll be a bottleneck. Basic college computer science course is enough. PIXI doesn't have any special magic in this field.

UPD. I have to deal with 10k elements in container, and all the operations are lazy, including updateTransform, but its not easy to achieve.