Bitplane based collision detection while drawing sprites

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

Post Reply
simonsunnyboy
Moderator
Moderator
Posts: 5235
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Bitplane based collision detection while drawing sprites

Post by simonsunnyboy »

Today I thought about how to detect a collision while drawing a sprite. E.q. have a bitplane (nr 4) in the background set and use this to indicate a collision (drawinging over color 8-15 should trigger a collision detection)

While drawing the sprite, the onscreen bitplane is obviously read and masked with AND. Now I wondered if there was a simple thing to implement as a sideeffect to detect a set pixel that is masked away.

A clumsy approach might look like this but it takes way too many cycles...
assume a0 points to screen, a1 to mask data

Code: Select all

move.w (a0),d0  ; fetch bitplane and store temporarily
move.w (a1)+,d1  ; fetch mask data  (pixels to keep are 1, pixels to clear to OR the sprite in are 0)
and.w d1,0(a0)+   ; mask onscreen
; now:
not.w d1  ; flip mask bits
and.w d1,d0  ; and the negated mask with the bitplane
bne collision_found    ; if any bit is still set we found a pixel based collision
Any ideas or suggestions?

*EDIT* NOT instead of NEG ofcourse...
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee
User avatar
daeghnao
Captain Atari
Captain Atari
Posts: 479
Joined: Wed Oct 27, 2004 12:41 pm
Location: York, UK
Contact:

Re: Bitplane based collision detection while drawing sprites

Post by daeghnao »

It is apparently (according to my girlfriend) far more common, even on small retro systems, to have either a separate collision map system or to do collision detection with simple circles/boxes. Reason being, using the sprite masks makes for a really tricky game. Also, a separate map means that you can be more dynamic - have different maps for bullet collision versus your own character's collision, or have different size collision areas for your ship compared to enemies. You might also get somewhere with maintaining a Y-sorted sprite list, but I'm unsure of all the trade-offs in this area at the moment.
User avatar
Patrice Mandin
Atari User
Atari User
Posts: 39
Joined: Mon Aug 09, 2004 7:06 pm
Location: France
Contact:

Re: Bitplane based collision detection while drawing sprites

Post by Patrice Mandin »

Linux and Atari coder
Development tools, games
simonsunnyboy
Moderator
Moderator
Posts: 5235
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: Bitplane based collision detection while drawing sprites

Post by simonsunnyboy »

daeghnao wrote:It is apparently (according to my girlfriend) far more common, even on small retro systems, to have either a separate collision map system or to do collision detection with simple circles/boxes. Reason being, using the sprite masks makes for a really tricky game. Also, a separate map means that you can be more dynamic - have different maps for bullet collision versus your own character's collision, or have different size collision areas for your ship compared to enemies. You might also get somewhere with maintaining a Y-sorted sprite list, but I'm unsure of all the trade-offs in this area at the moment.
Well basically this will be a map based approach - the bitplane to be tested is already a map of bits that will trigger a collision.

For sprite to sprite the box method is ofcourse the simplest but on the background it's a different thing. One can do tile based detection with coordinates but it is not as accurate.

@pmdata: I know about your routine but if it requries a blitter it is not 100% what I'm looking for. It shall work on a plain STF aswell.
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee
User avatar
BoNuS
Atari Super Hero
Atari Super Hero
Posts: 771
Joined: Mon Jan 19, 2009 12:45 pm
Location: The Netherlands
Contact:

Re: Bitplane based collision detection while drawing sprites

Post by BoNuS »

Intressting stuff, i'm at that same crossroad it seems.

In my "Men at War" I use a system like this:
256 color mode so 8 bitplanes
4 lower bitplanes for everything that is background like walls and floor.
4 higher bitplanes for men, bombs and bullits.

So walking men it test before I step with bit test, so if bittest is lower than 16 then it is ground or wall.
If it is more then 16 I have a collition with other item like bomb or men.

Bullit works the same way, <16 walls/ground >16 mem or bomb.
Further more I can look this way as in:
color 0 till 3 ground , so I can walk on
color 4 till 10 wall so I have to stop if I walk into it.
color 11 till 16 special effect like bounce back or killed by...

It works okay but has a drawback. Certain colors can only be used in one way which makes
drawing a pain in the .ss, because for example the green color I can would like to use for a tree.
But if that same color also kills it can't be used that way. It limits more then I expected.

The idea of a seperate collitions detection map is one I have in mind too. So simple said
if its 0 you walk and if its 1 you stop. In thats map you can make all kind of hidden features or
usefull features, also killer walls which in de gfx don't have to show.

I guess I have to make a picture to make it more clear (I guess ??) but I'm afraid that I have
to do a lot of re-coding since this is the better way. Also for a level editor you now have 2
different maps. The one you see and play in and the one hidden that takes care of the collition.
I wish I knew that logic years ago ;)
http://bonus.home.xs4all.nl/
( I have just to much Atari stuff)
Post Reply

Return to “Coding”