I’m having problems where my game loop falls behind on slower machines and is not able to keep up with the frame rate I have set. I’m working on a metronome application which I will be moving over to mobile devices, so having this program run on slower devices is very important as I want it to work well for anyone who uses it.

This code runs flawlessly as long as the machine is fast enough to keep up. I ran it for close to 20 minutes or so on a fast laptop and the visual stayed in perfect sync with the audio, no problems at all.

I’m using JLabels and sprite sheets for my animations, which as I understand means that I can’t use some of the fixes I’ve found for handling this problem on slower machines. Methods like variable frame rates or changing how far objects move during each update based on how fast the computer moves through the loop seem like they require motion to be based on physics calculations instead of sprite sheets.

I’ve tried a few different methods using a constant frame rate. Initially I tried using the Util Timer, but this was really bad on the slow machine and I had no way of allowing it to skip ahead when it fell behind since it does all the timing stuff itself. Then I tried my own version of checking the system time and checking to see if it has time to spare to sleep or if it needs to rush ahead by skipping over the paint method...this worked a little better, but would cause glitches in the graphic where it would freeze for a bit and then start moving again. Also, even when it was moving smoothly the timing was off from the audio.

The current method I’m using now is one I found in this article:http://entropyinteractive.com/2011/02/game-engine-design-the-game-loop/This also used the technique of skipping the paint method, and so far this method seems to produce the smoothest animations (no long freezing glitches), but this still doesn’t keep time correctly with the audio on slower machines.

The only change I made to the method used in the article is I removed the option to reset the nextTime variable if it falls too far behind. I have two frame counters going, one on the audio side and one on the visual side and it seems like if I were to reset nextTime on the visual side that would cause it to simply drop those frames instead of trying to make them up. Thus the visual frame counter would never catch back up to the audio’s frame counter and the two would be permanently out of sync.

Your biggest first problem is that you are using JPanels and JLabels for animating game objects, which is not at all encouraged. Instead, we recommend you to try to keep a single Canvas, set it's preferred size and add it to a JFrame. Then create a BufferStrategy and use active rendering. Here's a small guide for that.

Another thing is that you can't rely on Swing for your games. If your game is getting big, you will see some performance problems like the one you got now. It is recommended to switch to OpenGL and use some library like LibGDX.

I wasn’t aware that swing was going to be such a problem performance wise, that’s a real bummer!

I don’t know that I can use any 3rd party libraries because I’m going to be using Codename One for developing my program on mobile devices, which uses their own Java API that is translated to native code for various mobile devices (Android, iOS, Windows Phone, Blackberry, etc). Everything I’ve been working on in my Java prototype I’ve been checking against the Codename One API to make sure the classes I use are also supported in Codename One.

Essentially what I need in my metronome are setting controls, such as text fields to enter numerical values, buttons (start/stop, tap tempo, etc), sliders (for tempo, volume, etc). Then I will have the visual display which will involve the beat counters (which is also changing color currently) and sprite animations. That’s about it!

It seems I need a mix of swing components and graphics (for animation) and not many tutorials seem to cover how to do all of this, which I think is why I’m getting so stuck on this. I’m usually pretty good at finding information, but this has been difficult finding anything close to what I need. Your article is about the only tutorial I’ve seen that goes into this kind of thing. However, you (and the article you posted) don’t actually recommend using swing at all for games...so that also complicates things.

If I was just sticking with Java then using 3rd party libraries wouldn’t be so much an issue. But I don’t think I’d be able to get them to work with Codename One when I move to mobile unfortunately.

So given all of these things, what seems like the best path forward? I’ve re-written my graphics code several times starting from complete scratch and it seems each time I try something different I still end up running into some kind of road block. I was really hoping this latest one would be more easily fixed with some tweaks to my game loop, but if this is still not the best route to go, then I’d rather do it a better way.

