Say… your bricks are 24x12 and the ball radius is 6… then you shouldn’t move more than 11 pixel per frame. That means using tickbased animation. Eg a fixed framerate of 60 and fixed movement. If the machine cannot deliver that much frames the game will just get slower (the vast majority of 2d games are like that).
hmmm, but i really think it is important to keep the movement
completely independent from sizes of your game object. not only that they can change widely (over development, additional enemies whatever). sometimes it is necessary to have objects which move faste than 11px (like your example):
e.g: the-ultra-plasma-rocket-phasor-launcher which needs to fire bullets with a speed of 20px per frame to (example only!)
to get a lightning fastflight over a 1024 wide screen … or something…
Well, yes… raycasting + sweep tests :
[quote]best way to animate smoothly is to have a coordinate and a direction vector, which gets scaled based upon the passed time. this can cause the problem that if the computer is late on drawing and the direction vector gets too long, the ball could jump over small obastacles without noticing any collision. same problem occurs if the ball’s speed is very high.
[/quote]
Yes, I’ve noticed problems like that in my game. If the game lags when the ball is close to the edge of the screen, it may have gone ‘out of bounds’ by the time the game gets updated again.
[quote]That means using tickbased animation. Eg a fixed framerate of 60 and fixed movement. If the machine cannot deliver that much frames the game will just get slower (the vast majority of 2d games are like that).
[/quote]
:-/ That sounds kind of crappy. Seems like most good 2d java games I’ve played lately run at several hundred frames per second. Do the benefits of tickbased animation and a fixed framerate outweight the benefit of using time based movement and an uncapped framerate, and the game being playable on a slower machine?
[quote]Well, yes… raycasting + sweep tests :
[/quote]
??? Should i look into these things?
up to now im convinced not to use raycasting or similar heavy weapons :-*
scientifically spoken there were very good and smooth arkanoids, breakouts and blockbusters 15 years ago and im sure, no raycasting was used there.
perhaps i will have enough time next weeks to get a early (but smoooooth =)) build of arkanoid ready.
yeah, it has to be so … it must …
That sounds kind of crappy.
It is. But it’s easy and it works perfectly well as long as the machine is always able to deliver the frames fast enough. All arcade and almost all console 2d games work like this.
Should i look into these things?
Well, yes. It’s pretty cool stuff, which you can use for lot’s of different things. (Raycasting won’t be helpfull, because you don’t use a grid).
General (nice overview):
http://www.harveycartel.org/metanet/tutorials/tutorialA.html
http://www.harveycartel.org/metanet/tutorials/tutorialB.html
Sweep tests:
plane vs sphere (walls vs ball)
AABB sweep (ball vs bats)
Grid traversal (raycasting):
http://www.flipcode.com/articles/article_raytrace04.shtml
It’s also a good idea to check out the articles from Jeff Lander (gamasutra).
Well, you’ll need a high res timer (*) and at least two weeks for understanding the concepts, but it’s really worth it. You can also use that stuff in 3d later on - it’s the same (really). Oh and it’s also a step towards rigid body dynamics. So if you ever want to do some cool physically correct simulations, you’ll have to learn less new stuff.
(* It’s possible with a crap timer and some averaging. However, just thinking about that gives me a headache. It’s really not recommended.)
[…]breakouts and blockbusters 15 years ago and im sure, no
raycasting was used there.
Arcade games use a fixed framerate of usually 60fps@60hz.
They just rely on vsync and do their fixed steps all the time. If there’s too much action the game will just slow down.
If I have a high performace timer I generally just decouple the updating from the frame rate. So, I can do a tick based update, but the framerate will go as high as available. This also makes things like demos very simple. 
Can we see how you implemented it please ?
I am trying to learn how to do the same thing
[quote]its very nice that this discussion gets along frame rates. now i would like to drive it in the area of collision detection ;D
if my post isnt placed well here, im sorry, an admin should move it to an own thread then.
years ago i made a arkanoid clone by myself and i got fast to some collision issues.
best way to animate smoothly is to have a coordinate and a direction vector, which gets scaled based upon the passed time.
this can cause the problem that if the computer is late on drawing and the direction vector gets too long, the ball could jump over small obastacles without noticing any collision. same problem occurs if the ball’s speed is very high.
i solved the problem with calculating each pixel of movement and testing collision for these positions (so many tests for one frame). this is a pretty save but expensive way.
i know is started such a thread long time ago, but the
solutions(?) were a little academically (i remeber some words like raycasting - perhaps a little too heavyweight for breakout …)
[/quote]
Hey can i look at how you did collision detection in your arkanoid clone please i am trying to learn how to do the same thing
I’ll just reply here instead or PMing you back.
“Pixel Perfect Collision [detection]” aka PPCol isn’t necessary for a game like breakout.
Well, you can of course handle it pixel perfect, but NOT on the pixel level. Instead you use geometric shapes to discribe the pieces - a circle(*) for the ball and rectangles for the bricks.
(* Oldschool Arkanoid also uses a rectangle for the ball)
Doing that stuff on a geometric level is way faster.
I could post some code for doing it the “proper” way (raycasting + sweep tests), but you wouldn’t understand it. It’s not because I think that you are stupid or anything like that. It’s just… 200+ lines of rather weird/complicated code, which would be completely useless without knowing/understanding the math behind it. It’s based on more than 6 articles and a paper about raycasting from 1986 and it took me more than 2 weeks to write it (I had to learn/understand that stuff at the same time). Without fully understanding it you would be unable to do the changes needed for some of the common powerups.
Ok. Since you are pretty new to all this game stuff I suggest to do it the easy way first. Believe me - it’s still hard enough 
The price you’ve to pay is also pretty small:
-There is only one framerate.
-The maximum speed of the ball is limited.
-If the machine cannot keep up the speed the game will slow down.
So…
-Pick a framerate which is high enough (60 or 75fps)
-Do the math before. Calculate how much you can move the ball.
-Using 2d acceleration your game will run at more than 200fps on a 500mhz machine with some gf2mx-ish card. It hardly matters.
This is how you calculate the max speed:
For example the brick is 10 pixel heigh and the ball has a radius of 4 pixels. The length of the arrow in that picture would be 10+4+4=18, therefore the maximum speed (at which it should be impossible to pass through bricks) would be 17 pixels.
Sure you could move the ball faster in other directions, but it’s the worst case which matters. It should be fast enough anyways. [17*60=1020 pixels per second]
The collision detection would be just Rectangle’s intersect() method and the four cells which you’ve to check are those under the 4 bounding rectangle corners of the ball(*). Calculating em is simple… take the middle of the ball and add|subtract the ball radius and then devide by cell height|width… and Math.round the result.
- as seen here:
The reason for only checking those 1, 2 or 4 cells below the ball is simple - it’s much faster than checking all cells. And well, there is no reason to check for collisions which won’t happen anyways.
Also, remember that there’s a difference between drawing to the screen and updating the game. Presumably you already do this, but if you don’t: update the game-state independently of the rendering and the drawing. This lets the game progress at an even pace even if the fps suddenly drop (some background-process suddenly hogs the processor).
Added plus: when you know nothing has happened in the game-space you do not need to draw a new frame to the screen, as it would be the same. Geddit? A frame saved is a frame earned, or something.
Bottom line: seperate updates per second (UPS), which relates to the speed of the game, and frames per second (FPS), which should be consistent at say 75 frames/sec.
This article shows you how to use the nanotimer (it’s really easy and good) and maintain consistent frame-rates:
http://www.sys-con.com/story/?storyid=46663&DE=1
Dr. Andrew Davison (who frequents this board) is writing a book on game-programming in java (and it’s quite good, although not quite finished). Check out the first chapter, “An Animation Framework” for just this sort of thing Remember to send him any errata you find…
http://fivedots.coe.psu.ac.th/~ad/jg/
I hope this helps