LÖVE

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.

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.

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.

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.

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.

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!

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

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

JoelLikesPigs wrote: ↑Sun Mar 05, 2017 11:14 pm 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.

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 .