Return to Answer

You are checking each object against each collision tile and each enemy, even when those are too far away to have a chance to affect it. That's inefficient, because the computational cost increases quadratical with the amount of objects. Divide your map into zones and keep track of which zones each mobile object touches. Then only check for collisions inside each zone.

Keeping track of which zones each object touches can be done whenever that object is moved. Compare its old coordinates with the new ones to find out from which zones the object needs to be removed and to which zones the object is added. Each map zone would have a HashSet<MobileObject> representing its current inhabitants. Note that when an object is on the border of two zones, it can be in multiple zones at the same time.

When you check for collisions, you only check for collision of objects and tiles which are in the same zone (you might have to check adjacent zones too, when objects are large enought to span multiple zones).

I also assume (but might assume wrong), that you have a lot more collision tiles than mobile objects. When that assumption is right, most zones will always contain collision tiles, but will often not contain any mobile objects. In that case it would be better to iterate all objects and check them against the tiles in their zone instead of the other way like you are doing right now (iterate tiles and check them against mobile objects). When you only check for collisions with the player and have no collisions between other entities, you only need to check the zones touched by the player-object.

Regarding how to define zones: The most straight-forward way would be to use square-shaped zones of uniform size. This has the advantage that finding out the zone a point is in is trivial: Put the zones in a two-dimensional array. To get the array-indexes of the zone a point is in, just divide the x- and y-coordinate of the point by the zone-size and you have them.

The ideal zone-size depends on your object-density and object-mobility. You will need to find a compromise between keeping the zones small enough so their population is small and large enough to avoid too frequent zone-changes.

When you have areas which are always much more densely-populated than others, it might make sense to divide these areas into smaller zones.

You are checking each object against each collision tile, even when those are too far away to have a chance to affect it. That's inefficient, because the computational cost increases quadratical with the amount of objects. Divide your map into zones and keep track of which zones each mobile object touches. Then only check for collisions inside each zone.

Keeping track of which zones each object touches can be done whenever that object is moved. Compare its old coordinates with the new ones to find out from which zones the object needs to be removed and to which zones the object is added. Each map zone would have a HashSet<MobileObject> representing its current inhabitants. Note that when an object is on the border of two zones, it can be in multiple zones at the same time.

When you check for collisions, you only check for collision of objects and tiles which are in the same zone (you might have to check adjacent zones too, when objects are large enought to span multiple zones).

I also assume (but might assume wrong), that you have a lot more collision tiles than mobile objects. When that assumption is right, most zones will always contain collision tiles, but will often not contain any mobile objects. In that case it would be better to iterate all objects and check them against the tiles in their zone instead of the other way like you are doing right now (iterate tiles and check them against mobile objects).

Regarding how to define zones: The most straight-forward way would be to use square-shaped zones of uniform size. This has the advantage that finding out the zone a point is in is trivial: Put the zones in a two-dimensional array. To get the array-indexes of the zone a point is in, just divide the x- and y-coordinate of the point by the zone-size and you have them.

The ideal zone-size depends on your object-density and object-mobility. You will need to find a compromise between keeping the zones small enough so their population is small and large enough to avoid too frequent zone-changes.

When you have areas which are always much more densely-populated than others, it might make sense to divide these areas into smaller zones.

You are checking each object against each collision tile and each enemy, even when those are too far away to have a chance to affect it. That's inefficient, because the computational cost increases quadratical with the amount of objects. Divide your map into zones and keep track of which zones each mobile object touches. Then only check for collisions inside each zone.

Keeping track of which zones each object touches can be done whenever that object is moved. Compare its old coordinates with the new ones to find out from which zones the object needs to be removed and to which zones the object is added. Each map zone would have a HashSet<MobileObject> representing its current inhabitants. Note that when an object is on the border of two zones, it can be in multiple zones at the same time.

When you check for collisions, you only check for collision of objects and tiles which are in the same zone (you might have to check adjacent zones too, when objects are large enought to span multiple zones).

