This is my first attempt at collision detection and I'm going to use bounding box / rectangle collision detection, do I need to check with all the objects on the map? If I have 100 different platforms, boxes and other stuff do I need to check with all of them if they collide with the player? This seems really tedious and inefficient..

I also have a problem with the keyboard input / events in my game, when I press left / right arrow key then press the up arrow key to jump while holding left / right it stops moving to the left / right.

What I thought would happen, if this is the event queue: right, right, right, up, right, right, right, etc etc.

What actually happens: Right, right, right, up then it stops.

Sorry if my explaining is a bit confusing. Here's some code.

Player.cpp Move function.

The jumping function only sets the vel_Y to -20 and sets jumping = true

My game loop.

my Game.update

Right now it's only a "P" being drawn on a black background, I'm trying to perfect character movement before I add platforms, images, sound etc

oh and, whats the difference between Player::vel_X and just typing vel_X in player.cpp?
Edit: nevermind, there is no difference between Player::vel_X and typing vel_X, it's a matter of style for anyone else who might be wondering the same thing

If this is your first attempt at collision detection, I'd say you have a long way to go before you get to the point where optimizing bounding box checks becomes a real concern. Concentrate on getting something that feels like a game done, then optimize, if needed. It's easy to get carried away trying to figure out how to speed things up with space partitioning.

Well, since I've already mentioned it, the general idea is to divide the space into simple, non-intersecting regions, figure a fast algorithm to find out which region an object is inside, then check for collisions only between objects that are in the same region. The most common method for a 2D game is probably a simple grid of squares. You can try quad trees if you want to get fancy, but it's almost always overkill.

I see, so checking for collision with all the objects in a level isn't something that will slow down the game? Even if there are hundreds or perhaps thousands of objects?

Thanks Only need to workout the keyboard problem now.

A fast and easy way to improve collision detection(if it's slow) is to check for bounding circles first, and then for bounding boxes. That way your algorithm will only check for boxes if the sprites are close enough to do so.
Comparing the squared distances of the sprites centre's is the fastest way to do it.

in pseudo-code(actually, I guess this works fine in C):

Could anyone confirm this is a good practice? I sometimes do it this way and it works most time.(guess I turned my answer to a question, )

You might be better off doing something like:

I think an angled line could cut corners if you have oddly shaped sprites.

max(sprite->w,sprite->h);

Hundreds? Nope. Thousands? Probably not enough to slow down a modern PC, but if you manage to get into that range, it will probably become worthwhile to free up some CPU cycles for the other tasks needed to handle thousands of objects. Note that when you say thousands of objects, I assume that each one of them may collide with any other. That's not usually the case. Either way, my point is that you shouldn't worry about this yet, whether it will become a problem in the future or not. Focus on the fun part of making an actual game. Optimizations are a huge time sink and it's quite demotivating when you realize you've spent two weeks trying to implement quad trees but don't have anything that even remotely resembles a game yet.

Depends on the type of bounding boxes. If they're axis-aligned, it's a waste of time, since a method to check wether they intersect should look roughly like this:

    if(min.x > other.max.x || min.y > other.max.y || other.min.x > max.x || other.min.y > max.y) return false;
    else return true;

If they're allowed to rotate, well, that's another story, but I think the OP doesn't really care for rotating bounding boxes yet.

Thanks for all the help, I think rotating bounding boxes and quad trees are beyond me right now, so I'll save that for later!

Uhm.. about the problem I have with key events. Do all keyboards stop repeating the keystroke when another key was pressed? I'm currently trying to figure out how to keep sending keystrokes of the last button pressed excluding the jump button. If someone has a fix for my problem then please post

well,
doesn't really solve your problem, but I have a question:
why

and not

?

EDIT: Added "p->jumping" into the condition, so it only happens during jump.

Because I'm stupid sometimes edited the code to match yours.

I have a bad habit of creating more if statements than needed, at that point I was trying to figure out why the velocity would sometimes continue to increase even though it hit 400. Then I realized it was because it never actually hit 400 but went past it so I made another if statement for when that happens.

Also, I found a workaround for the keyboard / key event problem I had.

For anyone who stumbles into the same problem, here's how I fixed it

player.cpp

What I did was I added
bool keyDown;
ALLEGRO_EVENT lastEvent;
in the Player.h

And stored the last keyboard keycode in lastEvent.

There is most likely a better way to do it