Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (527)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (593)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  breakout: smooth ball animation  (Read 2191 times)
0 Members and 1 Guest are viewing this topic.
Offline Serethos

Junior Devvie




Java games rock!


« Posted 2004-12-13 18:13:12 »

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  Wink.

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.
Offline CreoGames

Senior Newbie




Java games roxor!


« Reply #1 - Posted 2004-12-13 18:21:18 »

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.
Offline Serethos

Junior Devvie




Java games rock!


« Reply #2 - Posted 2004-12-13 18:51:06 »

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...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #3 - Posted 2004-12-13 19:00:55 »

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. :-)

Java Game Console Project
Last Journal Entry: 12/17/04
Offline Serethos

Junior Devvie




Java games rock!


« Reply #4 - Posted 2004-12-14 06:01:53 »

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

but any comments on the cast vs rounding thing ?
Offline Malohkan

Senior Devvie




while (true) System.out.println("WOO!!!!");


« Reply #5 - Posted 2004-12-14 13:58:49 »

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

Admin and Game Developer at
GameLizard.com
Play Rimscape!    |    Play Conquer!
Offline Serethos

Junior Devvie




Java games rock!


« Reply #6 - Posted 2004-12-14 19:00:21 »

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.
Offline Malohkan

Senior Devvie




while (true) System.out.println("WOO!!!!");


« Reply #7 - Posted 2004-12-14 20:09:05 »

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:
1  
2  
3  
4  
5  
6  
7  
8  
9  
.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:
1  
2  
3  
4  
5  
6  
7  
8  
9  
.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.

Admin and Game Developer at
GameLizard.com
Play Rimscape!    |    Play Conquer!
Offline tom
« Reply #8 - Posted 2004-12-14 21:14:06 »

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:
1  
2  
3  
4  
5  
6  
7  
8  
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.

Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #9 - Posted 2004-12-14 21:25:15 »

Instead of that silly sleep thing you should use some kind of (smart) frame capping like this one:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
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;
}

弾幕 ☆ @mahonnaiseblog
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Serethos

Junior Devvie




Java games rock!


« Reply #10 - Posted 2004-12-15 06:12:38 »

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"


Grin
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #11 - Posted 2004-12-16 01:25:17 »

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 Tongue

弾幕 ☆ @mahonnaiseblog
Offline Serethos

Junior Devvie




Java games rock!


« Reply #12 - Posted 2004-12-16 05:58:06 »

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.
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #13 - Posted 2004-12-16 06:33:16 »

>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.

弾幕 ☆ @mahonnaiseblog
Offline Serethos

Junior Devvie




Java games rock!


« Reply #14 - Posted 2004-12-16 07:44:47 »

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  Grin

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 ...).
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #15 - Posted 2004-12-16 09:19:48 »

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

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 Wink)

弾幕 ☆ @mahonnaiseblog
Offline Serethos

Junior Devvie




Java games rock!


« Reply #16 - Posted 2004-12-16 18:26:14 »

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

JGO Coder


Medals: 2


pixels! :x


« Reply #17 - Posted 2004-12-16 19:51:30 »

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


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:


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 Roll Eyes).

弾幕 ☆ @mahonnaiseblog
Offline Serethos

Junior Devvie




Java games rock!


« Reply #18 - Posted 2004-12-17 06:19:48 »

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 ...
Offline Serethos

Junior Devvie




Java games rock!


« Reply #19 - Posted 2004-12-19 09:33:31 »

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...
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

PocketCrafter7 (12 views)
2014-11-29 06:25:35

PocketCrafter7 (7 views)
2014-11-29 06:25:09

PocketCrafter7 (8 views)
2014-11-29 06:24:29

toopeicgaming1999 (74 views)
2014-11-27 05:22:04

toopeicgaming1999 (64 views)
2014-11-27 05:20:36

toopeicgaming1999 (15 views)
2014-11-27 05:20:08

SHC (29 views)
2014-11-26 02:00:59

SHC (27 views)
2014-11-26 01:53:45

Norakomi (32 views)
2014-11-26 01:26:43

Gibbo3771 (28 views)
2014-11-25 09:59:16
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!