Why no collision when fully inside tilemap? (DEF-2956) (SOLVED)

Questions
#1

Problem: No collision response or contact_point response are cast when fully inside a collisionshape created from tilemap.
Weird thing is that it works with all other shapes. So if you have 2 shapes colliding and 1 shape is fully emerged by the second one they are still triggering and giving away all data needed.
But with tilemaps they just stop and wont detect a collision at all.

Heres 3 shapes. One sphere, one box and one tilemap shape.
Collisions

I understand that some data must be harder to get (normal, distance etc) but couldnt we at least send a collision_response just showing that a collision occurred?

Usecase: I try to scan my map for good spawning points that doesn’t interfer with other stuff on map. Works fins with all small gameobjects having primitive shapes but it cannot even detect blocking walls etc made by tilemaps.

1 Like
Continuous Collision Detection (DEF-3115)
#2

I want to bump this as I once again stumbled upon a problem with this in our game.
It would be great to at least detect if within collisionshape (if giving normal and distance would be a trickier design issue). Anyone?

#3

I created ticket DEF-2956 for this so that we can prioritise it and get a fix out.

/Johan

4 Likes
#4

Awesome Johan. Thank you!

1 Like
#5

Hey.

I already noticed this issue while developing my coronadefoldjam game FoodRescue. Based on a tilemap I got exactly the same: If the Player runs too fast he runs “thru” the border of the tilemap. If so the Player easily moves “into” the walls. I had to reduce the movespeed to prevent this.

Fact is, the collision is just at the “borders”. Inside the shapes there are no collisions.

1 Like
#6

A temporary solution is to manually check the tilemap data if a cell is an obstacle or not - of course you know that but posting for others who may read until issue is fixed.

Another thing that may help is putting nesting gos with smaller and smaller collision shapes inside of your primary collision shape. I did this with a fast moving platformer character and it was more successful at detecting tilemap collision shape wall collisions at high speed without getting stuck inside of walls.

2 Likes
#7

Unfortunately the sample above is simplified. In my user case right now I use custom collision shapes on the tiles so they are not square.
The main reason I use tile maps right now is to diminish the performance hit that lots of game objects with collision shapes would probably generate. Also it will make it a lot easier for level designers to use rather than compose a nested GO structure.

But for other projects I agree that checking the cell data would be even more efficient.

#8

I’m running into the same problem. I have a maze tilemap and the player ends up inside the walls if speed is too high.

#9

My solution for this kind of problem was to cap the speed to exactly half the smallest size of my collision-spheres which always made it push out again instead of making to big of a jump into tilemap.

#10

I have speeds between 50 and 100 pixel/sec at the moment and it seems to work. If I go higher the problem starts surfacing. Smallest collision circle diameter is 8 pixel. If I understand you correctly this would translate to a speed cap of 4 pixel/frame or 4*60 = 240 pixel/sec. In my case that would definitely be too high.

Another observation: When I export the game to html5 and test that the effect is far worse, my objects enter the walls all the time even on low speed. I suspect that’s due to the overall slower speed of calculations in javascript, right?

#11

Lower framerate = longer distance travelled per frame = higher likelihood of full penetration

1 Like
#12

So, effectively this means no html5 for me, or does it?

#13

Have you done any profiling? Why aren’t you at 60 fps even on web? Are you running a release build?

#14

@fbrummer
If your maze is made up by square tiles in the tilemap (not using specific collisionshapes) there are better solutions for you to avoid getting stuck in walls (unless you’re using dynamic physics) with combinations of knowing what tile you are on, what kind of tiles are next to you and revert yourself to known positions of open area whenever you are in an invalid tile.

2 Likes
#15

@britzl: I’m running release build for html5 but it’s not my priority, because I want to run well on native and andrroid for now. Will have a look into profiling and report back. Btw: I’m using your orthogonal camera module. Very nice work, thank you!

@andreas.strangequest: You’re right. I’m already looking at the tiles around the player to infer where to turn to when colliding with walls. Just doing the separation with the code from the physics docs. I’ll try checking for valid tile on every update instead. Thank you for the suggestion.

2 Likes
#16

@britzl and @andreas.strangequest: I’ve changed my implementation according to your suggestions to no longer using physics to detect collisions with the walls. This change solved the problem with sprites entering the walls (I have one player sprite and 4 enemy sprites “running” around the labyrinth). As a nice bonus the html5 build now runs smooth with 60 fps. Very nice!

3 Likes
#17

Glad to hear! Lua is actually very fast and as most games requires only a fragment of physics that is delivered with libs like Box2D it can always be a good idea to see if it can be done in other ways.

Congrats

2 Likes
#18

Fixed in Defold 1.2.121

3 Likes