MSX (Software) Sprite Collision Routine

By Chilly Willy

Expert (66)

Chilly Willy's picture

15-10-2021, 20:32

I ended up with 8 sprites but when I looked up the specs on the TMS 9918 it has no clue in determining which one of those sprites are hitting another. If it does I haven't been able to figure it out.

Can someone share code of how to do this without some BIOS call?

Crossing x and y paths perhaps but how does that work with offsets because x and y only applies to the upper left hand corner of each sprite.

Many thanks in advance.

Login or register to post comments

By thegeps

Paladin (881)

thegeps's picture

16-10-2021, 00:46

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

By Chilly Willy

Expert (66)

Chilly Willy's picture

19-10-2021, 05:32

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.

By Grauw

Ascended (10146)

Grauw's picture

19-10-2021, 10:18

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.

By NYYRIKKI

Enlighted (5889)

NYYRIKKI's picture

19-10-2021, 10:32

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)

By thegeps

Paladin (881)

thegeps's picture

19-10-2021, 11:10

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

By PingPong

Prophet (3789)

PingPong's picture

19-10-2021, 11:46

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