Link Here: https://www.gamedev.net/page/resources/_/technical/game-programming/intelligent-2d-collision-and-pixel-perfect-precision-r3311
Advertisement
Moved as an article.
Link Here: https://www.gamedev.net/page/resources/_/technical/game-programming/intelligent-2d-collision-and-pixel-perfect-precision-r3311
Link Here: https://www.gamedev.net/page/resources/_/technical/game-programming/intelligent-2d-collision-and-pixel-perfect-precision-r3311
Previous Entry
Simple 2D game... Simple collision? Probably not? =-=
Next Entry
New Blog and featured guide.
Advertisement
Advertisement
Comments
Comments are shown oldest first so the discussion reads top to bottom.
December 23, 2011 01:51 AM
Thanks!
I am doing this research on pixel-perfect collision for my last project, I want it to be as precise as possible, even if the player is using wide quad high def with 2560x1440!
This way I can insert even small projectiles and make them work well without hitting air or anything.
Just to make it more visually appealing, if you get me, as well as training myself while doing it!
Still, the pixel-perfect is just one step away from the bounding box!
It just forces me to optimize further!
I'll probably go back and use simple circular/box collision if the performance proves itself invincible! haha
I am doing this research on pixel-perfect collision for my last project, I want it to be as precise as possible, even if the player is using wide quad high def with 2560x1440!
This way I can insert even small projectiles and make them work well without hitting air or anything.
Just to make it more visually appealing, if you get me, as well as training myself while doing it!
Still, the pixel-perfect is just one step away from the bounding box!
It just forces me to optimize further!
I'll probably go back and use simple circular/box collision if the performance proves itself invincible! haha
December 23, 2011 03:24 AM
Nice article. Long ago I did my own pixel perfect collision, using the 1-bit mask you mentioned before, but performing a bounding box 1st. This turned out to be a requirement for my shump; if any game type needs precise collision, it's shumps. Back then, I didn't know what spatial hashing was, but, it didn't seem to matter for my game as I never had that many objects/enemies.
As you probabl know, I've become a spokesman for 2d physics libraries to do my collisions and movements, but It's always good to have a good understanding of how it all works.
As you probabl know, I've become a spokesman for 2d physics libraries to do my collisions and movements, but It's always good to have a good understanding of how it all works.
December 23, 2011 05:21 AM
Yes, in this article I speak about the bounding boxes, explaining a little how to use them!
As you can see here, in my first paragraph of the bounding box section:
[quote]The bounding box check is both, the most easy and the most efficient way we have to reduce overhead on pixel-perfect collision games! Before you check if two sprites are colliding you check if they are near enough to have any chance of collision. If their bounding boxes aren't touching, there's no reason to check for pixel collision, since all pixels are necessarily inside their bounding boxes.[/quote]
I also go on a bit around simple spatial hashing, nothing fancy, just the old immaginary space boxes.
I'm actually reading a little on Box2D as well as Chipmunk, but I have no projects that needs more physics other than simple gravity, if you get what I mean. I'm somewhere near metal slug or megaman x series.
No doubt I'll be using physics on my next titles, thats for sure! Most probably Box2D.
Thanks for the input!
As you can see here, in my first paragraph of the bounding box section:
[quote]The bounding box check is both, the most easy and the most efficient way we have to reduce overhead on pixel-perfect collision games! Before you check if two sprites are colliding you check if they are near enough to have any chance of collision. If their bounding boxes aren't touching, there's no reason to check for pixel collision, since all pixels are necessarily inside their bounding boxes.[/quote]
I also go on a bit around simple spatial hashing, nothing fancy, just the old immaginary space boxes.
I'm actually reading a little on Box2D as well as Chipmunk, but I have no projects that needs more physics other than simple gravity, if you get what I mean. I'm somewhere near metal slug or megaman x series.
No doubt I'll be using physics on my next titles, thats for sure! Most probably Box2D.
Thanks for the input!
December 23, 2011 03:39 PM
Nice article.
What is the reason that it is common to divide the playing are into 4? why isn't there any other number being commonly used?
What is the reason that it is common to divide the playing are into 4? why isn't there any other number being commonly used?
December 24, 2011 10:30 AM
Actually, 4 is used just as an example everywhere. Most games will probably use a grid with more sections!
Still, that's way too much game-dependant! This is the reason why we use 4, it's just an example, let's make it simple!
Just consider that if your game has not a real lot of entities to collide, 4 can be a good number of sections! (actually even 2 can do the trick...)
When designing your game collision detection system, consider the following:
1 - Grid Shape;
2 - Grid Size.
The final number of sections will be nothing more than a consequence of these.
At the Optimization part of the article I speak about different grids!
[quote]If you pay attention to our grid, it has only 4 sections, the sections will have lots of objects in them, what if we increased the number of sections to... let's say... 10? What if, instead of dividing in 4 cartesian-like quarters I divided in horizontal sections?[/quote]
Still, that's way too much game-dependant! This is the reason why we use 4, it's just an example, let's make it simple!
Just consider that if your game has not a real lot of entities to collide, 4 can be a good number of sections! (actually even 2 can do the trick...)
When designing your game collision detection system, consider the following:
1 - Grid Shape;
2 - Grid Size.
The final number of sections will be nothing more than a consequence of these.
At the Optimization part of the article I speak about different grids!
[quote]If you pay attention to our grid, it has only 4 sections, the sections will have lots of objects in them, what if we increased the number of sections to... let's say... 10? What if, instead of dividing in 4 cartesian-like quarters I divided in horizontal sections?[/quote]
December 24, 2011 02:11 PM
Nice article.
Just one note. Isn't a "boolean matrix" just a very inefficiently implemented bit mask?
Just one note. Isn't a "boolean matrix" just a very inefficiently implemented bit mask?
December 25, 2011 09:07 AM
Yes, they're basically the same thing and both can be implemented in relatively efficient ways. The advantage of the matrix is that it is intuitive to implement, better for beginners as simplicity is welcome. Wont make much difference in most cases, since anyone who is willing to implement such thing instead of using Box2D or other library is building simple games... If not, then this person ain't a beginner anymore, knowing what has to be done and how.
As of our example here, we will make few bitmask collision tests per frame, since [i]player/bullet [/i]versus [i]ground [/i]shouldn't use it.
As of our example here, we will make few bitmask collision tests per frame, since [i]player/bullet [/i]versus [i]ground [/i]shouldn't use it.
December 25, 2011 02:20 PM
Nice article. While I'd thought to combine the pixel perfect CD with bounding boxes, it never occurred to me to separate screen regions. First few minutes on this site and I've already learned a new technique.
December 31, 2011 05:24 AM
Thanks for your comment, Fractur65!
If you wish to go deeper, try some of the links at the bottom of the article, they have more in-depth information as well as techniques not explained here! It's really worth 5 min to take a fast look at each and see if they are interesting to you!
If you wish to go deeper, try some of the links at the bottom of the article, they have more in-depth information as well as techniques not explained here! It's really worth 5 min to take a fast look at each and see if they are interesting to you!
January 01, 2012 06:21 PM
I skimmed them, and plan on reading more.. I'm always looking for more resources, so I was glad to see you included so many links at the end. This came at a time, I'm actually working on a small (very, I am still new to this) project that's going to have a lot of gunfire to check collisions for.
January 02, 2012 06:36 AM
Latest Entries
Finally got hired!
4104 views
Simple Animated Sprite with L
4047 views
Introduction to L
3265 views
Lua Snippets
3241 views
SDL_vault is now functional.
2962 views
SDL_vault, an asset loading helper (Updated)
4174 views
Little Game Programming Love [LGPL]
2896 views
YAML Parsing
3685 views
My personal Gamedev Bookmarks
2731 views
Simple Keyboard input interpreter
2685 views
Advertisement
I personally use bounding box collision for most projects, and sometimes I mix in using an array to check a grid. I rarely use Pixel Perfect unless need be, but I have a great desire to make more classic games.
Keep up the great work!