Hardware collision detection bit

Post Reply
helmha
Member
Posts: 10
Joined: Sun Sep 12, 2021 10:37 am

Hardware collision detection bit

Post by helmha »

In my game I have 2 sprites. I'd like to have a simple collision detection routine by using the hardware collision bit (bit 5 in VPD status register $BF). How can I access that bit without messing up the interrupts? Because they seem to not work after reading the status register. The status register is already read in the tms9918_interrupt-routine but result is not stored anywhere to be used later.

Thanks for your help.
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: Hardware collision detection bit

Post by dom »

Oh, that is a bit poor isn't it!

Sounds like we need to cache it and provide a couple of helper functions to access it. It's trivial to do for most of the targets, though I can't easily spot how to do it for an MSX rom.
Timmy
Well known member
Posts: 392
Joined: Sat Mar 10, 2012 4:18 pm

Re: Hardware collision detection bit

Post by Timmy »

My suggestion would be, don't use hardware collision check. It's just not reliable enough.

If you really want to, you can write your own inline assembly for it, there's some code of it in the second link.

More information about this feature:

https://nicole.express/2021/alf-2-alf-harder.html
https://www.msx.org/forum/msx-talk/deve ... on-routine

I have always used bounding boxes for these things, either on the MSX or on the Spectrum. It's more portable and it gives much better gameplay.

I write the bounding box code in C. It's easy and fast. (It's not really obvious but when people understand how it works, it's really easy.)

There's also a whole library of rectangular routines in /z88dk/libsrc/rect, but I have no idea how to use them. (And I don't need to.)
User avatar
jorgegv
Well known member
Posts: 287
Joined: Wed Nov 18, 2020 5:08 pm

Re: Hardware collision detection bit

Post by jorgegv »

The C implementation in RAGE1 is exactly the one mentioned by Timmy:

https://github.com/jorgegv/rage1/blob/m ... ollision.c
helmha
Member
Posts: 10
Joined: Sun Sep 12, 2021 10:37 am

Re: Hardware collision detection bin

Post by helmha »

Sure Timmys suggestion works and I've used it in other projects but in this one it's too overmeasured/oversized/overcomplicated (lack of better words).

In my tests written with Sjasm collision bit does work reliably enough. But when I want to use that in C with interrupts handling the music, problems arise.

[edit] In timmys msx.org link, I'm with NYYRIKKI. Handle the more in-depth collision test AFTER the collision bit is set sounds sane to me, instead of constantly checking for collison by software.[/edit]
Timmy
Well known member
Posts: 392
Joined: Sat Mar 10, 2012 4:18 pm

Re: Hardware collision detection bin

Post by Timmy »

helmha wrote: Wed Oct 20, 2021 11:45 amIn my tests written with Sjasm collision bit does work reliably enough. But when I want to use that in C with interrupts handling the music, problems arise.
Ha! I think you missed my point, or everyone else's point.

This is an important point.

You CANNOT do hardware time-sensitive things while also having interrupts doing things, ever. Not in sjasm, not in any other compiler. Not on the MSX, not on any z80 machine.

I could explain the interrupt mechanism here, but the conclusion is pretty simple.

You can either:
1) Do hardware related things only when interrupts are off, or
2) Play music only when you don't do hardware collision checking.
3) The software solution doesn't have this problem.

Most people do 3) or 1), but 2) also works.
helmha
Member
Posts: 10
Joined: Sun Sep 12, 2021 10:37 am

Re: Hardware collision detection bit

Post by helmha »

Umm... The code written with sjasm also reads the vdp status register at entry and stores it for later use (z88dk interrupt handler doesn't store it), then plays a frame of the music and finally returns to main code. Then I check the previously stored vdp status register value and check for the collision bit. If collision bit is set then do what is needed. And it works.

I don't know how to explain this better. Thanks for your help and time spent answering.
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: Hardware collision detection bit

Post by dom »

Regardless, it seems sensible to capture the status register since most BASIC ROMs either store it, or pass it on to any user interrupt routines.

So, it's now available in extern unsigned char _tms9918_status_register; which for want of a better place is defined in <msx.h>
helmha
Member
Posts: 10
Joined: Sun Sep 12, 2021 10:37 am

Re: Hardware collision detection bit

Post by helmha »

Thank you!
Post Reply