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

[kikito]

To solve it I just let the resolveCollision method return the new x and y position and I use them as newx and newy instead of wx, wy. It works but I hate the way it is done... I would love to hear some better ideas from you guys..

Well the only thing I can say is that the code seems a bit "involved" - there's lots of indirection - and maybe that's on me because there's certainly a bit of indirection in the bump demo as well. But you are adding lots of extra conditionals that make the code difficult to read, without adding much value. That makes finding bugs like this difficult.

Here's an example:

Code: Select all

if self.collidable then newx, newy = self:processCollisions(newx, newy) end

My suggestion would be adding a processCollisions method to Object, which by default would do nothing:

Code: Select all

function Object:processCollisions(x,y)
  return x,y
end

That way you can remove that previous conditional and just do:

Code: Select all

newx, newy = self:processCollisions(newx, newy)

Another one:

Code: Select all

if len > 0 then
  for i=1, #cols do ...
else
   self.onGround = false
end

The whole point of that conditional is setting the onGround variable when the length is 0. So do that directly instead, and avoid the extra conditional:

Code: Select all

self.onGround = len > 0

Finally, this one:

Code: Select all

local other = cols[i].other
if self.resolveCollision and other.collidable then
  self:resolveCollision(other)
end

You can add an empty resolveCollision to Object. And the collidable should be checked on the filter instead of afterwards. This will allow you to remove the if, and will be faster, since some collisions will be skipped and won't need to be calculated. And since you only have one instance of other now, you can use it directly. So those 4 lines could become just one:

Code: Select all

self:resolveCollision(cols[i].other)

In addition to this, once a teleport is detected you probably want to skip the rest of the collisions anyway. So one possible option is changing self.resolveCollision to "immediately return" when there has been a teleport. So if you make resolveCollisions return x and y only when there has been a teleport, you can exit the processCollision function right there. Here's the code after all the changes:

Code: Select all

Object:processCollisions(goalx, goaly)
  local wx, wy, cols, len = self.collisionWorld:move(self, goalx, goaly, self.filter)
  self.onGround = self.len > 0

  for i=1, #cols do
    local rx,ry = self.resolveCollision(cols[i].other)
    if rx then return rx, ry end
  end

  return wx, wy
end

I've always had problems teleporting a Bump object so I just remove the object before changing the coordinates then recreate it when it gets to the new location.

A couple things: first, world:move uses world:update internally, so even if you only use move, you are still using update anyway. Second, what update does is equivalent to removing the object and recreating it. It just optimizes the case in which the object has not moved at all, or has moved so little that it is in the same cell group. So even if what you do works, it's bound to be a bit slower than using update. But whatever floats your boat

[MadByte]

thanks for your help, I appreciate it.

Code: Select all

self.onGround = len > 0

Im now working so long with löve but I still wasnt aware that this is a thing I could do. Shame on me and my if else constructs.

[kikito]

thanks for your help, I appreciate it.

You were a bit lucky Lots of other things fight for my limited free time, and reviewing other peoples's code takes a lot of it, so I can't do it often. But I know it helps individuals. And those ifs really jumped at me.

Just so you know, this technique of "removing conditionals and just calling object methods" has a name: "Tell, don't ask", in case you want to expand your knowledge on it.

Shame on me and my if else constructs.

No shame! No one is born knowing everything. I also had to learn all this, and there's still a bunch of stuff I don't know.

[BörnedByLOVE]

Hi kikito, hi everybody!
I found out about LÖVE this summer and worked through Sheepolutions excellent tutorials, which I highly recommend as a starting point in Lua/LÖVE. (There is one about collisions which was a real eye-opener for me. )
I had some basic experience in scripting coming from python, putting together some textbased scripts for personal use. That helped and I had the feeling that I made faster progress in Lua/LÖVE in weeks and months than in Python/Pygame in years.

Then I felt ready for new adventures, and here I am willing to learn the usage of bump.lua.
(Necessary introduction, because after working through this thread I feel like the dumbest person here so far. So, run for the hills, dummy alarm!)

But anyway: After reading a lot and tinkering a lot I was able to copy and paste and write together my first working little bump-snippet!
(Two rects, one moves with arrow keys, one moves with WASD, and both can collide.)
There it is, at the bottom of the post, perhaps some starters like me will find it useful.

