trjhtr

I have the following code that works just fine for collision detection. The only problem is its size and its performance. I'm trying to do it and many other things 60 times per second, which doesn't work out very well. Is there any way to condense it as it's much the same stuff over and over again?

for(int x=0; x<40; x++) 
 for(int y=0; y<28; y++) 
 if(tiles[x][y]==0) 
 if(keyManager.up) 
 Rectangle player = new Rectangle(you.getX(), you.getY()-1, 10, 10), tile = new Rectangle(x*25, y*25, 25, 25);
 if(player.intersects(tile)) 
 return;
 
 if(x==39 && y==27) 
 you.setY(you.getY()-1);
 
 if(keyManager.down) 
 Rectangle player = new Rectangle(you.getX(), you.getY()+1, 10, 10), tile = new Rectangle(x*25, y*25, 25, 25);
 if(player.intersects(tile)) 
 return;
 
 if(x==39 && y==27) 
 you.setY(you.getY()+1);
 
 if(keyManager.left) 
 Rectangle player = new Rectangle(you.getX()-1, you.getY(), 10, 10), tile = new Rectangle(x*25, y*25, 25, 25);
 if(player.intersects(tile)) 
 return;
 
 if(x==39 && y==27) 
 you.setX(you.getX()-1);
 
 if(keyManager.right) 
 Rectangle player = new Rectangle(you.getX()+1, you.getY(), 10, 10), tile = new Rectangle(x*25, y*25, 25, 25);
 if(player.intersects(tile)) 
 return;
 
 if(x==39 && y==27) 
 you.setX(you.getX()+1);
 
 
 
 

You are creating a new Player and Tile every time this code executes. That is likely your performance hit. Try moving the existing player rather than creating a new one in a new location.

Does performance slow down further the longer the game runs? This is because your objects are piling up.

For further reading I recommend looking at AABB Collision Detection and Quad Trees.

You seem to have a player that changes coordinates when keys are pressed and tiles that are stationary.

On each "tick" (~60/second), for each of the tiles (~1000) that is 0 (tiles[x][y]==0) you're creating a Player rectangle, a Tile rectangle and checking whether these intersect or not.

How many Player rectangles should in fact be created? Since the Player moves once per tick, you should have one Player rectangle created per tick.

How many tile rectangles should be created? On first glance, you could get away with creating all of the tile rectangles on game start (since they don't change position between ticks).
An even better approach is to not create any tile rectangles, but based on the position of the player determine which tiles he is intersecting.

Observation 1: since the tiles are well behaved - first tile on first row goes from 0 to 25, second tile from 25 to 50, etc, you can determine easily determine which tile a random point belongs to.

Observation 2: since the player is a square of side length 10 and the tiles are squares of side length 25 (bigger), the player can intersect at most 4 tiles - one per corner of the player.

Hopefully it's become obvious now that you can decide if the player intersects tiles of value 0 a lot easier:

1. Update player position


2. Compute corners of player square


3. Compute tiles mapping to those corners


4. Check if any of these 4 tiles have value 0

But what if my tiles/player are not squares, what if it's harder to compute the intersection between player and tiles?

Any shape can be inscribed in squares. You can use this algorithm to eliminate all of the tiles that are too far away from the player to intersect it and make a list of all the tiles that "could" intersect the player. Then you use your custom Tile.intersects(player) method on the reduced set of tiles to determine exactly which tiles intersect the player.

But what if my tiles are not tiles, they are objects scattered around a map?

You can divide your map into conveniently sized tiles and assign each of the (stationary) objects to the tiles they intersect - this is a one-time operation. Then you use the same algorithm described above to determine objects that possibly intersect the player (by eliminating all of those in the tiles the player doesn't belong to).