Why player can’t pass in some places? It’s the same floor tile across the screen.
I believe you are hitting the “stitching” in between sections of tiles. My recommendation is to change to a sphere (or multiple smaller spheres) instead of a box for the player.
Sphere works fine, thanks. But since tiles are aligned properly to the grid why is it happening? I noticed I can ‘force pass’ as speed increases.
I believe the gotchas in this thread are still relevant: Directional platforms help - #30 by totebo
4 Likes
Oh, yeah, I had forgotten about that post by Ross!
1 Like
This is mad. I just jumped
2 Likes
How are you separating the shapes on collisions?
What do you mean?
The player is standing on block made of 2x2 tiles. Stitching again?!
Is the player collision dynamic or kinematic?
What does the code look like that handles the collision? Or are you using a dynamic collision object?
Have you seen the platformer sample project?
Kinematic as stated in thread title. Static objects use tile based collision shapes.
(I’m ditching Gamemaker, testing alternative engines).
I used this code:
https://defold.com/tutorials/platformer/
Ok, have you changed the collision response code?
The collision normals looks like it’s pointing straight up, so I’m not sure how the platformer code would move the object sideways.
Usually, you’d check if the slope of the ground is pointing “up” (within a certain range), and act accordingly.
If on a slope, it’s often common to project the incoming velocity onto the vector perpendicular to the normal, so that the object may slide sideways.
It looks a bit like that’s the case here.
I didn’t change the code (apart from variables)
If you could zip up the test project and share it here (don’t include the ./build and the .git folders) and we can take a look.
Thanks! First of all I’d simplify the handle_obstacle_contact() function and not mess with the velocity in the way it was done before. I would also ignore collisions with a negative distance. Updated function:
local function handle_obstacle_contact(self, normal, distance)
if distance > 0 then
-- project the correction vector onto the contact normal
-- (the correction vector is the 0-vector for the first contact point)
local proj = vmath.dot(self.correction, normal)
-- calculate the compensation we need to make for this contact point
local comp = (distance - proj) * normal
-- add it to the correction vector
self.correction = self.correction + comp
-- apply the compensation to the player character
go.set_position(go.get_position() + comp)
end
-- check if the normal points enough up to consider the player standing on the ground
-- (0.7 is roughly equal to 45 degrees deviation from pure vertical direction)
if normal.y > 0.7 then
self.ground_contact = true
self.velocity.y = 0
end
end
Another improvement you could do to avoid some stitching is in the tilesource itself. The tiles look great, but they have a lot of small areas with transparency which becomes very visible when physics debugging is enabled:
You can do this by using another image for the collision where you tidy up these small gaps. Here’s a modified collision map for your tileset:
It will turn the tilesource from this:
To this:
And the result in-game:
Updated project:
Archive.zip (36.3 KB)
4 Likes
Thanks for clearing this out. I noticed someone else on this forum reported today similar issue.
However it’s visible only on the bottom row of tiles, the ones player don’t interact with.
I need Photoshop tutorial then!
1 Like
That was the culprit! No need for changing player’s collision shape or making collision map for tileset.
1 Like