Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: AA unit square collisions with a grid of AA unit squares  (Read 285 times)

0 Members and 1 Guest are viewing this topic.


  • Newbie
  • *
  • Posts: 15
    • View Profile
AA unit square collisions with a grid of AA unit squares
« on: August 06, 2023, 01:15:17 am »
this seems really simple, and it probably is, but as a beginner with the c++ language and SFML, I'm having a hard time figuring this out.

I have a player, that is a square, one unit by one unit. I have a grid that is my map, that is a grid of squares, each one unit by one unit. The problem comes from the fact that I can't just check for collisions with every box in the map, as my map is 2000x900, and possibly larger. What I was doing was finding the block each vertex of my player was in, and checking if that block was empty or not. the problem with this method though was that there was glitchy behaviour, holding jump and to the right on a wall to the right of the player would result in the player getting stuck, while holding jump and left on a wall to the left would rocket the player upwards. in short, this method was inconsistent and ugly.

I'm wondering if there's any simpler methods? a pseudocode example or simple explanation would be best. the code is quite long, and creating a minimum example would still be large, but if you need the code I can send it.


  • Hero Member
  • *****
  • Posts: 3339
  • My number of posts is shown in hexadecimal.
    • View Profile
    • Links
Re: AA unit square collisions with a grid of AA unit squares
« Reply #1 on: August 06, 2023, 10:17:55 pm »
Your method seems to be sound for finding if there is a collision and with which tiles.

It's worth noting that when the tile and player line up perfectly, it might be unclear which tiles should be considered a collision.

Then, we come to what to do with the information once we have it, which is where I expect the 'glitchy' behaviour stems.
For example, if it's touching 4 tiles (each corner is in adjacent tiles), which seems the most likely scenario, then, at what point, do we consider it "touching" instead of "colliding/overlapping" the very next tile? This would be a design decision.
Although I'm not 100% sure what "holding jump and to the right on a wall to the right of the player" would look like exactly, remember that you "start to jump", you should no longer be able to jump until you land, and that landing should be sure in your design (just on a floor/something below it?). If you wanted to allow what I would call "sliding" (gripping a wall but maybe still falling - at a different rate to normal falling), you should track this as a different state to jumping. i.e. if it is sliding, it's isn't jumping.

I'm guessing this is a form of side-scrolling platformer so my presumptions are based that so if that's not the case, what I have said/am saying may not be correct.

You should consider the "state" (mentioned that briefly above) of the player. Things like isJumping, isSliding, isFalling, isRunning, isIdle are common things to track but you may was to consider using some form of state system (a finite state machine is a common example.
Here's a common explanation of the sort of thing if you don't know what I mean:
Selba Ward -SFML drawables
Cheese Map -Drawable Layered Tile Map
Kairos -Timing Library
 *Hapaxia Links*