nesdev.org

Well, I had just recently moved my metasprite building routine to where it ran after all the objects had been gone through and it got me thinking... Would it be good to run through collisions for everything after all the objects have been gone through, like the metasprite routine? You could have every object have a register set aside for it that would be a flag for if it was hit during the collision code.

For performance reasons, I only iterate over the list of objects once. Even drawing the metasprites is something I do during this single sweep.

I used to think that since objects can influence the positions and states of other objects, that I would only be able to draw a consistent state after all of them had been processed. But I ended up going with something simpler: I draw the objects using information from the previous frame, which is known to be stable, and only then I run the rest of the object code.

I didn't get very far with collision detection, but I'd surely look for an apropriate time during the one time slice I give each object, even if that results in small errors. For example, testing for a collision between an object that has already moved and another that hasn't might produce different results than if both objects had moved already... but I think that's a small price to pay for the performance boost that is not having to sweep the list of objects twice (or 3 times).

If you aren't sweeping over the list of objects multiple times, you're preserving registers and jumping a bunch though. I like doing it all after because you don't have to write jumps and stuff for all the objects, and performance seems to be about the same. (It actually seemed like I got a slight boost, but I did some other stuff so I don't know if that was what actually helped.)

Our experiences may differ, considering I work with the NES and you with the SNES, but to me it just makes sense to do everything related to a particular object when I'm already working in the context of that object, rather than leaving that context only to restore it at a later time.

I just figure a simple lda, beq for checking each object slot is a quicker than jrs, phx, phy, plx, ply, rts.

My design uses three loops.

The first loop updates the player and the player's projectiles

The second loops through the enemies and:

• Updates its position
• Checks for collisions between then enemy and the player.
• Checks for collisions between then enemy and the player projectiles.

The third (display) loop displays the player, projectiles and enemies using my MetaSprite routines.


The main reason I'm using three loops is because:

1. By separating the enemies and the player projectiles, I decrease the number of collisions needed from O(n²) to O(n*m).
   This has the disadvantage of having potentially overlapping enemies, but this is what I think Zelda aLttP does, so I don't think it will be a problem.
2. The game design calls for times when the Entity's need to be displayed but not processed.
   The Game Over animation, acquire item animation and the (future) options menu spring to mind.

UnDisbeliever wrote:My design uses three loops.

The first loop updates the player and the player's projectiles

The second loops through the enemies and:

• Updates its position
• Checks for collisions between then enemy and the player.
• Checks for collisions between then enemy and the player projectiles.

The third (display) loop displays the player, projectiles and enemies using my MetaSprite routines.

Even though I loop through my objects only once, my design is somewhat similar to this. I cheat with the player object, updating it before all other objects, but not drawing it. Then in the actual loop, that randomizes the order in which objects are processed (for sprite cycling), all objects are drawn (using the previous frame's stable state) and then processed, and the player also gets drawn during this time (so it takes part in the sprite cycling).

I know this is not the ideal setup, but on the NES I kinda feel the need to take a few shortcuts in order to optimize CPU usage. On the SNES I think you can take the time to sweep through the list of objects more times.

I do collision in the AI routine. The only reason why I do metasprites seperately, is because the "plasma grinch" requires sprite priorities.

Is there anyway of doing sprite priorities and flickering at the same time?

psycopathicteen wrote:Is there anyway of doing sprite priorities and flickering at the same time?

I process objects in random order, so that sprite priorities are cycled every frame, and I created 2 virtual sprite layers by allowing objects to select which end of the OAM they'll be rendered to (the OAM is filled from both ends towards the center). I try to keep the number of high priority sprites down, otherwise the low priority ones will flicker too much or even disappear. Sprites of the same object are always rendered in the same order, so I have full control of priorities there.

I handle both priority and flicker in the following way:

I have an array of 16 objects.

I always draw object 0 first, this lets me give a single object priority.

After this, I increment the index by some relatively prime number (e.g. 1, 5, 7, 11) that changes for each frame. This allows me to iterate through all the objects in a different order each frame, creating flicker when there is overlap. X = (X + prime) & 15

Aside from the object, there are some special things outside the object system that are drawn first or last for priority needs. If I ever needed more than one prioritized object, I might create a special solution for that, but so far hasn't come up in my game.

On the SNES, you really don't even need to worry about sprite flicker, so I have no plans of implementing something like that. The sprite pixel per scan line limit is a major pain, but you can't really do anything about it.

Flicker has other purposes besides the sprite limits. It can prevent overlapping objects from hiding each other, which can be very important to gameplay. E.g. imagine a bullet suddenly pops out from behind a spaceship.

I probably wouldn't be doing it all the time though, and I could probably just get by coding it into the specific object.

tokumaru wrote:I cheat with the player object, updating it before all other objects, but not drawing it.

Why do you update the player object first? (Because its position is needed for the enemy-player collisions?)

Perhaps because the camera follows the player.