So, the basic usage of bump.lua (as I understand it so far):
-----------------------------------------------------------------------------
Step 1: At the beginning of your script, require the library.
Step 2: In love.load(): Build a bump-world
Step 3: In love.load(): Build some objects and add them to the bump-world.
Step 4: In love.update(): Use the built-in methods, especially move.
----- >a) Write your code as if you would move stuff conventionally.
----- >b) Give those x- and y-variables to bump.lua.
----- >c) Get them back from bump.lua.
----- >d) Use them in your code.
Step 5: In love.draw(): Draw your stuff.

If you get all this working, in case of a collision, bump.lua gives you the Slide response for free!
You can build some environment for your player, it doesnt float throught foggy limbo anymore, but hits walls and ground. Great, if you get this working for the first time! (Like me.)
So far so good... Problems start in the next post.

[BörnedByLOVE]

As a next step I wanted to build three snippets as basic examples for the other three types of collision response:
cross, touch, bounce. - I started with touch.

The idea was: You have a yellow arrow coming in from the left, hitting a blue wall on the right.
(Does it get stuck? Or can you move it afterwards? I found no answer in the docs, but I wanted to try out.)

But soon I had to give up and here I am. At the bottom, there is the code so far.

Although I studied the docs on github and this forum thread, I do not fully understand the filter function and how to handle it.

• How do I construct the filter function so that it produces a collision table? (Sorry, the explanation in the docs is to abstract for me...)

• How do I extract the touch (or cross or bump) "identity" of the collision object from the cols table?

Code: Select all

if other == walls

Does not work, because other is no string.

Code: Select all

A.isWall = true -- inside of the A-table 

Does not work either.

I know: I have to sharpen my Lua-skills. I need more coding experience. But it would be so nice to know now, anyway!
Help appreciated! (As Number 5 said: INPUT! I need INPUT!")

[AntixDevelopment]

Hi kikito, love your bump library but I'm having a wee issue when it comes to using queryPoint(). I have made the following code..

Code: Select all

local bump = require('bump').newWorld(128)

bump:add({gid = 1}, 0, 256, 128, 128)
bump:add({gid = 2}, 128, 256, 128, 128)

local x, y = 0, 257

for k = 1, 16 do
  local items, len = bump:queryPoint(x, y)
  if len > 0 then
    for i = 1, len do
      local other = items[i]
      print('queryPoint found tile with gid ' .. other.gid .. ' at ' .. x .. ',' .. y)
    end
  else
    print('queryPoint found no tile at ' .. x .. ',' .. y)
  end
  x = x + 16
end

When I run the code above I get the following results..

queryPoint found no tile at 0,257
queryPoint found tile with gid 1 at 16,257
queryPoint found tile with gid 1 at 32,257
queryPoint found tile with gid 1 at 48,257
queryPoint found tile with gid 1 at 64,257
queryPoint found tile with gid 1 at 80,257
queryPoint found tile with gid 1 at 96,257
queryPoint found tile with gid 1 at 112,257
queryPoint found no tile at 128,257
queryPoint found tile with gid 2 at 144,257
queryPoint found tile with gid 2 at 160,257
queryPoint found tile with gid 2 at 176,257
queryPoint found tile with gid 2 at 192,257
queryPoint found tile with gid 2 at 208,257
queryPoint found tile with gid 2 at 224,257
queryPoint found tile with gid 2 at 240,257

So why does queryPoint() not find anything at pixel 0 and pixel 128, when there are clearly defined collision rectangles at those positions and the queryPoint() coordinates are also clearly inside those collision rectangles?

Am I doing something stupid (most likely)?

I should mention that I'm using Gideros, not Love2d but that shouldn't make a difference should it?

[kikito]

I honestly lack the time to investigate this in depth. My recommendation would be to avoid this kind of tests on tile borders (or not do it and expect it to always work). Borders and corners are ... temperamental, especially when coupled with floating point numbers.

If you find a way to make it work without breaking the rest of the library, feel free to send a PR

[AntixDevelopment]

Darn, oh well. My current solution is to use queryRect on the area around the players feet, then use a simple pointInRect check to determine the actual tile the player is inside. From there I just use my slope code and it all seems to work..

https://youtu.be/Ca7IU6CBxCA

Maybe I'll have a look at bump and see if I can't figure it out but for now I've got a solution that functions