Let me know what you think.
http://gaming.cyntaks.com/projects/projects/BreadPong/applet/
Works! (JRE1.5, XP, 2GHz, Nvidia) Ball motion a bit jerky.
Cas 
Works here as well.
2.5GHz, XP SP1, JRE1.5b2, nVidia GF3 ti200
It seems more jerky on high-quality than on normal, but I can’t see any difference in quality? What does that do?
Yes, it works, but it’s pretty jerky… guess the timer is to blame. This kind of stuff works perfectly well with nanoTime.
It seems more jerky on high-quality than on normal, but I
can’t see any difference in quality?
It’s antialiased then.
Ok, y’know… you can cheat there. Draw the antialiased circle once to an offscreen image… and draw that one all the time.
private public Image makeBall()
{
Image image=gc.createCompatibleImage(BALL_SIZE,BALL_SIZE,Transparency.OPAQUE);
Graphics2D g2d=(Graphics2D)image.getGraphics();
g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING,RenderingHints.VALUE_ANTIALIAS_ON);
g2d.setColor(background);
g2d.fillRect(0,0,BALL_SIZE,BALL_SIZE);
g2d.setColor(Color.white);
g2d.fillOval(0,0,BALL_SIZE,BALL_SIZE);
g2d.dispose();
return image;
}
See? Piece of a cake 
just make sure that the extra stuff to anti-alias the edges doesn’t run over the edge of the image! You may need to add another pixel to the width and height
All systems go I like the highscore table! Simple and smooth.
You may need to add another pixel to the width and height
That isn’t be necessary. All drawing action should take place within those pixel boundaries.
Javadoc says:
“Fills an oval bounded by the specified rectangle with the current color.”
See?
Ah, good idea. I’m not sure if that’ll make that much of a difference, but I’ll look at it.
Anybody try it with an OS other than XP, or a JRE<1.5?
Also, what do you guys think about the difficulty curve? I think it feels like it starts out way too easy, but that might just be because I’ve spent so much time playing with and testing it 
I also feel like it starts out too easy. I think this would be fixed by making it so that moving the paddle while you hit it actually knocks it at an angle… you know, angular momentum I really like that in pong games and it would make it more interesting. When I started, it just bounced between two corners 5 times before it finally moved on, but it never did anything interesting still.
Works with similar problems to those described above; jerky ball when on the high quality setting. I also experienced a couple of little jumps where the ball disappeared.
Also when I lost a ball the paddles disappear to display the get ready message, reappear in the position they were last at when I lost the ball and then jump to the position of the mouse when it’s moved. Which looks a bit messy.
Have to admit I found it all a bit slow going and, well, dull…sorry…
Sys: JRE1.5.0-b64, Win2K, AMD2400XP, GeForce4MX
Well I’m pretty new to game programming, so I can’t think of any way to make the ball move smoother.
The amount I’m moving it by each ‘tick’ is relative to the amount of time that has passed since the last tick, so the game speed should be constant regardless of processer speed. And I’m ‘ticking’ as frequently as possible. Is there a better way to do it, or does anybody have any other suggestions? Is there a way to v-sync outside of fullscreen?
Yeah, it sucks :P. I was cleaning out some of my old java projects when I found a simple ball bouncing app I wrote. I thought it might be fun to throw in some paddles and call it a game
The amount I’m moving it by each ‘tick’ is relative to the
amount of time that has passed since the last tick[…]
That explains the crappy “framerate”. The framerate by itself might be pretty hight, but lots of identical frames are drawn, because no time passed between frames.
The millis timer thingy is only 50-55msecs accurate on win9x. That means if less than 50-55 msecs passed, the measured timespan will be 0 and the calculated movement will be also 0. The result are freshly created 100% identical frames
Just switching to nanoTime will make it alot smoother. If you also switch to pre drawn antialiased images, you’ll get a very high frame rate (about 400fps on a 500mhz machine with some gf2mx-ish card).
[quote]That explains the crappy “framerate”. The framerate by itself might be pretty hight, but lots of identical frames are drawn, because no time passed between frames.
[/quote]
Crappy framerate? What does that mean? The user will never see/notice that identical frames are being drawn, so does that matter?
[quote]The millis timer thingy is only 50-55msecs accurate on win9x. That means if less than 50-55 msecs passed, the measured timespan will be 0 and the calculated movement will be also 0. The result are freshly created 100% identical frames
[/quote]
Everybody so far has been using 1.5 though, so millis has been is accurate. What else could be causing my jerky ball? I’ll throw up a 1.5 build using nanotime to see if the difference is noticable.
[quote]If you also switch to pre drawn antialiased images, you’ll get a very high frame rate (about 400fps on a 500mhz machine with some gf2mx-ish card).
[/quote]
400fps? Won’t that result in a “crappy framerate”? Is that good or bad ???
“crappy framerate” = low framerate
Crappy framerate? What does that mean? The user will
never see/notice that identical frames are being drawn, so
does that matter?
I put quotes around framerate, because the framerate itself can be pretty high actually.
Well, do the math. 1000/50=20.
With win9x you get less than 20 different frames per second, which does indeed look a bit crappy/jerky.
Everybody so far has been using 1.5 though, so millis
has been is accurate.
Uhm… no. That millis thingy is as bad as ever. System.nanoTime() is the accurate one.
400fps? Won’t that result in a “crappy framerate”?
That’s the number you could reach… benchmarking etc. Usually you want to cap it somewhere eg at 60 or 75 fps (idially the same freq as the monitor).
Some c&p frame capping:
private long timeNow, timeThen, timeLate = 0, timeDelta;
private boolean frameCap=true;
[...]
g.dispose();
sync(1000000000L/frameRate); //nice spot
strategy.show();
[...]
public void sync(long frameFraction)
{
long gapTo = frameFraction + timeThen;
Thread.yield(); //good if the machine is maxed out all the time (we won't enter the yield loop)
timeNow = System.nanoTime();
if(frameCap)
{
while(gapTo > timeNow+timeLate)
{
Thread.yield();
timeNow = System.nanoTime();
}
}
if(gapTo<timeNow)
timeLate = timeNow-gapTo;
else
timeLate = 0;
timeDelta = timeNow - timeThen;
timeThen = timeNow;
}
That timeDelta thingy can be used like this:
b.x+=b.dx*ups*(double)timeDelta/1000000000.0;
b.y+=b.dy*ups*(double)timeDelta/1000000000.0;
(dx/dy is a normalised direction vector and “ups” is units per second - the speed)
[quote]“crappy framerate” = low framerate
[/quote]
Actually it sounded like he meant that a crappy framerate is one that is too high. In that the game will be refreshing before anything had changed.
/me points at the latest post of page 1
(we posted at the same time :P)
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 …)
i remeber some words like raycasting - perhaps a little too
heavyweight for breakout …
Haha ;D
Well, raycasting is the way to do it. You also need sphere sweep tests and you need to be able to run the simulation until you reached the elapsed time.
That’s the price you’ve to pay for using time based movement. It’s much easier with tickbased timing (if you ensure that the ball moves less than one cell per tick).
hum hom … not really satisfiying at all…
you mean its important too keep float point coordinates to avoid rounding mistakes… ?!