Implementing pixel precision collision on OS4 ?

Hello

I have made a program called GMAP that use "sprites" collision (not real sprites just bitmap with transparent parts)

I do the collision with boxes then with the cpu for the intersecting area

YLOOP(Src1.h)
{
XLOOP(Src1.w)
{
if(RevertX) x2=Src1.w-x-1; else x2=x;

pix1=((PIX1[x ] AND alpha) != 0);
pix2=((PIX2[x2] AND alpha) != 0);

if(pix1 et pix2)
{
Collision=TRUE;
goto done;
}

}
PIX1+=offset1;
PIX2+=offset2;
}

The RevertX allow to test "sprites" that are X flipped
(characters going right or left)

But this simple method cant allow to test "sprites" in any position (I mean rotated or Y flipped)

Compositing allow to draw rotated "sprites"

So is there a way to obtain pixel-collision with the Compositing ?


Alain Thellier

@thellier
While you can most likely hack something together using Compositing (after all I even squeezed some sort of hardware z-buffer out of it in WingsBattlefield) so that the result is a bitmap where e.g. all not colliding pixels are masked out or so, it's most likely much faster to do it in software.

After all you'd have to lock and read back your "collision"-bitmap after the special collision-check-rendering.
And in that time a decent "manual" approach would be long done already.

Makes no sense IMHO (at least for your case, exception see below in "additional notes").

However, if you really want to do it, you'd do something like that:

0. I asume you want check for collision between 2 rotated / scaled COBs (Compositing OBjects :P ) which are RGBA bitmaps.

1. select the one with the smaller number of pixels in its bitmap, let's call that A. The larger one is B.

2. change your point of view so that B's rotation, scale and position is adjusted so that those values end up being relative to the unrotated, unscaled, 0,0-positioned A.

3. have an IGraphic RGBA bitmap prepared and cached that matches the size of A.

There are maybe several options on what to do next, one possible approach could be the following (untested, just from guessing / recalling the meanings of the flags and modes; I might be wrong or there's probably a way to make it more efficient, but it should get you on track nevertheless):

4. clear the bitmap to RGBA0000

5. draw B (properly scaled / rotated as in (2)) with COMPOSITE_Src and COMPFLAG_DestAlphaOverride. Important is to *not* set COMPFLAG_IgnoreDestAlpha because we need B's transparency info; setting that flag would also disable writing to the alpha-channel IIRC.

6. draw A into the bitmap, unscaled, unrotated to 0,0 with COMPOSITE_Dest_In_Src. Again, no COMPFLAG_IgnoreDestAlpha.

By all that only the parts where texels of both A and B contributed to should have alpha-values != 0 in the bitmap.
So the final steps are:

7. lock the bitmap, get pointer and stride.

8. loop through the pixel-data, as soon as you find any pixel with an alpha != 0 then you have a collision.

9. unlock


Some additional notes:

- if you want to test for collision only and don't care about with what you collide (e.g. a shooter where you die on contact with any enemy or so) then you can extend (5) and draw all your colliders B0, B1, ... Bn before proceeding with (6); use COMPOSITE_Src_Over_Dst then.
Note that this is a usecase for which this approach may be faster than the naive manual software check, because the player's ship and thus the collision-check-bitmap is very small, lot's of bullets / enemies share the same bitmap and can therefore be drawn in large batches.

- you can probably gain performance by trading some accuracy: just scale the collision-bitmap's size by 0.5 or whatever. Of course you must scale everything else then too.

- for "manual" software-collision-checks you'd of course do the same as in (2): transform everything into the local coordinate-system of the smaller bitmap to simplify things.