Is there another route I can go implementing a double buffer on my own? I read your article and it sounds like BufferStrategy essentially chooses the best method between double buffering or page flipping...so couldn’t I implement a double buffer myself using other Java components (which would be supported by Codename One) instead of relying on BufferStrategy? This is essentially what I started out trying to do originally in my other thread I posted above, but my method was not successful at all.

Yes there is another route. Drop Codename One (whose server build code is proprietary whereas the homepage claims "Codename One is open source & free for use!") and use LibGDX, don't rely on black boxes. I don't know why you would go on using a tool that isn't optimized for games. Codename One seems to be enough for near real-time rendering but not for games. If you stick with Codename One, only use very simple components (in com.codename1.ui) and don't override the painting. Codename One supports text fields, sliders and buttons of course. The problem is that you need to animate a sprite :s

Yeah, the server builds on Codename One is certainly a drawback. I wasn't looking forward to that for sure especially if the whole process takes a while to get your code back from their server.

I've done a little bit of research into LibGDX and I saw that it does a similar thing to Codename One in that it also writes native code for mobile devices. I wasn't able to find much in the way of direct comparisons to Codename One other than a general mention that LibGDX is geared more towards games and Codename One is geared towards applications...but I'm not sure what specifically that involves. I do know they have very different API's just from a quick glance at them. I was originally leaning more towards Codename One still because it's API was closer to Java SE, but now I'm sensing that may not be such a good thing. LOL

One other thing I noticed is that LibGDX doesn't appear to support Windows Phone where Codename One does. I don't really know how many people use Windows Phones, but maybe this would be a worthwhile tradeoff if the overall program would end up being a lot better if done in LibGDX?

I will give LibGDX a more solid look now that it is appearing this may be the better route to go in.

Windows Phone seems to be stagnating, I'm not sure that the choice of an API should be dictated by its support. Look at LibGDX Scene2D. I can't advise you to use JogAmp's Ardor3D Continuation yet as its OpenGL-ES support is partial (ES 1 ok, ES 2 & 3 nok) and there is no plan to support all mobile operating systems except Android and GNU Linux distros (including Raspbian).

I’d like my app to be supported by as many devices as possible, so the number of devices that an API supports is something I’m taking into consideration. However, it seems like I may not get the performance that I want out of standard Java and Codename One, and LibGDX does support everything else that Codename One supports minus Windows Phone...so the tradeoff might be worth it.

Although, I googled LibGDX to Windows Phone and I found a forum post talking about the possibility of going from LibGDX to HTML5 and then using PhoneGap to convert the HTML5 to Windows Phone...that’s certainly taking the scenic route, but maybe something like this would work?

For my metronome I shouldn’t need any kind of 3D animations. I have very basic animation needs really, just a few displays keeping a count of the current beat and 2D animations of an analog-style metronome.

I’ve looked a little harder at the LibGDX API and holy smokes it is totally different! lol It kind of feels like learning a brand new language, I didn’t even see basic java components I need like ArrayLists and such. I believe there are lists in LibGDX, but I just need to learn the new terminology now.

In regards to point 3 about using the standard library with libGDX...does this include converting to mobile devices? If so, how does the entire Java library get converted to mobile devices? From looking into Codename One you had to stick to their API in order for the code to be translated to the various devices. Is this the same with LibGDX or do they support converting the entire Java library? If they do, then I am totally SOLD on LibGDX!!!

Keep in mind that by "the whole std lib whilst using libGDX" I am assuming you won't be using AWT/Swing/Java2D as that would mostly defeat the purpose of libGDX. But stuff like java.util (ArrayList) is trivial. (libGDX does have it's own collections though)

Wow!!! I had no idea LibGDX supported the entire Java library otherwise I would have gone this route a lot sooner. Looking at the info you posted, RoboVM is how they convert to iOS? So I assume they have other tools they use to convert the Java library to the other platforms as well since it also supports Android, Blackberry, and HTML5?

