perhaps you could give me a bit more of a hint on what you are envisioning with the table. I am not sure I can see it/ too dumb to see it.
As for determining which copy was hit, here is an example of my logic for 3 active copies:
1. determine missile x pos ( player x pos + 8 at time of fire , player is double wide) ( assuming player x position is left edge of player)
2. if collision detected
add 12 to enemy left copy x and store ( position half way between copy 1 and 2)
add another 16 to enemy left copy x and store ( position half way between copy 2 and 3
3. if missile x pos> (left copy x +28) then copy 3 was hit
if missile xpos < (leftcopy x +12) then copy one was hit
else copy 2 was hit.
Seems like this should work but it is not......
Your hit detection algorithm appears to be correct. You probably just have a bug in the implementation of it. Don't forget to post asm and bin files for problems like this. We can't help with debugging without them.
Regarding the tables. Here's some more details.
enemyHitIndex - Should be 0 for the left copy, 1 for the middle copy and 2 for the right copy
enemyX - X position of enemy stored as distance between left side of screen and left side of left copy in pixels. This should always apply to the left copy regardless of it being active to keep hit detection simple.
enemyXOffset - offset to be added to the enemyX position when calling the PostionObject routine.
enemyState - 3 bit value indicating the state of the enemy. Spawn with state 7 for 3 active copies, and don't draw for state 0 because there are no copies left. Each bit corresponds to a single copy. 1 indicates the copy is active(visible), and 0 indicates it is inactive(hidden) I.E. %00000101 = X _ X and %00000110 = X X _
EnemyXOffsetLooup - Use the same index as the EnemyStateTransitionLookup to determine what value to add to the current enemyX value. This compensates for deactivating the leftmost active copy of the enemy by moving it right to where the next copy starts.
EnemyStateTransitionLookup - Index into this table with the hit detection result and enemyState to determine what the next state should be. Index is the concatenation of the 2 Hit bits (H) and 3 State bits (S) in the format %000HHSSS
EnemyNusizLookup - Index into this table with the enemyState value to determine the correct NUSIZ1 value.
Here's some sample code. It's untested, but should be close to what you need.
; Calculate state transition index
; update X offset
; assumes C flag is cleared by code above. If something else comes between this two sections add a CLC instruction here
; update current state
; x still has transition index
; Set NUSIZ1.
; assumes A contains enemyState. If this is done late you must replace tax with ldx enemyState
The tables shouldn't be difficult to generate manually. The states are 3 bits, just visualize which copies are still active after a hit occurs. The offsets will be 0 except for a few cases where the left copy is hit, in those cases the value will be 16. The NUSIZ lookup is just mapping the state to the right count and spacing for the remaining active copies.
00000 - 0 ;
00100 - 0 ; Left copy hit, but already inactive. No action required.
00101 - 16 ; Left copy hit and middle is already gone So move over 32 because right copy is all that's left
00111 - 16 ; Left copy hit which means the middle copy will be the new location. So move over 16
01011 - 16 ; middle copy hit leaving only the right copy. So move over 16
00011 - 011 ; State unchanged because inactive enemy was hit, normal execution will never go here
00111 - 011 ; Left copy hit and deactivated
01111 - 101 ; Middle copy hit and deactivated
10111 - 110 ; Right copy hit and deactivated
000 - 7 ; make it quad cause we should never draw this
001 - 0 ; single copy for the right copy
010 - 0 ; single copy for the middle copy
011 - 1 ; 2 copies close for middle and right copies
100 - 0 ; single copy for the left copy
101 - 2 ; 2 copies med for left and right copies
110 - 1 ; 2 copies close for left and middle
111 - 3 ; 3 copies close for left, middle, right