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.
Hardware collision detection bit
Re: Hardware collision detection bit
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.
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.
Re: Hardware collision detection bit
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.)
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.)
Re: Hardware collision detection bit
The C implementation in RAGE1 is exactly the one mentioned by Timmy:
https://github.com/jorgegv/rage1/blob/m ... ollision.c
https://github.com/jorgegv/rage1/blob/m ... ollision.c
Re: Hardware collision detection bin
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]
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]
Re: Hardware collision detection bin
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.
Re: Hardware collision detection bit
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.
I don't know how to explain this better. Thanks for your help and time spent answering.
Re: Hardware collision detection bit
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>
So, it's now available in extern unsigned char _tms9918_status_register; which for want of a better place is defined in <msx.h>
Re: Hardware collision detection bit
Thank you!