I just want to know before we get there, sorry. But will looping over every low entity every 60 frames or so not create any hickups in the framerate? Can we just ignore these or will we guard against them and maybe separate them into 'chunks' so first 1000 then next 1000 in next 60 frame cycle.

Or should I just wait until this comes up?

I thought the plan is to optimize for worst case per frame so probably we will be processing 1/60 of entities per frame (60 chunks)

Sorry I don't follow. How is it 60 chunks. You can't possibly know how much time the 9 High TilesChunks (Screens) take wich could all be in 1 chunk, so we will definatly not be processing the entities of 60 chunks right?

Am I missing something, oh the anticipation...

The idea is that there is always a relatively low number of entities in the high simulation set - like, less than 500, less than 1000, something like this. Those are always processed. Then, however many low entities there are (a million, ten million, we don't care), we will simply process n of them a frame where n is however many we can afford to process. Say that is 10000. Then each frame we process 10000 low entities, which means each low entity gets updated once every n/1000 frames, which for 1000000 low entities would be once every 1000 frames, about once every 30 seconds.

Ideally we will be able to "process" a rather large number of low entities per frame, because a lot of them will not have anything to do (they are things like trees, which just sit there most of the time).

- Casey

So we would be using the available left over time per frame for this then, thanks for clarifying.

Would another option be a low prio other thead for low entity updates? Or would that over complicate things on the low entities on the edge of the high zone? And what about the impact on the framerate with 2 separate threads?

We might actually quad-thread the code now that I know the Raspberry Pi will have at least four cores when we go to port to it. How exactly we divide up the work will depend more on what the workload ends up being in practice once we measure it.

- Casey