MSX (Software) Sprite Collision Routine
You have to set collision boxes and check box coordinates between all the sprites that may collide... forget hardware collision detection.
Defining your sprites starting from top left corner (instead of center them in the 16x16 square) will help on check (less offsets to apply)
Example: 2 squares 16x16
You know for sure that a collision may accour when player_y is in the range from enemy_y-15 (bottom line of player sprites overlaps top line of enemy sprites) to enemy_y+15 (top line of player sprites on bottom line of enemy sprite).
When this condition is verified you can check in the same way for the x coordinate.
So you need 4 checks to know if a collision has occourred. Obviously if any of those checks fails then there is no collision and you can ret from this routine (or check for next enemy)
And check only for active enemies: set a table where you can check if a sprite is active (on screen) or not (1/0), so before check coordinates you can skip checking for inactive sprites/objects
I found this from Tony Cruise's work
COLLISION_TEST:
LD A,(IX+00)
CP (IY+00)
JP NC, NOHIT
ADD A, E ; get our original value back
ADD A, L
CP (IY+00)
JP C,NOHIT
LD A,(IX+01)
SUB D
CP (IY+01)
JP NC, NOHIT
ADD A, D ; get our original value back
ADD A, H
CP (IY+01)
JP C, NOHIT
SCF
RET
NOHIT:
XOR A
RET
HL is your main sprite size
DE is the Sprite you are colliding with
ld DE, 1010h would be a 16x16 sprite
just using this is really a pain and is highly inaccurate.
I am still learning and although I kind of understand it I am at a loss.
I know I kind of rubbed a bit in my last post and I am really trying to fit in.
A few posts ago a gentleman really helped me out and posted the routine from Konami about how to detect sprites hitting patterns.
It was an excellent routine, I am highly grateful and now use it in all my current as well as updated my old work it is that good.
I am hoping that someone has a routine in similar quality or a link to where these mandatory routines are because this is really the final problem outside of making music and sound effects before I get a polished title.
As I alluded to, if I rubbed someone wrong I wholeheartedly apologize but I am lost without this help.
What I am doing is making an MSX version of Atari 2600 Adventure in Z80 assembly language that will be portable to any other Z80 with a TI9918 or compatible VDP.
The differences between the Atari 2600 and MSX are so incredibly opposite that I have run into a multitude of problems and collisions are the last of the last I have to figure out.
So far I have all the mazes and patterns in place, movement logic and a mapping system. 360 degree collisions is the final barrier and when it is all done I plan post the source for anyone who wants to learn from it.
Chilly Willy wrote:
just using this is really a pain and is highly inaccurate.
Can you elaborate what kind of troubles you have with this routine? Because it seems to correctly do a box overlap check, and accurately. The only limitation being that the boxes must have the same specified size. If it doesn’t work for you I think you should look at what input coordinates you’re passing in.
I would not maybe completely throw away the hardware check... I would add it as first check. If no sprites are colliding, no need to do box check. This has the added benefit that it may go unnoticed if invisible parts of sprites collide. (Less deaths caused by close encounters)
You are right. I suggested it only because I've noticed that some people, when drawing multicolor sprites on msx1 (overlapping them) often aren't too accurate and draw filled colors ones simply overlapping each other instead of leaving empty pixels where other color sprite will be... so there is always a collision condition so hardware collision check is always a time-waste check
NYYRIKKI wrote:
I would not maybe completely throw away the hardware check... I would add it as first check. If no sprites are colliding, no need to do box check. This has the added benefit that it may go unnoticed if invisible parts of sprites collide. (Less deaths caused by close encounters)
Hw support is not flexible enough. And it is not a VDP failure. Even the C64 that can set a bit in a byte for every sprite that collide with another is a bit more than vdp but far than ideal. For example with this binary configuration:
10001100 you can say that sprites 8,4,3 are colliding but you cannot say which. So bounding box is almost always necessary
Войдите или зарегистрируйтесь, чтобы получить возможность отправлять комментарии