breakout: smooth ball animation

Java 2D
#1

i want to pick up the topic which breadpong already started.
im keen on working my old arkanoid over (windowed). and now where i want to make it really nice i notice that this is not the easiest task …

in my testphase my game runs with normal thread.sleep(x) and bufferstrategy >150fps. i know the problems around sleep but the framerate should fairly be enough to go further.
the problem is the movement of the ball itself. like it is normally done theres a position-vector and a direction vector both with float components.
but like breadstick’s example the ball moves very crap (no breadstick, i love your game ;).

i know there are pitfalls with the vsync and rounding issues so that e.g. sometimes two frames paint the same coordinate. but i dont know how to avoid this.

therefore i looked into the ping example of chet haase.
but although its very nice the ball doesnt move really smooth.
i looked into the movement-algorithm and wondered why he uses a cast to get the floating point coordinates to integers. isn’t rounding the better choice ?

so im searching for the smoooooth ball movement.

#2

You problem is probably due to the granularity of the timer.

e.g.

You determine 25ms has passed since the last loop
Next time around you get 15ms, then 20ms, etc. etc. Because the timer values are all over the place, it doesn’t bode well for smooth animation.

I normally smooth things out by writing a simple to class to take the timer value and return a new averaged value. So it’s kinda like this:

Loop pass 1: 25ms -> Class returns (0 + 25ms / 1) = 25ms
Loop pass 2: 15ms -> Class returns (25ms + 15ms) / 2 = 20ms
Loop pass 3: 20ms -> Class returns (40ms + 20ms) / 3 = 20ms

The more values it’s given, the better the average becomes.

#3

i dont think its the granularity of the timer:

i take my concrete example. i want 85 fps so using a sleep timer a frame should only take 11ms.
i took an output of the time my rendering and gamelogic takes and the pausing which is calculated upon that. trusting this output java gets it perfect to handle these desired 11ms.
the sum of the pausing and the consumed time is always 11ms…

#4

The timer granularity on Windows is 10ms for 2000/XP and 50ms for 9x. So there is little to no possibility of getting 11ms. If you use System.nanoTime(), you can get better precision.

Also, you can’t rely on sleep() methods to return when they say they will. The return time can and will drift by a few milliseconds. And if you attempt to use a sleep value less than 10ms, the entire Windows clock will drift. (Ever wonder why your computer clock seems a little fast? Now you know.)

Now I created a timer that solves all of these issues. But if you’d rather beat your head against the wall, then be my guest. :slight_smile:

#5

errrmmm, eehhhemmm…
sounds logically. should have thought about that. was late
yesterday. ermm.
so i try it using nanotimer. results will be published soon ;D

but any comments on the cast vs rounding thing ?

#6

store your info with all the accuracy you want. Cast when you pass to your draw methods

#7

ok, but an explanation would be nice. up to now i always preferred rounding because it “feels” more natural and logical than cutting the floating point part off.

#8

well, either it gets rounded down now, or it gets rounded down later. Either it gets rounded up now, or it gets rounded up later. If you move a ball by .6 pixels per frame, and you watch it go across, casting to int will do:

.6                  0
1.2            1
1.8            1
2.4            2
3.0            3
3.6            3
4.2            4
4.8            4
5.4            5

Or with rounding you get:

.6                  1
1.2            1
1.8            2
2.4            2
3.0            3
3.6            4
4.2            4
4.8            5
5.4            5

You can see that the length of time spent on a pixel is the same, just shifted over a bit. To clarify, look at the first example. Start with x=1.2. Times you stay on the same pixel are 2, 1, 2, 2. If you look at the rounding example, and start with x=1.8, you get: 2, 1, 2, 2. The same stuff happens, it just happens .6 pixels over. To prove that mathematically, consider the ranges for which one pixel is used. For casting, you have from 0.000 - .999. For rounding, you have .5001 - 1.500. Both have a range of approximately 1. The only difference is their slightly shifted. That means your objects WILL move at the SAME SPEED, not different. However side by side their approximations will occur at different times, but they will run through the same order of approximations.

#9

The only problem with casting is that positive numbers are rounded down, but negative numbers are rounded up.

Lets look at an example where you increment by 1:


float=3.5 cast=3 round=4
float=2.5 cast=2 round=3
float=1.5 cast=1 round=2
float=0.5 cast=0 round=1
float=-0.5 cast=0 round=0
float=-1.5 cast=-1 round=-1
float=-2.5 cast=-2 round=-2
float=-3.5 cast=-3 round=-3

Notice the two zeros in the cast column. Thats why you wan’t to use round, ceil or floor instead of cast.

#10

Instead of that silly sleep thing you should use some kind of (smart) frame capping like this one:

private long timeNow, timeThen, timeLate = 0;
private boolean frameCap=true;
[...]
g.dispose();
sync(1000000000L/75L); //75hz
strategy.show();
[...]
private void sync(long frameFraction)
{
      long gapTo = frameFraction + timeThen;
      timeNow = System.nanoTime();

      if(frameCap)
      {
            while(gapTo > timeNow+timeLate)
            {
                  Thread.yield();
                  timeNow = System.nanoTime();
            }
      }

      if(gapTo<timeNow)
            timeLate = timeNow-gapTo;
      else
            timeLate = 0;

      timeThen = timeNow;
}
#11

