What is the best way of handling collisions between sprites and backtab?

[Darkhog]

Title. So I can e.g. make game area with backtab end won't need to hardcode where player can go and where he can't.

[+nanochess]

It wouldn't look elegant, as the sprite needs to be over the background item to signal collision.

 

But at same time collision bits are only readable until next frame.

 

This means it would collision in one frame, collision detected in next frame and then you would have to make it back a few pixels, so it would jitter.

[+DZ-Jay]

Title. So I can e.g. make game area with backtab end won't need to hardcode where player can go and where he can't.

It depends on what you mean by "best way." IntyBASIC supports reading the Intellivision's built-in hardware collision registers for each MOB. For information on how to do this, check out the documentation that comes with the IntyBASIC SDK.

 

Alternatively, you can create your own mechanism using bounding-box or similar algorithm to test for collisions in software.

 

Neither is "better" than the other, though; both have their pros and cons: hardware collisions are very fast, but they are available after rendering the current frame, which presumably was computed during the previous frame; so it is always one frame behind.

 

Software collisions give you full control over its timing and mechanics, but require custom code, which obviously incurs a performance hit over the rest of your game loop.

 

dZ.

[Darkhog]

Well, I want to check which card player is touching and then take an action based on that.

[artrag]

For checking which tile is under your sprite convert sprite coordinates to a backtab address

 

If (#backtab(x/8+y/8*20)=const) then ... else ...

 

As nanochess says the HW collision bits will occur after the collision has been displayed so if you mix sw and hw tests you have to take into account this delay