Same.
To make things more interesting, you can add an impulse to the ball in the direction the paddle is moving at the time, or allow the paddle to be tilted.

Some versions of Breakout provide some sort of enhancement for the player's paddle (or for the game itself), like "slower ball", "stick on paddle until mouse-click", "shoot lasers to also pop tiles", etc.

You could do the same kind of thing: turn on gravity, make the paddle "bounce" the ball back (like bouncers in pinball machines), change from a 6-angle paddle (like you were just talking about) to a totally flat paddle, etc.

But that's just for your TODO list down the road, once everything else gets up and going.

How is your logic being updated, according to time? Do you pass in the delta time, the current number of "ticks", or are you simply calling your update() function without using any sort of "time measurement"?

Also, logic updates and screen updates rarely need to be set at the same speed. You may only want to do logic updates a few times (10 or 20 times for your 60-fps setup), and then draw every single frame (drawing is actually quite CPU-intensive, so that may not be so great), or fiddle with some of your settings.

I have one game where you can moderate your FPS. Below 20 FPS, the game really starts to stutter noticeably. Stepping up from below 20 FPS to around 30 is when you can tell that the "jumping" gets smoothed to almost non-existent. Between 30 and 60 FPS, there's not major difference, and above that (up to 200 FPS, where I cap it), there's no change at all (though it eats up more CPU).

Working with an actual "delta_time" being passed into my update() function was the best thing for me. At 200 FPS, my delta time was in the order of "1/200th" of a second (well, due to processing time, maybe "1/198th").

Check out how I have the code (at least the updating system) in the attachment on this thread. While I didn't go with the Allegro timers (I used the BZflag's code), the way that the game gets updated is with delta times, and you can change the FPS with the '-/+' keys.

The trouble with the design presented on the wiki is, as mentioned earlier, that you don't get any sort of delta to compare your timing against. It essentially assumes that all updates are the same, regardless of framerate. And from experience, I have personally seen most programs jump between a single tick, to multiple ticks, each time the logic gets updated. That's due to other programs hogging the CPU (good old Firefox, IE 8, Safari, Opera, and any other tabbed browser that likes to refresh its tabs on a regular interval), which throws off the exact "tick" count in odd places.

The wiki shows this kind of construct:

However, I'd suggest modifying that a little.

(Warning: untested)

With this, since the timer was set initially to "(1000.0 / FPS), then to get the delta time, you take the difference between the current and old ticks, and divide by that value. So if your FPS is set to 60, then the allegro timer will update your "ticks" once every (1000/60)th of a second (or roughly every 1/16th of a second). If the difference of (ticks - old_ticks) is "0", then your logic is simple: the ball's velocity gets moved "0" pixels. If the difference is "1", then the delta_time is around "0.06" seconds, meaning that your ball will move (velocity * 0.06 * [cos(angle) | sin(angle)]) pixels (depending on x- or y-direction).

Does that work in your program?

What do you suggest then?

So what you guys are saying, is that it is impossible to make timing for a breakout game, using the allegro4 timers only? Or at least without forcing 100% CPU because of having to update logics 300/s...

300 updates/s is way too much. First off, the timers are too coarse (10 ms by default under Windows) to properly handle update frequencies that high. But more importantly, there is absolutely no point of running updates at a higher frequency than your display - which at best goes up to around 100 Hz. 50 Hz should be more than enough for your needs.

You do know that if your monitor only refreshes at 60Hz and your ball moves faster than 1px per 1/60 seconds you are going to get jumping no matter how high your FPS goes?

You mean this question?

Breakout clones have been done many times in the forums. Some better than others, admittedly. Search through the last few years worth of posts and you should find some good pointers and tips on how, when others who have done it, everything was set up to allow for correct timing and updating (so it didn't look choppy/jumpy).

With what you've currently coded up, are you still seeing jerky movement? If so, could you post your code? We may be able to spot where the jerkiness comes from, and post better feedback once we know how to best respond based on your needs.