Complex collision detection?

I’m creating a pinball game that will need some relatively complex collision and I’ve hit a wall the past few days trying to figure this out. The map scrolls on the y axis, if that matters, anyways I am looking for a simple way to detect collision against a collision bitmap (which will be somewhat different to the display bitmap for obvious reason) - ideally something like getPixel in the arduboy2 library but reading a static bitmap, not active display data. I am pretty new when it comes to C and I think trying to do something this complex for my first program is probably a bad idea but I’m far enough into the project now that I need to just power through. Is there an available library that can do this for me, or an easy way to apply or adapt getPixel to a static bitmap?

Using the screen buffer for the collisions it might not be the correct way to achieve this. Do you have an example of the code related with the issue? How do you generate in first place that screen?

1 Like

Well there would be many issues with using the screen buffer anyways, objects that are visible aren’t necessarily collidable so I need to differentiate between the visible and the collidable. Since the screen buffer is only the visible portion I prefer to avoid that, hence the hesitation of using getPixel as it is - though if I truly simplified the game, this wouldn’t even be an issue but I wouldn’t be happy with such a simple game… I would like to read a bitmap in the PROGMEM, albeit one that isn’t displayed, for collision detection…
The screen is only a bitmap (drawBitmap) at this time so not much code to show related to that, it simply moves with the ball, if ball moves up, the bitmap moves down (to keep it centered) and no collision as of now aside from the 128x64 boundary of the screen

Yeah but the screen buffer is accessed by getPixel, that is what I mean. If you are drawing things to that buffer (everything that happens before calling arduboy.display() ) then there should be a way to do the collision detection in that stage…

Ah, if I draw both bitmaps and call getPixel() and my collision routine before the last bitmap is rendered then it works as I want it to.

There are very basic collision detection functions in the Arduboy 2 library but they only detect if a given point is colliding with a given rectangle, or a given rectangle is colliding with another given rectangle. You have to keep track of these points and rectangles separately but in sync with your bitmaps and other objects.

This may not be what you’re looking for but perhaps examining this library collision code will help with devising your own methods. You could also look at some of the games that use these functions, such as Team A.R.G.'s Reverse Mermaid Hockey, Shadow Runner and Epic Crates of Mass Destruction.

Well sure, but that would mean recreating a playfield with rectangles… while not particularly difficult, it would be relatively time consuming - nevermind that it took me this long to figure out the “quick” way, but it’ll at least be faster to recreate. The benefit to recreating it with drawRect() though is custom physics per component. A wall could behave different to a rubber slingshot, for example… I think I can take care of that with some relative location based if statements though, it’s not THAT complex.
My biggest goal was to have different playable levels. I don’t think I’ll get more than 2 with my method since I’m already at 70% memory. I would be in better shape if drawCompressed() didn’t make scrolling nearly impossible

Thanks for the help guys - I’m a quick learner hopefully I can get some games out and start contributing

I understand, that you are not asking this but it is best practice to handle the physics, gamelogic and display separately.

Doing the collision with “rectangles” is far simpler than to draw one. Handling the physics on pixel level is far more complex than do it on math basis. #my7cents