Pacman - Collision problems with FlxTileMap

[Gold D]

Hello.

I'm making a Pacman simulation with Haxeflixel as a final college project, and I have a collision problem between Pacman and the the world.

Here is a repository for reference:
https://github.com/Raul-Ramos/Haxe-Pacman
You can see the problem in the "problemaBordeIzquierdo" branch.

The world is made with Ogmo and imported using the utility Ogmo, then kept as a FlxTileMap for collisions. Every tile is 50x50.

If you look at the sides of the screen you will see a path that goes "outside of the game". They're connected, so if you go to the right, when you get one tile outside of the tilemap ( (width_in_tiles + 1 )*50 ), pacman changes his x to -50 and reappears from the left. It goes smoothly.

However, when I try the same thing with the left path, Pacman stops at the extreme (like you can see in the image), as if it collided with an non-existent wall.
When I debbuged, I saw that there was a FlxTile just in front of Pacman, blocking his movement. The fun part is that it wasn't always there: When I checked the _tileObjects variable in the FlxTileMap, I noticed that none of the members were in that position prior to the collision, it was moved during it.

The problem is in this line in FlxG
var result:Bool = quadTree.execute();
The quadtree moves the FlxTile 14 of _tileObjects just in front of Pacman - independently of his Y value - for no reason.

I suspect that it might be because Pacman's X gets lesser than 0 for a moment, and it somehow messes with the quadtree function. But then again, if you go to the right, Pacman will come from the left without colliding with anything.

I have made a temporal solution, but I will like to know if there is any know way around this problem.

Thank You.

[Kyatt]

Working on a game myself that loops around like that, this was the bane of my existence for weeks. Turns out that the way HaxeFlixel handles tilemaps, if you reach the end of one from the left, you'll collide with whatever the right-most tile is from the above row.

Anyway, this can all be circumvented by making the map one tile wider in each direction and then shifting the map's position one tile to the left (in your case, "map.x -= 50;"). That way, you never touch the actual end of the map.

[Gold D]

Woah that's some answer. I figured a way to make it more or less functional, but I will use this solution if I have time to implement it.

Thank you so much!