Page 7 of 23

Re: [library] bump.lua v3.1.2 - Collision Detection

Posted: Tue Apr 28, 2015 6:44 pm
by ivan
Jasoco wrote:Expanding on that, maybe detect collisions (But not resolve) with other polygonal shapes.
IMO, testing IF two shapes intersect is actually straightforward.
Continuous collisions BETWEEN two circles is not too hard either.
But it can get a little messy when you have circleVsRectangle and so on.
It get worse as the number of shape types increases.
Jasoco wrote:Thoughts?
If you don't need collision response,
you can just add static query functions
that test against each rectangle.
Something like:

Code: Select all

circleA = x,y,radius
squares = world:queryCircle(circleA)
for each squareN in squares do
  -- circleA intersect with squareN
It' would be pretty fast too especially when you use partitioning like in Bump.

Re: [library] bump.lua v3.1.2 - Collision Detection

Posted: Tue Apr 28, 2015 7:44 pm
by Jasoco
Yeah, circle vs. rectangle is what I would want to check against. I don't know if I need to switch to a library like HardonCollider just for hitboxes. But I will if I have to. If it'll work well enough. Again I don't really need resolution with circles. Just checking if one overlaps a rectangle. I assume Hardon does that. I'm just weighing my options.

Re: [library] bump.lua v3.1.2 - Collision Detection

Posted: Tue Apr 28, 2015 8:49 pm
by kikito
Jasoco wrote:Expanding on that, maybe detect collisions (But not resolve) with other polygonal shapes.
I don't doubt it's possible, but frankly, I lack the motivation or energy to implement or maintain that. I am not a super-mathy guy. I have been programming bump for several years, and people still find bugs - even if it's got boxes only. The code size would increase significantly in size, complexity, and errors. The interface would be less simple too.
Jasoco wrote:I mean I guess I could pile HardonCollider on top of Bump and use HC for hitboxes and Bump for platforming. If I had to. I would understand why you wouldn't want to put it in Bump for that very reason.
If you are going to do a single new type (i.e. circle vs box) then you could use bump as a broad phase detection (with the circle inside a bump box) and then implement your own stuff.

Code: Select all

local _,_,cols,len = world:move(item, goalX, goalY)
for i=1,len do
  if cols[i].overlaps and collidesAsACircle(item, cols[i].other) then
    -- do something here
  end
end
Notice though that this strategy will only work for "overlap"-type collisions. If you get a tunnelling collision (i.e. the ball is moving so fast it goes completely through a wall in a single frame) you would have to use something different and more complex (probably as complex as bump).

If you are doing something more complicated, with polygons etc, I would *not* use bump at all. I would recommend just using hardoncollider.

Re: [library] bump.lua v3.1.2 - Collision Detection

Posted: Wed Apr 29, 2015 12:29 am
by alberto_lara

Code: Select all

But it can get a little messy when you have circleVsRectangle and so on.
Actually, detecting collision Rect. <-> Circle it's a really easy calculation, as far as I know (and I've tested), the "simple" collision detection applies for the following cases:

Rec <-> Rec
Circle <-> Circle
Rec <-> Circle
And check if a circle is inside another (pretty much like the first one).

As you say, detecting collision for e.g. pentagon and so on would be more complex.

Re: [library] bump.lua v3.1.2 - Collision Detection

Posted: Wed Apr 29, 2015 8:54 pm
by Jasoco
I don't really need polygonal collisions. If I ever wanted to make a game like Braid or NSMB I would look into a different way.

I just really want circles if possible. Just mainly so I can have circular enemies. If I had to I'd just write a separate hotbox system for dealing with checking for enemy to player and weapon to enemy collisions and keep Bump for the actual solid collision resolution.

So I assume HardonCollider would be my best bet? I just really need simple code for rectangular to circle collisions.

Code: Select all

collideRectWithCircle(rx, ry, rw, rh,  cx, cy, crad)
Maybe I could just Google. I don't want to take this off topic since it's not going to be Bump related anymore. Thanks guys. If someone wanted to they could split this conversation into a new thread.

Re: [library] bump.lua v3.1.2 - Collision Detection

Posted: Thu Apr 30, 2015 1:32 am
by alberto_lara
Ok, for Rect <-> Circle collision detection I used the code showed here: viewtopic.php?f=4&t=33493

contained in overlap_example.love (posted by Santos in the 1st page). It's quite a simple code and you can simplify it even more :)

Re: [library] bump.lua v3.1.2 - Collision Detection

Posted: Sun May 03, 2015 11:42 am
by bakpakin
This has probably been done already, possibly in other, better ways, but here's how I added one-way platforms in my Ludum Dare 32 platformer, Command Kibbles. The code is quite short, and makes use of the built-in bump collision responses. It implements a collision response that act like either a 'slide' or a 'cross' depending on the collision normal. This could also be changed to act like a one-way bouncy platform or a one-way sticky platform by using 'bounce' or 'touch' instead of 'slide'.

Code: Select all

local slide, cross = bump.responses.slide, bump.responses.cross

local onewayplatformSlide = function(world, col, x, y, w, h, goalX, goalY, filter)
  if col.normal.y < 0 and not col.overlaps then
      col.didTouch = true
      return slide(world, col, x, y, w, h, goalX, goalY, filter)
  else
      return cross(world, col, x, y, w, h, goalX, goalY, filter)
  end
end

myBumpWorld:addResponse('onewayplatformSlide', onewayplatformSlide)

Re: [library] bump.lua v3.1.2 - Collision Detection

Posted: Sun May 03, 2015 3:09 pm
by kikito
@Fenrir: I think I found the issue and implemented a fix. Please try the version of bump.lua attached on this post. If it fixes your issue, I will release a new version.

@bakpakin: That solution is fine, but for moving one-way platforms, you will need a bit more (platforms will need to "push up" whatever is touching them when they are moving up). With one-way platforms it is tricky, because things tend to "fall off". There's an implementation of moving one-way platforms on the patforms branch of the repo:

https://github.com/kikito/bump.lua/tree/platforms

Re: [library] bump.lua v3.1.2 - Collision Detection

Posted: Sun May 03, 2015 7:34 pm
by sam
Sorry if this has already been answered before, but i was wondering if slanted walls/slopes are a realistic possibility using this library. I'm working on a game that has a similar perspective/collision system as Super Mario RPG, where it's in an isometric point of view with walls that slide the player along them as they walk.

This is a long speedrun of the game, but if you click around it you should get an idea of what I'm wishing to accomplish.

https://www.youtube.com/watch?v=FtlJlYFiteE

If anyone has a method of doing this, that would be great!

Edit: YouTube tag didn't work, whoops.

Re: [library] bump.lua v3.1.2 - Collision Detection

Posted: Sun May 03, 2015 9:54 pm
by kikito
sam wrote:Sorry if this has already been answered before, but i was wondering if slanted walls/slopes are a realistic possibility using this library. I'm working on a game that has a similar perspective/collision system as Super Mario RPG, where it's in an isometric point of view with walls that slide the player along them as they walk.
Hi Sam, I have bad news and good news.

The bad news is that no, bump does not support slopes or slanded walls.

The good news is that you don't need those for doing an isometric game, necessarily.

The main thing you have to take into account is that perspective and collision are two different things. The world can be represented in an axis-aligned state internally, but "transformed into isometric" right before it is presented into the screen. This takes a bit of math, but as far as I know everyone does that.

Give a look at the graphics on the answers to this question: http://gamedev.stackexchange.com/questi ... 7901#37901 - the one at the top is the isometric rendering, while the one at the bottom is how the map "looks" when performing collision detection.