Per-Pixel / Pixel Perfect collision yay or nay?

[JoelLikesPigs]

Hey there! I've decided to take the plunge and start coding using Love2D

All my previous experience coding games has been in scratch - but I've made some pretty good stuff

I want to try converting one of my games into Lua and into a Love2D format - so far so good. I have the basics of my character down - he runs, he jumps etc.

However I'm struggling with the hit detection, scratch can check when two sprites are overlapping, but love2D requires hitboxes/bounding boxes around any objects you want to collide, however, I've come across Per-Pixel / pixel perfect collision on these forums, however most of the posts are several years old, or all the replies are negative saying it shouldn't be done - most say they should use bounding boxes on their objects and work out collisions using that - however this seems like it would take forever if I have several sprites like this: One of my 100 "ground" sprites

Not to mention, I remember reading you can only make 8 sided polygons for detection, which would mean making several hitboxes for a single sprite. So what do I do? I'm aware of the getPixel function and that maybe I could use the none-alpha pixels to create a sort of perfect bounding box but is this the best way? Is this a horrible endeavor? Should I be doing something else?

TL;DR: In Scratch there's an "if touching" block for when two objects are overlapping - I use this and apply my code to separate the sprites - is there a way to create a pixel perfect hitbox around my "ground sprites" and check for collisions on a bounding box. Do you recommend a specific library for this, or is there a better way entirely.

[raidho36]

The only way a box can be perfect match is if original sprite is a box. Otherwise you need to produce a (possibly very complex) shape that reasonably approximates the sprite, which is itself an approximation. Normally pixel perfect collision is done via automatically generating a collision mesh consisting of large number of tiny boxes (usually long across one of the axes) that precisley match original sprite. You don't normally see non-axis aligned meshes automatically generated because as quality requirement increases, code complexity skyrockets, those are usually produced by hand in some sort of physics editor.

[JoelLikesPigs]

Thanks for the reply, though I'm a little confused. So it can't be done? Am I going to have to produce a bunch of separate hitboxes for my ground sprites then?

In my example ground sprite: here I made this using a tile 16x16 tileset, so it's made out of basic shapes, but just so many of them it would be time-consuming to create bounding boxes on every area even more so if I have to alter them after testing them, I have multiple rooms like this in my game.

[zorg]

Why would it be time consuming? When you create the ground, you do it piece by piece, i'm guessing, since you did mention a 16x16 tileset; just have a collisions table having the bounding box data generated with it, for each tile.

That said, i'd look into kikito's Bump library, since that's an easier solution: https://github.com/kikito/bump.lua

Technically, it can be pixel perfect too, since your tiles don't have gaps in them, nor are they jagged around the edges; and even if they were, graphically, most games still use smooth bounding boxes anyway, for those kinds of platforms, for example.

[JoelLikesPigs]

ah cool! I'll check out this library. I only brought up the fact the ground sprite was made from a tileset because of the previous comment mentioning non-axis alignments, I figured it would clear up how the sprite was made and maybe shed some light on that area. I could potentially export my ground sprites as collision tables, but I already have them all as pre-made images. I figured I'd be saving time doing so, but maybe not?


I'm still working in a scratch programming mindset so a lot of these techniques are new to me. Thanks again I'll check out that library.

[megalukes]

Have a look in this article. It helped me a lot back in the day. Most of the tilemap tecniques the author describes can be done with this library. Good luck!

[0x72]

Hi!

For a simple platformer you should probably go with a tilemap and regular collision tests as people suggested.

However, I'd like to note that pixel perfect per-pixel[*] collisions - although not common - are not difficult at all; they should be good for simple projects and can yield interesting results. For instance one could have destructible environment like in Worms (not that I have any other example... but you get the point!)

I guess Scratch does something similar to the example I've prepared[**] (I've used your assets, hope you don't mind ). It's super simple, more of a demo of technique then anything else, but seam to have no performance issues (as expected, I'd be surprised if LÖVE perform worse then Scratch. Also: there is plenty of room for performance improvement if ever needed).

[*] not sure about the terms, if you just test AABB but you do this with pixel resolution is it pixel perfect?
[**] it was also fun to write

[JoelLikesPigs]

Thank you 0x72, is it possible I could look at the source code of the example you made.

The Love forums really are a friendly place. I've got a lot to read into thanks so much for everyone's help

[zorg]

Thank you 0x72, is it possible I could look at the source code of the example you made?

Change the love file's extension to zip, then extract contents into a folder.

[0x72]

As zorg said. .love are just a zip files just like .sb2 are.

I've tried to have comments wherever it might not be obvious but if you have any further questions fear not to ask .