0
\$\begingroup\$

So I'm working with a player moving across a grid of isometric tiles. Each tile is stored in a .png file. I have a class that crops out BufferedImages from different sprite sheets and initializes them for use in my game. When I crop out a tile image, the image is cropped out like this (minus the black border):

enter image description here

Because the four corners of this rectangle are transparent, I'm able to tessellate the tiles perfectly. I'm now trying to implement collision detection and having a tough time. The player moves by following the mouse around. In the player's tick/update method, I am checking to see if his new position will be in a tile marked as being solid. If the tile is solid, I don't update his position so that movement doesn't occur. My problem is that when I check to see if the player is moving into a solid tile, I'm checking the entire .png image, including the transparent corners.

So, if I'm moving towards these 'stone' tiles and I mark them as being solid, the player isn't colliding with the tiles in a natural way.

enter image description here

In the image you see here, I've updated these stone tiles with a black border showing the edge of the BufferedImage, and I've updated my player with a red rectangle indicating his bounding box. I've marked these tiles as solid. As I approach the tiles from the left moving right, I collide with these black lines rather than the colored portion of the tile. Actually, sometimes I collide with nothing to the left of the tile, like in this image (I'm sure that's just my math somewhere.)

I considered trying to attach a Polygon object to each solid tile that covers only the visible pixels of each .png file and doing collision against the polygon instead of the whole tile. I'm currently trying to implement this and having troubles.

My question here then is, how would you implement collision detection in this scenario? Would you draw polygons in the shape of the visible portion of each BufferedImage and do collision against these polygons like this? Is there a change that I can make or a technique I can use to implement smooth collision detection? Should I use a polygon object to crop my tiles in the first place? I'm looking for the simplest way to go about this.

\$\endgroup\$
4
  • \$\begingroup\$ Do you want to know when the player's feet are in the tile? \$\endgroup\$
    – clabe45
    Commented Aug 5, 2017 at 22:44
  • \$\begingroup\$ When the player is moving right on the x axis I'm checking the two right corners of the bounding box (the red box) and when the player is moving left on the x axis I'm checking the two left corners. Two top corners for moving up, and two bottom corners for moving down. So, depending on the direction my player is moving, I'm checking certain corners of his bounding box. \$\endgroup\$ Commented Aug 5, 2017 at 23:28
  • \$\begingroup\$ I can move my bounding box down to around his feet if that would make collision feel more natural. However, that wouldn't address this issue. \$\endgroup\$ Commented Aug 5, 2017 at 23:29
  • \$\begingroup\$ Check out this answer \$\endgroup\$
    – clabe45
    Commented Aug 6, 2017 at 0:29

1 Answer 1

-1
\$\begingroup\$

In my opinion, the best way to do this would be "convert" map into simple 2D topdown plane, then check the collision with more simple figure.

So you've got Screen World, which is drawn with tiles and stuff, but also your world's Computer Representation, just a 2D grid\matrix\array or anything. You can easily find different approaches of translating world coordinates into screen coordinates and vice-versa.

Use plain 2D world for collsion and use isometric tiles for drawing the world onto the screen.

\$\endgroup\$
4
  • \$\begingroup\$ So, say I have all of the cartesian coordinates of my tiles and I'm just rendering them at isometric positions. My isometric tiles are 128x64 in size, which corresponds to a 64×64 cartesian tile. Does my logic need to assume a 64x64 tile then, and just render the isometric image at a converted isometric coordinate? \$\endgroup\$ Commented Aug 5, 2017 at 14:38
  • \$\begingroup\$ Because right now my 2D coordinates use the 128x64 for math even before converting to isometric. \$\endgroup\$ Commented Aug 5, 2017 at 14:39
  • \$\begingroup\$ @ChristianWestbrook I guess, you can go with any size, but since you have 64x64, it could be easier for you. You should also consider whether you'll be having additional parts "on" tiles, or all the tiles will be NxN \$\endgroup\$ Commented Aug 5, 2017 at 14:51
  • \$\begingroup\$ Your suggestion worked for me. \$\endgroup\$ Commented Oct 5, 2017 at 5:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .