nesrocks wrote:byte 1: object ID
byte 2: attributes
byte 3: X coord low
byte 4: Y coord low
byte 5: X coord high (haven't figured out how to do the whole coords thing yet, so I'm reserving these)
byte 6: Y coord high
byte 7: object state
byte 8: current animation frame
byte 9: current animation frame timer
byte 10: horizontal velocity
byte 11: vertical velocity
The Curse of Possum Hollow roughly follows this, assuming "ID" is an actor class, "attributes" are facing direction and palette swap, and "state" is health. Actor class controls which sprite set and which logic routine are used. I often duplicate frames, with two frames pointing to the same metasprite data, to encode state. And sometimes I use the timer for other state-like things and advance the sprite's animation on a multiple of 8 frames.
byte 12: horizontal velocity high
byte 13: vertical velocity high
byte 14: X coord highest (in screens)
byte 15: height of last damage (used for height-dependent damage response)
byte 16: offset into CHR RAM of start of animation frames
There are also about 16 bytes of state reserved for bosses.
EDIT: Here are some of the things tokumaru's engine stores that mine doesn't.
type, bounding box: Determined by logic routine type
next object in same group: Groups are hardcoded to the first or part of the object table, and there are few enough slots that a linear search for type=empty is enough
link to related object: Not used
Y coordinate 3rd byte:
Curse scrolls only horizontally
angle: Determined by bit 6 of sprite attribute
slope threshold: all walkers have the same slope behavior
animation script pointer: I use only 1 byte because it's a table index, doubling as a frame number
extended state, general purpose: Only one entity can have extended state, and it's the boss
spawn stuff: Not as necessary, as
Curse scrolls only one way