I want to use bounding boxes for my collision detection in my game. And it seems pretty simple, but whilst theorizing this Bounding Boxes method, I realized that if I check collision against every bitmap in the map then the games FPS will slow down significantly. (Although that's just a guess.)

How would I only check bitmaps around the player?

I want to use bounding boxes for my collision detection in my game. And it seems pretty simple, but whilst theorizing this Bounding Boxes method, I realized that if I check collision against every bitmap in the map then the games FPS will slow down significantly. (Although that's just a guess.)

How would I only check bitmaps around the player?

How many bitmaps are on a map? My advice: try the brute-force simple method first, testing every bitmap against the player in one loop - you may be surprised by how many things you can do in a single frame without any noticeable slowdown.

If this doesn't work, then you can start optimizing (there are many optimizations, collision detection is a well studied and documented problem).

Uhhh, not sure. At first, the maps will be small.

A bedroom, living room, kitchen, basement.

But then they start to expand. A small island, underground caves, mountains, etc.

Most of the collision optimizations I'm familiar with limit the number of checks that need to be made - something you alluded to in your first post, only checking objects near the player. One way this can be done is to partition the game world into chunks. Then you just need to check those objects within the same "chunk" as the player. This can get complicated (especially for a beginner) however, and generally the better optimizations are more specific to the situation (how the game world and its objects are represented).

This is why my advice is to just use brute force, and see if it works well enough. If the game slows down too much, then you can start to think of ways to trim down the collision detection loop. Personally, I'm more often surprised, on modern hardware, at how well a brute force approach works than not. Unless you specifically want to learn such things, researching and implementing needless optimization techniques can be a major time sink.

Most of the collision optimizations I'm familiar with limit the number of checks that need to be made - something you alluded to in your first post, only checking objects near the player. One way this can be done is to partition the game world into chunks. Then you just need to check those objects within the same "chunk" as the player. This can get complicated (especially for a beginner) however, and generally the better optimizations are more specific to the situation (how the game world and its objects are represented).

This is why my advice is to just use brute force, and see if it works well enough. If the game slows down too much, then you can start to think of ways to trim down the collision detection loop. Personally, I'm more often surprised, on modern hardware, at how well a brute force approach works than not. Unless you specifically want to learn such things, researching and implementing needless optimization techniques can be a major time sink.

Well of course I'll use the brute force method first, but if it doesn't work then I don't want to waste time asking questions I'll ask the questions I might run into, so I know how to deal with the problems I may run into.


But you make a good point, most hardware can handle quite a bit. Somethin like 10,000 or so calculations / frame without much noticeable difference. Plus, the slower computers have users used to lag. So optimising it would only be beneficial to people who are used to heavy lag. Obviously though, I'd like a fully optimised game so as to make the people whom usually have low FPS be attracted to this game that finally runs smoothly.