if (ball.y > PADDLE_Y) ball.y_dir = -ball.y_dir;

I'm going to be frank: If you can't figure something like this out then you aren't anywhere near ready to code a game. I recommend reading through some game programming tutorials before you go any further with your project.

Oh that's easy to do, just program it so it bounces off the paddle.

Yeah sure, just make the ball bounce off the paddle and that'll work, ok?

Good.

yukcell, did you even read my response? I said you are NOT READY to work on this game of yours because you are asking questions that show you do not have the most basic skills necessary.

If you truly want to make this game, what you need to do is search for some online tutorials to learn the basics of game design and game programming. No one here is going to program your game for you; This forum is for sharing bits of code and asking why they're not working. If you have no code to show nor a specific coding problem to solve then we can't help you.

Same goes for Compile Error in the following post if he happens to also be you or is working on your team: http://www.allegro.cc/forums/thread/611316

Seem to be seeing this a lot lately on a lot of forums. People who have never coded a single application coming to sites wanting help to make Pong/Breakout. The one I still love to see is guys that are beginners at best claiming to be putting a team together to make a MMO-RPG/FPS/etc.

If he doesn't recognize that first line of code then (s)he should take a programming tutorial before even touching on game anything.

Programming is an art, game, application, or OS makes no difference. With the tools out there it really doesn't take that extreme skills to make a game. If you make a game maker game or torque engine game you are doing game programming using a scripted language that is designed to make game programming easier. Truth is that everyone uses libraries and APIs to make games and rarely make everything from scratch. Even allegro at times seems like it is just a wrapper for multiple cross platform APIs (libpng, libogg, physfs, etc). Game programming is hard if you are wanting to learn C/C++/C#/Java/D etc, but in the same breath it is easy too due to all the tools companies have brought out for allowing those interested in game design to make a functioning game with little effort.

I'd say that when you get the OpenGL and the audio working, you're 25% done with a game. OTOH, if by "OpenGL working" you mean you've already finished level design, you might be 50% - 60% done.

Well, since allegro is basically a wrapper with some extras, it doesn't have much to do with game programming itself.

The difference between game programming and generic programming is that in generic programming stability and precision always go first with robustness just a bit behind them, and in game programming performance is everything and nothing else is even slightly important. If you need a lot of extra execution code to fix some undesired behavior that would add considerable delays, in generic programming you just add that code, but in game programming you can really just throw it away and get to go with that bug, or come up with "slightly unstable" code that would be really short and won't impact performance, where "slightly" is very widely ranged. Say, in generic programming you wouldn't even consider using fast inverse square root, but in games that invention turned out to be incredibly handy. Of course modern hardware offers much faster and precise direct inverse square root computation, but the idea remains the same: anything goes for the sake of running fast. And "running fast" is an absolute value. If something runs fast on your I7 it doesn't mean it is actually fast. It could be as much as 0.5 FPS fast on p3. For such cases there's very common approach which states "screw them", but you can't really use it unless you create a monster like doom4 or diablo3 that would naturally require hell of a processing power.

By the way, I was looking into allegro's sources and it really lacks of game techniques exploitment. It would constantly call malloc/free in events queue for an instance, which is a fine way to program a software, but bad way to program a game. In video game, you allocate your memory once and then you use whatever you have. That's because continiously allocating and deallocating small chunks of memory creates a memory fragmentation, which is virtually unsolvable within mehtods reasonable for game programming, apart from being slow by itself. Another thing is probably brought in by plusesers. That thing is application of C++ patterns where they're don't belong, which only adds up confusion and slightly increases execution time and memory consumption for absolutely no reason other than just having them there.

here was a huge rant about C++ and coders that use it, but it is now absent because they're not susceptible to reasoning and it would cause nothing but holy war

Easy: allocate as much as required to contain all the events that could possibly arrive between two discardtions. I believe, 4096 bytes events array would be satisfying for most cases. And if happens to be not, it could be easily re-allocated to 8192 bytes. That makes for a single malloc and free call and one or maybe two realloc calls, ever. That would also save up a bunch of memory compared to initial approach, because every single malloc creates 12 through 48 bytes overhead, depending on implementation.

Let me just download sources again... there.

Is there anything I missing?

Oh, that line...
if (vec->_items == NULL) {
And couple of ithers... I must've been reading the code diagonally when I thought it allocates space per event.

But what's with re-allocating to space two times bigger than necessary? It works okay if initial size is 1 unit, i.e. it would reallocate to 2 units, that makes perfect sense, but with 128 units it would reallocate to 256 units, while only giving 129 units data length i.e. just one more unit size increase to vectors' mind. It is certainly a memory waste. And this time I read the code line by line and then symbol by symbol so I'm fairly sure of it.

On the second thought, it supposed to double the vector size. But then the adjustment should be like this instead:

vec->_items = new_items;
vec->_unused = vec->_size;
vec->_size *= 2;

And if so, vector allocation is called old * 2 times, which grows the vector size in cubic progression, i.e. 0 -> 1 -> 2 -> 8 -> 1024 -> 67108864 -> 288230376151711744. It is enough to simply call it once to double it's size. But the thing that really confuses me here is that vectors' allocate back for some reason thinks that it uses up one unit. Absense of comments doesn't help at all.

Also, reallocation pointer is supposed to be void pointer, to match vector's _items field (and because *alloc returns void pointers).