Collision checking against a static background.

I think I must be missing something simple, or have the wrong idea completely cos I’m driving myself nuts trying to work this out.

A very simple car game, a moving sprite on a background.
I have a background mask which is black and white, it won’t be drawn, it’s just reference, and of course I have a car sprite with a texture.

I can get the rotated car sprite’s color map ok, but I’m struggling to create a small ‘crop’ of the background in the same rotation so I can then create a color map and check against the two.

In my head I need to create a crop texture the same size, rotation and position of the background.
Then extract the colour map of the crop.
Then I can pixel check the 2 color maps.

I’m getting stuck creating the background crop texture of the right size, because the rotation causes a larger footprint than the texture I need the color map from. And I can calculate how big the footprint is, but then that’s larger than the color map I need to create.

Does any of that make sense?

Is this the ‘right’ way to do this, or am I missing something a lot simpler?

Thanks.

I’ve been doing this kind of stuff in my latest game… Its a side-scroller, but same terrain collision principles…
(Look for “Grinder” here on the forums, and check out the PICTURE series I posted on my level 2 creation)

I DID have a working system that would crop my entire level to screen-size bits, (plus a little around the edges)
and do collision detection on that…

But i found a MUCH better solution to this that I would recommend… Here it its:

My level was 16 1920*1080 images in a row. I ended up loading EVERY pixel into a huge 2d array, and only testing KEY POINTS for collision… (perimeter around the wheels, front and rear bumper, etc)…

This way, I can just test ANY coordinate I want, against the SAME coordinate in my array…
like a missile-tip or bullet with screen position (244,122) checks the terrainArray[244,122] for whether or not its open or closed, black or white, whatever… (and in the case of scrolling games, just add the camera position to the screen position)

This has ALSO opened up for DYNAMIC terrain, in a much easier way… Because its easy and fast to change array values…

In every way this system has been better for me SO FAR… And it was lightning fast to IMPLEMENT…

Oh yeah, and I should recommend you download the demo… You can see it working with your own eyes :slight_smile:

Hello mono. Yes, we were talking about this a couple of days ago.

So you have actually implemented the array idea without issues?

Yes! And its wonderful in every way. No issues :slight_smile:

Also, if you need specifics, ask away. I’d be glad to help…

I tried at first using the color array returned from GetData, but I found the maths a bit funky with all the vectors I had to work out for rotating sprites. So I then bundled the color array into a 2d integer array and used that instead.

So, I take a double memory hit while setting up the map, but I release the color array as soon as the 2d array is built.

I used an integer array rather than boolean as I can set the value depending on the mask color, therefore I can check for different road conditions as well as collision points.

Yes, it is super fast without a doubt. It wouldn’t have worked for my last test project as I needed to check each pixel, but in this project it is pretty much perfect.

The only downside, I can’t think of an easy way to use this kind of approach for sprite on sprite. But that wasn’t the point of the exercise.

Thumbs up!

Cool!

About using it on sprites, I guess you do the same process as with terrain actually…

Load the sprites color mask into a 2d array contained within whatever object holds the sprite…
And if, say, a projectile enters its bounding_box, it checks against the array…

Of coarse, that doesn’t factor in rotation of the sprite… Which I guess would be the tough one…
Perhaps you could load 16 evenly spaced degrees of variation… Setup a method to do this automatically of coarse.
-And then just check against the nearest one… Wouldnt be pixel perfect, but for 2 sprites on the move, it might be enough.

Sounds like a chore to code though.