LÖVE

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?

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 ^_-

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.

D0NM wrote: a week ago I've moved from Bump to HC.
Now I can do this ^_-

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?

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.
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":
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).

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.

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!

kikito wrote:Ok, good luck

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

PS Many thanks for your middleclass.

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: 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.

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.