Collision detection

Do you live and breathe hexadecimal? Do you like speaking to hardware directly?

Moderator: Programming Moderators

Post Reply
Jonv
Posts: 12
Joined: Tue May 30, 2017 4:53 pm

Collision detection

Post by Jonv » Sat May 26, 2018 7:08 pm

Does anyone have any examples of checking the sprite system for sprite collisions? Had a good look around and not found anything. From reading the sprite documentation I thought that:

Code: Select all

collision:
            ld bc, $303b  ; Sprite status select slot
            in a, (c)
            rra    ; bit 0 into carry flag
            call c, changexdir
            ret
might work but no luck so far.

User avatar
varmfskii
Posts: 186
Joined: Fri Jun 23, 2017 1:13 pm
Location: Albuquerque, NM USA

Re: Collision detection

Post by varmfskii » Sat May 26, 2018 9:32 pm

That looks right if you are trying to detect two sprites colliding with one another.
Backer #2741 - TS2068, Byte, ZX Evolution

Alcoholics Anonymous
Posts: 508
Joined: Mon May 29, 2017 7:00 pm

Re: Collision detection

Post by Alcoholics Anonymous » Sun May 27, 2018 6:15 am

Unfortunately the hw sprite collision is not every useful. You'll end up using bounding boxes or similar in sw.

User avatar
MrKWatkins
Posts: 41
Joined: Tue May 30, 2017 8:37 pm

Re: Collision detection

Post by MrKWatkins » Sun May 27, 2018 10:53 am

I was thinking it could be possible to use the hardware collision by flipping sprites on and off and then testing the flag to work out which two are colliding. Might be quicker in some cases.

EtchedPixels
Posts: 17
Joined: Fri May 04, 2018 10:59 am

Re: Collision detection

Post by EtchedPixels » Sat Jun 02, 2018 4:51 pm

I concur - sprite collision detection is generally useless. Not only does it usually not tell you what collided but it means that whenever something collides you'll have to do a lot of extra work so your framerate has to allow for that work anyway.

Sometimes you can fudge it to be useful - eg if you know enemy shots cannot cross then you can make all the enemy shots and the player the sprites - then any collision is simply the player going boom.

Bounding boxes, squashed copies of objects or just plain cheating usually work best. If you make everything square enough or with sticky out bits you can usually get away with bounding box collisions 8)

Ped7g
Posts: 109
Joined: Mon Jul 16, 2018 7:11 pm

Re: Collision detection

Post by Ped7g » Wed Jul 18, 2018 7:44 am

MrKWatkins wrote:
Sun May 27, 2018 10:53 am
I was thinking it could be possible to use the hardware collision by flipping sprites on and off and then testing the flag to work out which two are colliding. Might be quicker in some cases.
Depends on the HW implementation I guess, I would expect more SW approach, i.e. clearing the flag at the beginning of frame, and setting it per scanline whenever the pixel collision is detected during image creation, then switching sprites off/on would not help, as it would not refresh the collision flag.

But then again, that makes also little sense from HW implementation I guess, unless it is calculated upon read, anything spanning whole frame is probably more cumbersome than something calculated instantly from current values, i.e. some per-scanline would be probably easier to implement.

But calculating it instantly in HW sounds way too complex to me, that's 64x256 pixels, every vs other, even with some cunning algorithm that's like 10k+ of compares... while you can set this flag "easily" on per-pixel basis, whenever you have more than 2 inputs from the sprite render (where already 12 simultaneous inputs are possible).

User avatar
SevenFFF
Posts: 221
Joined: Mon Jun 05, 2017 5:30 pm
Location: USA

Re: Collision detection

Post by SevenFFF » Wed Jul 18, 2018 11:02 pm

Ped7g wrote:
Wed Jul 18, 2018 7:44 am
Depends on the HW implementation I guess, I would expect more SW approach, i.e. clearing the flag at the beginning of frame, and setting it per scanline whenever the pixel collision is detected during image creation, then switching sprites off/on would not help, as it would not refresh the collision flag.
Yes, I'm pretty sure this is how it works. It's quite expensive to read the sprite pixels, even from FPGA BRAM, which is why only 12 sprites (192 bytes read) per video line are possible. I think they're all read during hblank for the line ahead. There isn't any spare time to read that much data all in one burst, as sprites can be in the borders also.
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel Spectron 2084blog

seedy1812
Posts: 67
Joined: Tue May 30, 2017 11:31 am

Re: Collision detection

Post by seedy1812 » Thu Jul 19, 2018 10:56 am

Reminds me of this youtube clip https://www.youtube.com/watch?v=zkZhTt3KSjI (is Pixel Perfect Collision Impossible? - CODING SECRETS ) its Amiga related but might give people some ideas

Post Reply