Do you know if there is another place where they list the standard Java libraries that is guaranteed to be supported by LibGDX? The LibGDX API only includes their libraries and doesn't include anything from the standard Java API (which is why I didn't know they actually did support Java standard libraries). I just want to make sure I don't end up mixing things that can't be mixed, like for example you said not to use AWT and Swing, so I want to make sure I'm not doing weird things like trying to use basic containers like JFrames to enclose the LibGDX animations if that is not going to work.

in libGDX it's a LWJGL Display (which in libGDX you never have to actually interact with)

Sorry to contradict you a very little bit. LibGDX has several backends for desktop and mobile environments, one of them uses JGLFW, another one uses Android GL, another one uses GWT, another one uses JogAmp... Only the current (August 17th, 2014) default desktop backend works like you say. It's just a small reminder. I agree with the rest.

So basically, it sounds like LibGDX combines a variety of different existing tools together under "one roof" so to speak and allows them all to be used from a single code base? Is that correct?

Also, one more small question...

Is there a preferred IDE for use with LibGDX? For example, when I asked this question about Codename One on their forum, the developer specifically stated to use NetBeans that they use it and they tended to release more updates for it and it worked better overall with Codename One. Is there a similar preference for LibGDX? I have limited experience with both NetBeans and Eclipse, so I have no real personal preference either way. Which ever one has better LibGDX integration or even has more LibGDX tutorials available...I'll go with that one.

Thanks BurntPizza! If there is no significant difference for compatibility with LibGDX, then from searching for IDE comparisons in general (not related to LibGDX) I've seen that Eclipse is more widely used, so I will probably go with that one then.

I wasn’t aware that swing was going to be such a problem performance wise, that’s a real bummer!

I don’t know that I can use any 3rd party libraries because I’m going to be using Codename One for developing my program on mobile devices, which uses their own Java API that is translated to native code for various mobile devices (Android, iOS, Windows Phone, Blackberry, etc). Everything I’ve been working on in my Java prototype I’ve been checking against the Codename One API to make sure the classes I use are also supported in Codename One.

Essentially what I need in my metronome are setting controls, such as text fields to enter numerical values, buttons (start/stop, tap tempo, etc), sliders (for tempo, volume, etc). Then I will have the visual display which will involve the beat counters (which is also changing color currently) and sprite animations. That’s about it!

It seems I need a mix of swing components and graphics (for animation) and not many tutorials seem to cover how to do all of this, which I think is why I’m getting so stuck on this. I’m usually pretty good at finding information, but this has been difficult finding anything close to what I need. Your article is about the only tutorial I’ve seen that goes into this kind of thing. However, you (and the article you posted) don’t actually recommend using swing at all for games...so that also complicates things.

If I was just sticking with Java then using 3rd party libraries wouldn’t be so much an issue. But I don’t think I’d be able to get them to work with Codename One when I move to mobile unfortunately.

So given all of these things, what seems like the best path forward? I’ve re-written my graphics code several times starting from complete scratch and it seems each time I try something different I still end up running into some kind of road block. I was really hoping this latest one would be more easily fixed with some tweaks to my game loop, but if this is still not the best route to go, then I’d rather do it a better way.

Is there another route I can go implementing a double buffer on my own? I read your article and it sounds like BufferStrategy essentially chooses the best method between double buffering or page flipping...so couldn’t I implement a double buffer myself using other Java components (which would be supported by Codename One) instead of relying on BufferStrategy? This is essentially what I started out trying to do originally in my other thread I posted above, but my method was not successful at all.

Thanks again!

I had the same issue with my games , I originally only used pure java with swing. There is currently no pure java alternative because of the fact it does not use the gpu hence if you use a low power computer it will have a lower power CPU meaning it will be slower. Honestly building a very basic efficient opengl renderer is easy if you have had some experience. its all the other things such as merging layers and shaders that are more difficult.

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