1.
You technically define the bounding box in your collision handling routine since that's what checks what pixels are colliding. So yeah you always define a bounding box in some way.
2.
The $0200 RAM page can be named oam_buffer or oam_shadow or something, and to access $0203 (sprite 0's x-position) for example you just use oam_buffer+3.
Also you might want to have some kind of metasprite system. Metasprites are also called objects (confusingly enough Nintendo uses the term "object" for the hardware sprites), and is what you refer to in your logic code. They don't have to be hardcoded into hardware sprite slots, you have a routine that runs every frame (as part of your logic, not in your rendering update) and translates your object data to OAM data and puts them in unused oam_buffer slots. You can also have it check how many sprites there is on a line and cycle them to make them blink to allow more than 8 sprites on a line (sometimes called sprite mutliplexing but that term also seems to have other meanings). Your object movement logic, collision logic etc never has to bother with oam_buffer slots, that's all taken care of in the object system. They only addresses these software objects. An object can also be made up of several hardware sprites. 1 parent sprite and 3 child sprites for 16x16 objects for example. The child sprites always have a position that is relative to the parent sprite (enforced by the object system routine), so only the parent needs to be moved by the movement logic code.
So your logic code may look something like this (for example):
Code: Select all
jsr input_read ;reads input devices (like the controllers) and saves their states in RAM
jsr input_handler ;checks player inputs and gives commands to player object to move
jsr object_movement ;moves objects according to physics, player input and enemy AI etc
jsr object_collision ;handles collisions and re-adjusts positions according to that
jsr object_system_handler ;looks for free sprite slots in $0200 and converts object data to OAM data
So your objects have their own format of data which the object_system_handler interprets and uses to build the OAM data in $0200.