Sprite to *background* collision detection

[Willsy]

Salutations!

 

Has anyone got any code I can look at that does sprite-to-background collision detection? This sounds terribly difficult to me. If sprites are at 2x2 magnified then you are covering 16 characters of screen space - that's assuming that the sprite is exactly lined up on a character boundary, otherwise you're covering a 24 character area!

 

WOWSERS!

 

I think the best way to do it is to read the sprite definition data into a buffer, and shift/mask as necessary and then do some XORing (or something) on the character definition data.

 

It sounds horribly complex and I'd appreciate some help/pointers from anyone that's done this before. I'd like to add the feature to TurboForth - it won't fit in the ROM then I'll include it on the tools disks as a loadable option. It would be a really cool feature if I could include it.

 

If my memory serves me correctly, Marc Hull did something similar in his Lander game? I haven't seen Marc post here in a long time.

[Asmusr]

http://www.dsapsc.com/code-snippets.html

[Willsy]

Thanks. I'll take a look at that. At the moment I'm thinking about a compromise. It would be quite effective to be able to determine (in 32 character mode) if a particular character were covered by a sprite. Dealing with the situations where the sprite doesn't line with a character boundary makes it harder. I think 2x2 un-magnified would be an acceptable limit on it.

Edited September 9, 2015 by Willsy

[+Lee Stewart]

Salutations!

 

Has anyone got any code I can look at that does sprite-to-background collision detection? This sounds terribly difficult to me. If sprites are at 2x2 magnified then you are covering 16 characters of screen space - that's assuming that the sprite is exactly lined up on a character boundary, otherwise you're covering a 24 character area!

 

WOWSERS!

 

I think the best way to do it is to read the sprite definition data into a buffer, and shift/mask as necessary and then do some XORing (or something) on the character definition data.

 

It sounds horribly complex and I'd appreciate some help/pointers from anyone that's done this before. I'd like to add the feature to TurboForth - it won't fit in the ROM then I'll include it on the tools disks as a loadable option. It would be a really cool feature if I could include it.

 

If my memory serves me correctly, Marc Hull did something similar in his Lander game? I haven't seen Marc post here in a long time.

 

Here is what I translated from TI Forth to fbForth's ALC definitions of SPRDIST , SPRDISTXY , COINC , COINCXY and COINCALL , among other graphics primitives:

 

fbForth104_GraphicsPrimitives.a99

 

COINCXY should (could?) be what you are seeking.

 

...lee

[Willsy]

Thanks Lee, I'll check it out!

[TheMole]

Keep in mind that most games don't use or need pixel perfect collision detection. There's a very interesting article written by the guy who wrote M.C. Kids on the NES which includes a section on how they handled collision detection back in the day and is a pretty good explanation of what most games need/use: http://games.greggman.com/game/programming_m_c__kids/

This is also the approach that I use in Alex Kidd, with that difference that I only use 6 test points instead of the 8 that are used in M.C. Kids.

 

Using the VDP collision bit usually only makes sense for games where you die when you hit the scenery, like in asteroids style games, space shooters, etc... The reason for this is that in most other games you need to react to a collision by pushing the player back, sliding him across a slope, slowing him down, etc. The routines to handle this collision reaction rely on calculations that you would've done to detect the collision in the first place so you're not winning anything by relying on the VDP collision bit.