I also assume (but might assume wrong), that you have a lot more collision tiles than mobile objects. When that assumption is right, most zones will always contain collision tiles, but will often not contain any mobile objects. In that case it would be better to iterate all objects and check them against the tiles in their zone instead of the other way like you are doing right now (iterate tiles and check them against mobile objects). When you only check for collisions with the player and have no collisions between other entities, you only need to check the zones touched by the player-object.

You are checking each object against each collision tile and each enemy, even when those are too far away to have a chance to affect it. That's inefficient, because the computational cost increases quadratical with the amount of objects. Divide your map into zones and keep track of which zones each mobile object touches. Then only check for collisions inside each zone.

Keeping track of which zones each object touches can be done whenever that object is moved. Compare its old coordinates with the new ones to find out from which zones the object needs to be removed and to which zones the object is added. Each map zone would have a HashSet<MobileObject> representing its current inhabitants. Note that when an object is on the border of two zones, it can be in multiple zones at the same time.

When you check for collisions, you only check for collision of objects and tiles which are in the same zone (you might have to check adjacent zones too, when objects are large enought to span multiple zones).

I also assume (but might assume wrong), that you have a lot more collision tiles than mobile objects. When that assumption is right, most zones will always contain collision tiles, but will often not contain any mobile objects. In that case it would be better to iterate all objects and check them against the tiles in their zone instead of the other way like you are doing right now (iterate tiles and check them against mobile objects). When you only check for collisions with the player and have no collisions between other entities, you only need to check the zones touched by the player-object.

Regarding how to define zones: The most straight-forward way would be to use square-shaped zones of uniform size. This has the advantage that finding out the zone a point is in is trivial: Put the zones in a two-dimensional array. To get the array-indexes of the zone a point is in, just divide the x- and y-coordinate of the point by the zone-size and you have them.

The ideal zone-size depends on your object-density and object-mobility. You will need to find a compromise between keeping the zones small enough so their population is small and large enough to avoid too frequent zone-changes.

When you have areas which are always much more densely-populated than others, it might make sense to divide these areas into smaller zones.

You are checking each object against each collision tile, even when those tiles are too far away to have a chance to affect it. That's inefficient. Divide your map into zones and keep track of which zones each mobile object touches. You can do so by checking the position before and after whenever you change the position of an object. Remove it from the object-set of any zones it doesn't touch anymore and add it to the object-set of all zones it now touches.

When you check for collisions, you only check for collision of objects and tiles which are in the same zone (you might have to check adjacent zones too, when objects are large enought to span multiple zones).

I also assume (but might assume wrong), that you have a lot more collision tiles than mobile objects. When that assumption is right, most zones will always contain collision tiles, but will often not contain any mobile objects. In that case it would be better to iterate all objects and check them against the tiles in their zone instead of the other way like you are doing right now (iterate tiles and check them against mobile objects).

You are checking each object against each collision tile and each enemy, even when those are too far away to have a chance to affect it. That's inefficient, because the computational cost increases quadratical with the amount of objects. Divide your map into zones and keep track of which zones each mobile object touches. Then only check for collisions inside each zone.

Keeping track of which zones each object touches can be done whenever that object is moved. Compare its old coordinates with the new ones to find out from which zones the object needs to be removed and to which zones the object is added. Each map zone would have a HashSet<MobileObject> representing its current inhabitants. Note that when an object is on the border of two zones, it can be in multiple zones at the same time.

When you check for collisions, you only check for collision of objects and tiles which are in the same zone (you might have to check adjacent zones too, when objects are large enought to span multiple zones).

I also assume (but might assume wrong), that you have a lot more collision tiles than mobile objects. When that assumption is right, most zones will always contain collision tiles, but will often not contain any mobile objects. In that case it would be better to iterate all objects and check them against the tiles in their zone instead of the other way like you are doing right now (iterate tiles and check them against mobile objects). When you only check for collisions with the player and have no collisions between other entities, you only need to check the zones touched by the player-object.