As I see it, the main reason to update objects in a specific order is to have them interact with each other properly. Objects that can affect the position of others, for example, should be updated first, so their final position is known when the objects affected by those are updated.
As an optimization, it may be desirable to draw the objects as soon as they're finished updating, specially if there's a significant overhead in the process of calling each object, which might require bankswitching, jump tables, and so on. The problem with this approach is that sprites are always output in the same order.
I guess that one of the most basic forms of sprite cycling still works in this case, which is starting from a random OAM position and advancing a prime number of positions each time. The main problems with this approach are:
- no priority control within the same object;
- no priority control between different objects;
- no way to reserve sprite 0 for raster effects;
- poor handling of the case when more than 64 sprites are needed (the last objects to be processed will get dropped every time);
Can anyone think of better sprite cycling techniques that will handle at least part of those problems better than this basic technique? To me, personally, the most important things are priority control within the same object and decent handling of more than 64 sprites, but I'd love to hear other people's thoughts on this.
As an optimization, it may be desirable to draw the objects as soon as they're finished updating, specially if there's a significant overhead in the process of calling each object, which might require bankswitching, jump tables, and so on. The problem with this approach is that sprites are always output in the same order.
I guess that one of the most basic forms of sprite cycling still works in this case, which is starting from a random OAM position and advancing a prime number of positions each time. The main problems with this approach are:
- no priority control within the same object;
- no priority control between different objects;
- no way to reserve sprite 0 for raster effects;
- poor handling of the case when more than 64 sprites are needed (the last objects to be processed will get dropped every time);
Can anyone think of better sprite cycling techniques that will handle at least part of those problems better than this basic technique? To me, personally, the most important things are priority control within the same object and decent handling of more than 64 sprites, but I'd love to hear other people's thoughts on this.