[library] bump.lua v3.1.4 - Collision Detection

Showcase your libraries, tools and other projects that help your fellow love users.
Sarcose
Prole
Posts: 48
Joined: Wed Jul 08, 2015 12:09 am

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

Post by Sarcose »

Been a while since I've read this thread. Was the slopes problem ever solved? I don't remember if this method was floated around, but wouldn't it be trivial to, in your own game engine, define a separate movement type for cells with sloped tiles? As long as each tile entity has a straight line you can define as its surface (any tile under a certain size would be visually fudged enough with a straight line even if it looked like it had uneven surfaces), you could use filters to set the player's movement along a vector that ignores collision with the ground - while isGrounded, you're probably turning off gravity anyway. You don't need bump.lua to tell the player to not move inside a ground tile over and over as long as you haven't disconnected with it in the first place.

Taking it a step further, you could use bump to reassure the engine the entity is standing on the ground and then use the ground as a rail to move along (say, a variably-shaped path along which there is only forward and reverse, which terminates at the first instance, in either direction, of a pixel height that is too tall for the entity to overstep). I considered this, but having less experience with programming my own collision, I'm not sure how much extra load that would add to the game.

kikito would you say bump could be used easily as a broad, first-pass engine in these special cases, then the dev can just add collision logic outside the project's scope?
User avatar
D0NM
Party member
Posts: 250
Joined: Mon Feb 08, 2016 10:35 am
Location: Zabuyaki
Contact:

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

Post by D0NM »

Sarcose wrote: I don't remember if this method was floated around, but wouldn't it be trivial to, in your own game engine, define a separate movement type for cells with sloped tiles? As long as each tile entity has a straight line you can define
well, also u could add normals / vectors into the slopes. Have u read the Sonic slopes implementation?

