I see this as a sort of passive limitation (using Thread.sleep() instead of limiting the redraws conditionally beforehand). One thing to note is when I leverage the delta properly, I can keep CPU usage down to between 15-20% with very smooth animation.

I'm really looking for any sort of advice on this. Is there generally a better way to go about the game loop? Is this code fine, but maybe a few tweaks here and there?

I'm not currently using any libraries. I'm literally just casting the Graphics object that is sent to the paint() methods I'm overriding up to a Graphics2D object and turning on anti-aliasing with the proper RenderingHints.

I will eventually switch to something a bit more powerful (and more appropriate) like Slick, LWJGL or JOGL for more complex games, but I wanted to get a good grasp of the underlying 2D rendering capabilities.

I'll dissect this and see where I can get in terms of performance. Thanks for sharing your loop. Anyone else have a game loop they'd be willing to share? Preferably not based on Slick or any other game library?

You also might want to reset interrupt status - though it shouldn't cause problems in this specific context, as you also rely on the running boolean and the contents of the loop should not require much time to execute.

Thread.currentThread().setPriority(10);seems random you might want to make it relative to the calling thread or allow one to set it by exposing it with their value.

You also might want to reset interrupt status - though it shouldn't cause problems in this specific context, as you also rely on the running boolean and the contents of the loop should not require much time to execute.

Thread.currentThread().setPriority(10);seems random you might want to make it relative to the calling thread or allow one to set it by exposing it with their value.

Thanks for the input.Where would you recommend putting the exit? When the user ends my game I set running to false which stops the loop. If I don't call exit, the application stays open.

Yes, it maxes the CPU, but other Threads are able to do their work even with that.

Maybe. I found that one of the games in this year's Java4k competition was almost unplayable until its author changed from yield to sleep, at which point it started actually detecting and handling all of my key presses.

What I did is basically create a repeating timer that call repaint() when it ends and I use paint() as my game loop... If the fps is faster than the Timer it will wait for the timer, if it's slower then the next repaint() will just have to wait. Anything is wrong with that

I don't even understand exactly what you're saying, but using the Timer class is acceptable. The main problem with it is that you can't directly control it like you can with the sleeping. So, if you're getting slower or faster FPS you can't really adjust it accordingly. For simple games I think it works fine, but I wouldn't use it for anything that's complex.

I don't even understand exactly what you're saying, but using the Timer class is acceptable. The main problem with it is that you can't directly control it like you can with the sleeping. So, if you're getting slower or faster FPS you can't really adjust it accordingly. For simple games I think it works fine, but I wouldn't use it for anything that's complex.

After reading it I got scare that I took a wrong way so I did some test to see how I could control the game speed so it match with the FPS. I'm still using a timer and I was able to change the game speed accordingly to the FPS. Here is a sample of my code.

protectedvoidpaintComponent(Graphicsg) {longtime0 = System.nanotime();//The code of the game loop//....//end of the game looplongtime1 = System.nanotime();intt10 = (int)(time1-time0)/1000000;inttimeDelay = setTimeDelay(t10);//+2 because it's the average time difference between 2 repaint and//the time in the game loopgameFrame.TIME_DELAY = timeDelay + 2; gameFrame.timer.setDelay(timeDelay); }

That will always be a frame behind, because you're setting the delay for the next frame based on the current frame's fps, and you don't appear to be using a delta variable of any kind. It won't really be very noticeable, but I still don't recommend using Timer.

Yay I finally made a good game loop (at least I think I do). Any places for improvement?

I took your mainloop and made a testrun, its very simple left-to-right animation. I have tried everything(?) to make it smooth as silk in a windowed Java application still not eating CPU100%. I think its close to impossible or I just can't.

Thx for making this testrun. To tell the truth when I post it I was hoping someone find a flaw in my design so I could improve it. (It is nearly my first gameloop).

I tried you testrun but I couldn't reproduce the jump unless I go to like 2000 fps (that eating nearly all my CPU). But, I see some tearing. I not sure to fully understand what cause tearing in a game but I find this with some research. http://www.gamedev.net/community/forums/topic.asp?topic_id=372033. Looks like you can't remove tearing unless you go fullscreen mode and enable vsync.

btw, what is you debug? Your fps counter print around 61 fps for me but you said it doesn't work.

Upper-left corner FPS counter was my debug value. When I posted my example code it printed run +90 fps but now I run it again. Its a steady 60-63 fps value. Go figure what was wrong last time, strange. So we come to a conclusion fps calc works after all :-)

I know and have done few native D3D apps they run fine windowed vsync lock. Its so nice a windowed non-tearing rendering loop, triple buffered flips and low cpu% usage.

Here is an another game loop borrowed from a forum post. Loop animation does not rely on a delta time but each updateWorld() call is one animation frame to be simulated. Slower machines drop renderFPS but loop tries to keep up to a updateFPS. I think it is a bit more consistent fps, but tearing is still visible. About "Toolkit.getDefaultToolkit().sync()" method I think we can forget it.

// Synchronise with the display hardware. Note that on// Windows Vista this method may cause your screen to flash.// If that bothers you, just comment it out.if (VSYNC) Toolkit.getDefaultToolkit().sync();

/* If the rendering is taking too long, then update the game state without rendering it, to get the UPS nearer to the required frame rate. */intskips = 0;while((excess > period) && (skips < MAX_RENDER_SKIPS)) {// update state but don’t renderSystem.out.println("Skip renderFPS, run updateFPS");excess -= period;update();skips++; } } }

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