ahh ok. very clean ideas, thx for it. im noticing that my first (and only one) game project (long time ago…) did only scratch the theories.

now im wondering if i should concentrate on tick or time based animation. at this point im not able to notice all pitfalls which can bite me in pure timebased animation. but im familiar with tickbased.
i have read articles which say that the animation benifits of time based technique does not outweight the collision detection problems in 2D games. i dunno if that is completely true.

the code snippet from onyx is exactly what ive been searching for, but before i start to base my game upon that (time is rare …=) i should consider to kick fps over board, animate only with a time factor and only give one thread.yield() a chance per tick to save racing conditions.

so gentleman, let me profit from your experience. then, perhaps 12 years later, you will play the world’s most exciting “serethos’ breakingout arkanoid”

;D

#12

The snippet is ment for tickbased animation (the timeDelta part is missing). As long as the machine is able to render at least the desired frames per second (75 in this example), the game will run perfectly fine.

You can throw in a Thread.yield() at the very beginning of the sync method for ensuring nice behaviour on crappy machines.

I was about to post some pics here, but they suspended my freenet account. Crap. Now I have to use my own webspace :stuck_out_tongue:

#13

sure, like i mentioned you snippet is the way to go for tickbased games. but im thinking if tickbased is what i want (need ? desire ?).
i think this i a very important decision which i want to make before i try to implement more deeper aspects like collision detection etc.

#14

but im thinking if tickbased is what i want (need ? desire ?).

Tickbased would be sufficient, because it’s unlikely that your game will be played on machines, which are unable to keep up. I mean… my machine is “ancient”. 500mhz, 128mb and some gf2mx card. However, an breakout-ish games easily runs with 200+ fps.

i think this i a very important decision which i want to make
before i try to implement more deeper aspects like collision
detection etc.

Let me put it this way. I could explain all steps for tickbased collision handling (from the top of my head) in a single (short) post. But I would need more than a day to explain the same for timebased movement.

It’s really a lot more complicated.

With tickbased animation you have to care - each frame - where you are and do those simple checks. That’s it.

With timebased animation an infinite amount of collision can happen from one frame to the next. Paddle, wall, brick, wall, brick, wall, brick, wall, wall, brick, brick… and out. You need to take care about that. You need sweep tests and raycasting. You need to determine the timefraction till the first collision and run the logic with the remaining time again until you ran out of remaining time (for this frame).

So if you like spending 2+ weeks for research and testing, go timebased. If you want to finish the game within 2 weeks, go tickbased.

#15

i think the issue is cleared. i only wanted to now if there are any pitfalls i did not calculated.
your post was very convincing ;D

but what did i hear ? finishing in two weeks ?!?
ehem, this wont be any breakout, it will be an amazing(!) worldbreaking brick-game!
hmm, perhaps not really, but it seems that i have only enough time to write two lines of code each day (untested ones …).

#16

but what did i hear ? finishing in two weeks ???

Ya, that’s 2 weeks “full spare” (3-4h a day) for 2 weeks, if you’re pretty good. Graphics, some sounds, an ingame level editor(*) and ~30 levels were included in that figure. It’s based on the amount of time, which I would need for that kind of stuff (since I did something like that not too long ago, I think the figure is pretty accurate).

(* It’s easy to do and the turn over rates are really worth it. Do some changes… check… change… check etc. You can churn out a dozen levels just before breakfast ;))

#17

still one thing:
the paddle, ball, wall, brick (…) problem can also occur with tick-based animation. perhaps not in such a massive way…

#18

[quote]still one thing:
the paddle, ball, wall, brick (…) problem can also occur with tick-based animation. perhaps not in such a massive way…
[/quote]
Yes.

-check for collision
-collision?
-if so… response… and repeat to check for new collsion
-if not… nothing to see here move along

You also need to keep the maximum amount of pixels per (logical) frame below this:

http://kaioa.com/k/max_speed.png

Eg the brick is 16px heigh and the ball radius is 6. 16+6+6=28. So don’t move more than 27px otherwise the ball can warp through bricks. (It’s really “fun” if the ball warps through the paddle ::)).

#19

yepp i very familiar with this kind of problem. in former times (its been long, looong ago) i already wrote an (technically not so perfect) arkanoid.

what i want to say is that the main collision problem occurs in tick like in timebased games, only with the difference of the amount of horror errors in a given time period.
so i thought it would be not the biggest problem to change to
time based animation.

but no matter, ill take tick based. but i really dont like the idea of limiting the ball’s speed to the thinnest object in my game world. in my old arkanoid project i moved the ball pixel perfect but drawed it only in larger intervals.
in know this is no way to go, because its horribly inperformant.

i would like to improve the original arkanoid with very basic physical aspects like differenct shapes. so not only cubic bricks but perhaps triangulars, 30° edges, whatever.
so it is important to have no limitation in shape and size of the game objects …

#20

so, ive implemented now the nanoTimer(). but im not really sure if that’s the result i wanna see. but please take a look by yourself

http://zeus.fh-brandenburg.de/~huellein/arkanoid.jar

im very sorry not to have it made webstartable…