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

[sam]

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.

Ah, interesting! I actually didn't know this was how people went about this sort of thing. I may try to implement something like this by using hump.camera/gamera by rotating/scaling the graphics in a certain way (perhaps just for tiles, leaving out things like player sprites and stuff). Thanks for the info!

[arampl]

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.

Ah, interesting! I actually didn't know this was how people went about this sort of thing. I may try to implement something like this by using hump.camera/gamera by rotating/scaling the graphics in a certain way (perhaps just for tiles, leaving out things like player sprites and stuff). Thanks for the info!

sam, I think you've misunderstood what kikito told you. He says "transformed into isometric" in a figurative sense. Did you notice quotes? You don't have to physically rotate / scale your graphics. Imagine how you'd usually store your level maps (even for isometric graphics):

1,1,0,0,0,1,
1,0,0,0,0,0,
0,0,0,0,0,0

- simple 2d matrix

and not like some diamond-shaped data.

In this case the same applies to physics. You calculate collisions with internal representation of your data, but draw all things normally how they were designed.

[Fenrir]

Hi kikito,

Thanks a lot for taking the time to have a look! It solves the problem on the test application, but unfortunately on the game context the issue is different now:



The red shapes are the bump colliders, and as soon as I touch the problematic wall I get teleported on top of it, I'll try to track it down to a simple test scenario and I'll let you know!

Cheers,

[kikito]

Damn, borders are difficult.

If it helps, I have tried this version with the bump.lua demo (the one with the jetpack and the enemies that throw grenades at you) and saw no "teleportation issues".

[Fenrir]

Ok I reproduced it in a simple scenario, but this time it's a bit more tricky (love attached):

Code: Select all

local bump = require "bump"

--
local world
local player = { name = "Player", x = -637.98029097876, y = 121.258009477, width = 45, height = 230 }
local wall = { name = "Top", x = -1231.0972683545, y = -4.7101051668953, width = 704.33784991272, height = 24.527806378436 }
local wall2 = { name = "Wall", x = -836.50049554579, y = 9.28935041878, width = 198.12839196213, height = 406.74931778108 }
local wall3 = { name = "Ground", x = -720.03530808969, y = 351.258009477, width = 825.61876233948, height = 147.22597405042 }
local step = 1

--
-- LOVE callbacks
--
function love.load(arg)
    world = bump.newWorld()
    world:add(player, player.x, player.y, player.width, player.height)
    world:add(wall, wall.x, wall.y, wall.width, wall.height)
    world:add(wall2, wall2.x, wall2.y, wall2.width, wall2.height)
    world:add(wall3, wall3.x, wall3.y, wall3.width, wall3.height)
end

function love.draw()
    love.graphics.translate(800, 200)
    love.graphics.scale(0.5, 0.5)
    love.graphics.setColor({ 0, 255, 0, 150 })
    love.graphics.rectangle("fill", player.x, player.y, player.width, player.height)
    love.graphics.setColor({ 255, 0, 0, 150 })
    love.graphics.rectangle("fill", wall.x, wall.y, wall.width, wall.height)
    love.graphics.rectangle("fill", wall2.x, wall2.y, wall2.width, wall2.height)
    love.graphics.rectangle("fill", wall3.x, wall3.y, wall3.width, wall3.height)
end

function love.update(dt)
end

function love.keypressed(key)
    if key == " " then
        if step == 1 then
            -- Move 1
            local actualX, actualY, cols, len = world:move(player, player.x - 10, player.y + 10)
            player.x = actualX
            player.y = actualY
            print("actualX="..actualX..", actualY="..actualY)
            print("colliding with:")
            for _, col in ipairs(cols) do
                print(col.other.name)
            end
            step = step + 1
        elseif step == 2 then
            -- Move 2
            local actualX, actualY, cols, len = world:move(player, player.x, player.y + 10)
            player.x = actualX
            player.y = actualY
            print("actualX="..actualX..", actualY="..actualY)
            print("colliding with:")
            for _, col in ipairs(cols) do
                print(col.other.name)
            end
            step = step + 1
        end
    end
end

So it occurs after 2 steps (press "space" on the test application to apply each step). At the first one, I try to move against the wall, bump returns me a correct position and I update the player with it, everything is normal. On the second step, I don't move on the x axis (I just collided a wall so my velocity is reseted to 0), I just make a gravity check that I'm actually always doing (I removed it on my first test scenario as the issue was occuring even without it, but this time it's required), and bump returns that it collides with the platform on top of me (and not the one I'm standing on) and moves me on top of it.

Is the issue coming from the fist collision check giving me a position which is still colliding with the wall? As for the second check I don't move on the x axis but I still collide with it, is it normal?

Cheers,

[arampl]

I remember similar situation where flooring coordinates were helpful.
Could you try change to:

Code: Select all

local actualX, actualY, cols, len = world:move(player, math.floor(player.x) - 10, math.floor(player.y) + 10)

and tell what happens then? (if non-integer coords is not urgent for you)

[Fenrir]

Yep it was the first thing I tried, flooring all coords seems to solve the intial issue (or at least it was more difficult to reproduce), but on my side it's a total mess to handle it and I gave up. Not being able to use non-integers values would be a major issue for me... :/

[kikito]

Ok, thanks again for producing a test case. I will do my best to solve this. Unfortunately, these things usually take time ... :/

[kikito]

@Fenrir: Please try again with the version in the attached one.

I had to retrace my steps and think of another way to solve your initial problem.

Both of the errors you got could be attributed to the use of floating point numbers in Lua. Because of them, there are very small imprecisions in calculations. Some values, instead of being zero (like they would be in the real world) end up being "a very small number, almost zero" (like 10^-14). I have added a bit of "wiggle room" (1^-10) to the calculation that failed for you in the first place, and that seems to fix both your examples, and the demos seem to work fine too.

Part of the problem was that the initial numbers chosen were not exactly represented in floating point. Out of curiosity: why are your platforms in coordinates like 638.37210358366 instead of 638 or 638.3 ? Do all those decimals have any other reason of being (besides finding problems in bump, that is )?

[Fenrir]

Hi kikito!

Thanks a lot, it's working great! I actually still had a minor issue, when colliding with my problematic wall, this time Bump does not make me traverse or teleport on it, but it moves me a bit before when correcting my position, so I have one or two frames where I don't collide anymore with the wall before colliding back on it. But a small check on my side solved the problem and I think it's a more than an acceptable behavior from Bump as long as the position it returns is not inside the wall or on top of it!

About the coordinates, well I'm actually using a selfmade editor to position everything:



And I don't round or floor any coordinates I receive from it when positioning using the mouse. But I actually tried to do it, but it raised other problems as we can push or drag crates, or animate platforms to make them follow a path, and as all movements on the game are intensively using Tween with quad or quart interpolations, it would require to round everything and it actually created other precision problems.

If I still come across this kind of problem I'll consider refactor everything to only use rounded coordinates but I definitely don't have time for it now.

And here is finally how this area is behaving without no more collisions problems: