I don't know if this is the best place to put this, but I'm looking for examples on how to handle collision, and maybe we can start a broader discussion on different techniques in general as well as the way they can be set up on the NES. I've seen a few threads on this forum discussing collision before but most of them have handled the issue of sprites interacting with static background elements, not many people seem to talk about sprites interacting with sprites.
Of course, when I talk about sprites I'm referring to the object that's represented by a sprite; an entity that is not affixed to the nametable grid. Mario and the Goombas, not the Question Blocks or Pipes.
So... What are some opinions on collision?
I started programming with MUGEN, so I'm used to thinking of collision in terms of red and blue hitboxes, aggressive rectangles that trigger code when they overlap with inert rectangles and the inert rectangles themselves. In most fighting games I've picked at, objects are all handled first, then collision is done afterwards. That is to say, the player's and every enemy's movements/state changes are calculated and applied before any collision is done at all. An object logic loop before the hitbox logic loop. I find this to be an ideal way of doing things, since processing any object's collision before all other objects are handled might lead to a single frame of latency (bullet moves into corner, finds no victim, player moves into corner, finds no wall, end tick. next frame, bullet moves again and finds the player that it should have collided with last frame).
However I can't find a generalized way of doing this without using a ton of memory for each collision box. Every hitbox would need many bytes in ram: x, y, width, height, the ram offset to find the object that created this hitbox, whether its a 'hit' box or a 'hurt' box, and the low/high bytes of the address to run code from when it interacts. Even if you compress width and height into a single byte, you're still looking at about six bytes per hitbox; which is an issue for bullet hells and similar collision-heavy genres. You would need about two pages of ram for hitboxes for a single page of simple objects.
What, when you go about your platformers/beat-em-ups/shmups/grid-movers/thwaites, do you do for collision? How do you stuff it into your RAM?
And have you looked into the collision systems for other games? How does Ninja Gaiden/Mega Man/Gimmick/Battletoads/Other handle their invisible object interaction detection?
Of course, when I talk about sprites I'm referring to the object that's represented by a sprite; an entity that is not affixed to the nametable grid. Mario and the Goombas, not the Question Blocks or Pipes.
So... What are some opinions on collision?
I started programming with MUGEN, so I'm used to thinking of collision in terms of red and blue hitboxes, aggressive rectangles that trigger code when they overlap with inert rectangles and the inert rectangles themselves. In most fighting games I've picked at, objects are all handled first, then collision is done afterwards. That is to say, the player's and every enemy's movements/state changes are calculated and applied before any collision is done at all. An object logic loop before the hitbox logic loop. I find this to be an ideal way of doing things, since processing any object's collision before all other objects are handled might lead to a single frame of latency (bullet moves into corner, finds no victim, player moves into corner, finds no wall, end tick. next frame, bullet moves again and finds the player that it should have collided with last frame).
However I can't find a generalized way of doing this without using a ton of memory for each collision box. Every hitbox would need many bytes in ram: x, y, width, height, the ram offset to find the object that created this hitbox, whether its a 'hit' box or a 'hurt' box, and the low/high bytes of the address to run code from when it interacts. Even if you compress width and height into a single byte, you're still looking at about six bytes per hitbox; which is an issue for bullet hells and similar collision-heavy genres. You would need about two pages of ram for hitboxes for a single page of simple objects.
What, when you go about your platformers/beat-em-ups/shmups/grid-movers/thwaites, do you do for collision? How do you stuff it into your RAM?
And have you looked into the collision systems for other games? How does Ninja Gaiden/Mega Man/Gimmick/Battletoads/Other handle their invisible object interaction detection?