Smooth sailing for me, I have vista and a dual core but no problems with your sample code.
I have made several games in java and all of them have used Java2D and I haven’t had any problems. One of them was even a full blown RPG with lots of drawing and calculations and I never saw a performance hit, always a steady 59-60 FPS so I think your issue with it lies somewhere else.
I agree that many names are stupidly long, but it makes starting out easier as they are more explanatory.
And with the garbage collector, remember that java was not made exclusively for video games and the gc does an incredible job performance wise taking that in mind, I think everyone else’s suggestions pretty much cover gc for video games.
So what do you think the issue might be? I’m running JRE6u10 under Windows Vista on a 2.2Ghz AMD Turion 64 with an ATI Radeon XPress 1100 graphics card. Should I be running the 64bit JRE? :-\
Typically the problem resides with the hardware, not Java. I’ve discovered that the machine (a laptop) was throttling the CPU to conserve power!
If you’re intrested, below you’ll find some code that will bench the Thread.sleep() method on your machine and report failures if the method doesn’t sleep for exactly the time requested.
public class ThreadSleep {
public static void main(String args[]) {
try {
boolean ok = true;
for (int i = 0; i < 100; i++) {
long start = System.nanoTime();
Thread.sleep(10);
long end = System.nanoTime();
if ((end - start) < 10000000) {
System.out.print("failed, iteration ");
System.out.print(i);
System.out.print(", time ");
System.out.print(end - start);
System.out.println("ns");
ok = false;
}
}
if (ok) {
System.out.println("ok");
}
} catch (InterruptedException x) {
System.out.println("error: Thread interrupted.");
}
}
}
Here’s the output for my machine:
failed, iteration 1, time 9961881ns
failed, iteration 83, time 9998757ns
failed, iteration 94, time 9968865ns
failed, iteration 97, time 9989818ns
Unpredictable as Hell, what a headache! Does anyone get a run of the code above with zero failures?
If you want to get 100% innocent CPU usage, spawn (a few*) daemon threads looping on Thread.yield(). It might do the trick keeping your animation smooth (and draw your battery like there is no tomorrow).
Yes, but it sleeps close to 20ms (you only check the lower bound). In any case, without using a hard real-time scheduler the duration parameter is a request rather than a demand.
… at least add a thread.yield or you will produce a cpu lock (if your blitting has been delayed for example it will be locked…), (there are severals java source code available and able to produce a stable frame rate).
IMHO : even from an algorithm point of view the method you have used is innacurate as the error are cumulative over time => with your method at 60fps after 100 s you can have produced a number of frame very different than 6000 (60*100)
Thread.sleep and System.nanoTime are two methods that have showed inaccuracy depending on OS and hardware
Oof, no love for the functor around these parts, is there? Time for a rant, duck and cover!
A lot of people underestimate how useful closures are to have built in to a language, and how crippled a language actually is without them - yes, as in, there are abstractions that we cannot make in Java because we don’t have this stuff, and it makes our code less reusable and modular. You can work around some of the issues with an interface, and for those uses it’s just syntax sugar (for sorting it’s not too obnoxious to require a comparator, for instance). But the same exact thing could be said about inheritance, which you can simulate to your heart’s content in a language like Lisp (let’s pretend for the moment that Common Lisp didn’t already have CLOS built in, which for all intents and purposes is true since nobody uses it). The difference between having that syntax sugar and not having it means that you approach problems in a completely different manner - in languages without closures, people pretend that everything is a noun, even when it’s a verb (MyFunctionWrappingObject), and in languages without objects, people pretend everything is a verb (myObjectSimulatingFunction). Yeah, you can get away with it, but IMO it’s better to verbs and nouns as they are meant to be used, not try to shoehorn one into the other.
Added syntax sugar is only one tiny bit of the argument in favor of closures, though - Neal Gafter had the following to offer on the subject:
Since the ability to abstract common patterns is generally considered a good thing, I’m surprised that the addition of closures is so hotly contested, as it opens up a whole new class of abstractions - as a very simple example, functionality like foreach is dead simple to implement with closures, and pretty much impossible to do properly without them, at least without writing your own compiler or annotation processor (essentially what AOP weaving does). Stuff like that needs to be hard coded directly into the language if we want to use it, which is a real shame, since it doesn’t happen very often, and we end up duplicating mountains of code patterns as a result.
If you need more convincing that there’s stuff that you really can’t do in Java as-is, see Neal’s talk about closures at http://www.parleys.com/display/PARLEYS/Home#talk=6533;slide=1;title=Closures%20for%20Java - there is actual power added to a language by closures, it’s just that it’s the type of power that most Java and C++ programmers don’t even think to miss because the boilerplate code that it would replace (and the design patterns it would render irrelevant!) has become so ingrained at this point. [To be fair, C++ technically has the ability to do this stuff, it’s just a lot messier than it should be - when people argue for closures, they’re not merely suggesting C++ style function pointers, which tend to do more harm than good!!!]
From a less radical point of view, the unconvinced may be curious to hear James Gosling’s take on closures (he’s one of the people campaigning for them):
And btw, I’m no more sympathetic to the functional people’s claims that their languages don’t need objects or state - you may be able to get away with representing everything as a monad, and in situations where you absolutely need state-free computation that makes sense, but for the sanity of people that don’t have that requirement, your language had better offer a choice, and build it in with some decent syntax. Yeah, I’m looking at you, Haskell!!!
@mgianota: Yeah, works fine on my machine, too (constant 60 fps), though there is an unacceptable amount of tearing (tested both OS X Java 5 and 6).
Edit: it’s worth noting that none of my closure rant has much to do with Java for games in particular, more just about the language as a whole.
;D I agree. Using Mono is not completely legal because Microsoft can prosecute you for patents violation. C# is not really cross-platform, it is a bad dirty clone that has some drawbacks of C/C++ and some drawbacks of Java (without all its advantages) :o
[quote]Most programming languages are turing-complete, so the power of closures do not arise from their ability to compute things that cannot otherwise be computed. Rather their expressive power arises from being able to abstract over things that you simply could not abstract over before. In the case of closures, it is the ability to define APIs that abstract over an arbitrary statement or expression. Writing such APIs simply isn’t possible in Java today.
[/quote]
All that vouchers for is control abstraction, not closures per se. and everything seems to be geared towards that. What it seems to boil down to is that ppl want the ability control abstractions. No one has researched or focused on discovering possible other methods of including those without closures, they rather copy what is out there. Which is very un-java like. I’m not against stealing good idea’s, I am against doing stuff wilst not thinking for ourselfs. The closures advocates have not given the right answers. Also syntax examples as shown out there just don’t work half of them aren’t java like other half is focused on one line code blocks and fail hopelessly with multi line etc. that and other stuff - which is rather something for an other (new) topic.
C# as a language is actually very capable and does not fall short of Java in any relevant aspect. I prefer Java, but discrediting C# does not help anything.
Yes, you’re right. I added the Thread.yield() call into the main loop.
The method I’m using is the only one I know for producing a reasonably acceptable frame rate. Do you have any code to share that can increase the accuracy? For example, do I need code that will measure the frame rate while the game is running and increase the frame rate to compensate for cumulative errors over time?
BufferStrategy will only vsync if it’s in fullscreen exclusive mode. IIRC it’s impossible (even for a native app) to do proper vsync’d rendering in a window.
Well, sorry if this is abrupt, but that is what we have been advocating all along. Java is fantastic as a language for so many reasons but without native libraries, it would not be possible to achieve parity with other native languages. And I see absolutely no problem with that whatsoever. In fact, check out one of my recent blog posts: http://blogs.sun.com/ChrisM/entry/wayback_machine_games_at_sun
Back in 2001-2002 we were attempting to build the equivalent of DirectX for Java. These were all going to be native libraries to get closer to the metal. And, again, there is nothing wrong with that. Better to have to support development of specific APIs than worry about cross platform porting of an entire application code base. I mean, before C became performant enough, developers used to code entire rendering pipelines in assembly. C++, developers used bindings for C APIs. In fact, you still see certain graphics platforms that access hardware directly and bypass APIs all together.
I guess someone needs to want it enough for that to happen.
Going back to the original comments on the thread, there seem to be just a few gripes:
Applets are crap (different reasons from different people, but still crap)
JRE is too big (fixed by Java Kernel?)
Need to use native libraries to get consistant performance (is this really an issue or a matter of taste?, fixed by including JOGL et all as a module of the Java Kernel?)
The other bits and pieces seem to be a matter of taste or isn’t a directly related games thing.
Task manager shows the java.exe consuming only 76% of the CPU.
- its crap.