a week ago I've moved from Bump to HC.
Now I can do this ^_-
Image
Our LÖVE Gamedev blog Zabuyaki (an open source retro beat 'em up game). Twitter: @Zabuyaki.
:joker: LÖVE & Lua Video Lessons in Russian / Видео уроки по LÖVE и Lua :joker:
Sarcose
Prole
Posts: 48
Joined: Wed Jul 08, 2015 12:09 am

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

Post by Sarcose »

Isn't Bump still basically the most gameist lib for collision though? That's why I'm interested in it. Especially for traditional sidescrolling platformers.

Haven't read the Sonic slopes implementation I don't think. If it's in this thread I might have missed it.
User avatar
Jasoco
Inner party member
Posts: 3727
Joined: Mon Jun 22, 2009 9:35 am
Location: Pennsylvania, USA
Contact:

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

Post by Jasoco »

D0NM wrote: a week ago I've moved from Bump to HC.
Now I can do this ^_-
Image
How easy is it to do resolution with HardonCollider? That's really what keeps me using Bump. It makes it dead simple. Does HC properly resolve collisions and return colliding objects to the proper location on the surface? Does it have the same methods like slide, bounce and cross?
User avatar
kikito
Inner party member
Posts: 3153
Joined: Sat Oct 03, 2009 5:22 pm
Location: Madrid, Spain
Contact:

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

Post by kikito »

Sarcose wrote:Been a while since I've read this thread. Was the slopes problem ever solved? I don't remember if this method was floated around, but wouldn't it be trivial to (...).
I consider this unresolved. The method you propose could work, but it seems quite ellaborate. I think it could be done more easily directly in bump. I just lack the time or motivation to do it, really. Let me go over the method I have in mind quickly.

Right now bump calculates the collision between two moving boxes by "compressing the one which is moving to a point", and making the other one bigger. This way, instead of a "moving-box-vs-box" problem, you have to resolve a "straight line vs box" problem, which is easier to solve (there is an algorithm for it). Once you have a solution for that, transforming things back is easy.
bump_1.png
bump_1.png (17.68 KiB) Viewed 7885 times
This "bigger box" is called the "Minkowsky difference". It is calculated by "moving" the green box around the perimeter of the red one.

With a ramp, things would be different: the Minkowsky difference would not be a box any more. It would be a box "with a missing corner":
bump_2.png
bump_2.png (23.49 KiB) Viewed 7885 times
Calculating the intersection between that and the line is not super complex. It is just ... tedious to write. There is no already-made algorithm for it, so it is a bit of a pain just to write it. Then there's the testing: there are lots of corners there, and there will be lots of comparisons on that algorithm. Put a < instead of a <= in one place and things will get stuck in corners. Or fall down the seams. Also, I would need to write it for 4 kinds of ramps (◢,◣,◤,◥).

But the most important hurdle is that I don't need it. Rectangles have been enough for me until now. So at least for now I am not writing it. I'll review and maybe accept pull requests if someone who needs it feels up to the task.
Sarcose wrote:kikito would you say bump could be used easily as a broad, first-pass engine in these special cases, then the dev can just add collision logic outside the project's scope?
That is definitively a good application.
D0NM wrote:a week ago I've moved from Bump to HC.
Now I can do this ^_-
That was a wise decision. Even if bump already had support for ramps as specified above, it would not support doing what you are doing on that image (the rectangle would have to be composed of several small ramps, and would not be able to "push other things by itself", you'd have to program that).
When I write def I mean function.
Sarcose
Prole
Posts: 48
Joined: Wed Jul 08, 2015 12:09 am

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

Post by Sarcose »

I will probably just standardize my ramps to two different angles and use foreground tiles to make the world look more organic (Metroid: Zero Mission does this). With first-pass in a tiled map, you can collide with the sloped tile as if it were a rectangle and have the slope's filter response finish the entity on top of it, no? Anything trickier and you might as well be using a different lib to begin with, I think.
User avatar
kikito
Inner party member
Posts: 3153
Joined: Sat Oct 03, 2009 5:22 pm
Location: Madrid, Spain
Contact:

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

Post by kikito »

Sarcose wrote:I will probably just standardize my ramps to two different angles and use foreground tiles to make the world look more organic (Metroid: Zero Mission does this). With first-pass in a tiled map, you can collide with the sloped tile as if it were a rectangle and have the slope's filter response finish the entity on top of it, no? Anything trickier and you might as well be using a different lib to begin with, I think.
Ok, good luck and let us know how it goes!
When I write def I mean function.
User avatar
D0NM
Party member
Posts: 250
Joined: Mon Feb 08, 2016 10:35 am
Location: Zabuyaki
Contact:

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

Post by D0NM »

kikito wrote:Ok, good luck
Your BUMP lib was the key to the instant implementation of the collision detection of our project. :ultrahappy:
W/o it I would lost a lot of time.
Also... HC is not as straightforward as Bump. :o:

PS Many thanks for your middleclass. :awesome:
Last edited by D0NM on Tue Nov 22, 2016 7:12 am, edited 2 times in total.
Our LÖVE Gamedev blog Zabuyaki (an open source retro beat 'em up game). Twitter: @Zabuyaki.
:joker: LÖVE & Lua Video Lessons in Russian / Видео уроки по LÖVE и Lua :joker:
User avatar
D0NM
Party member
Posts: 250
Joined: Mon Feb 08, 2016 10:35 am
Location: Zabuyaki
Contact:

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

Post by D0NM »

Jasoco wrote:
D0NM wrote:a week ago I've moved from Bump to HC.
How easy is it to do resolution with HardonCollider? That's really what keeps me using Bump. It makes it dead simple. Does HC properly resolve collisions and return colliding objects to the proper location on the surface? Does it have the same methods like slide, bounce and cross?
It doesn't have any BUMP's methods like slide, bounce and cross.
It detects a collision and returns a vector in the opposite direction of your movement.
So, now u have adjust your coordinates manually to not stuck in the collided object (or to slide, or to pass trough). In our game I used only BUMP's SLIDE method.

HC:

Code: Select all

self.shape:moveTo(self.x + stepx, self.y + stepy)
	for other, separating_vector in pairs(stage.world:collisions(self.shape)) do
		local o = other.obj
		if o.type == "wall"
		or (o.type == "obstacle" and o.z <= 0 and o.hp > 0)
        then
			self.shape:move(separating_vector.x, separating_vector.y)
			--other:move( separating_vector.x/2,  separating_vector.y/2)
		end
	end
	local self.x ,self.y = self.shape:center()
1) move your shape
2) check for collisions
3) if obstacle then move your object back
self.shape:move(separating_vector.x, separating_vector.y)
separating_vector has exact values to push your stuck object back into the freedom ))
Also u see a commented line:
--other:move( separating_vector.x/2, separating_vector.y/2)
If you uncomment it, then it'll push the other object, too. To the opposite direction.
You can add multipliers to adjust the bump distance.
4) get the final coords of the shape (it returns only the coords of the centre of the shape)

there MOVETO(to certain coords x,y) and MOVE(by xstep, by ystep)

The main hint is to WRAP collision detection with your methods.
Then it'll be easier to switch collision detectors.


PS HC is not faster than BUMP. It eats 40% of my CPU time, too )) According to the profiler.
Also... with HC I could drop iteration for faster detection in some cases.
And the most bad thing of HC that you cannot check collision of a virtual shape and other shapes.
You should always create a shape(to put it in the pool) then check for collisions.
After that don't forget to delete the temp shape.
Sometimes I just move my character shape forth, do the detection and return it back. It prevents me from creating any temp shapes.

PPS With HC I got more errors when 1 object slips trough another....
So I had to double the width of the obstacles(walls) in the game.
Our LÖVE Gamedev blog Zabuyaki (an open source retro beat 'em up game). Twitter: @Zabuyaki.
:joker: LÖVE & Lua Video Lessons in Russian / Видео уроки по LÖVE и Lua :joker:
User avatar
megalukes
Citizen
Posts: 94
Joined: Fri Jun 27, 2014 11:29 pm
Location: Brazil

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

Post by megalukes »

I was struggling with collisions for a while (using HC and programming my own module), but this lib saved me from a lot of trouble I was going through. Thank you very much. :awesome:
Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests