Current solution??: LWJGL + extra thread fix (downloads have not been updated with this fix)Also, smoothness achieved with C++ and DirectX!? Some updates to what I know:http://forums.tigsource.com/index.php?topic=22054.msg822358#msg822358
I've been using Game Maker for quite a while, but recently I learned some Java in college so I've been trying to make a game engine in Java (relying further on tutorials and various other sources). Problem is, on some computers the graphics never get rendered as smoothly as, say, a GM game--- moving images sometimes stutter. I've been trying to figure out why this happens for a while now. Any ideas as to the cause?EDIT:
Here are some newer examples I prepared, most of which are different versions of the LWJGL example
someone called Cero posted in a thread
over at Java-Gaming.org
. Most of the examples incorporate different examples of fixed timesteps from various sources.
I've bundled together those examples in a single download, along with some other example programs (like a similar Game Maker example) and the source for all the different examples. You can download it here: box.com download
Note: example_simple.jar and example_variabletimestep.jar are examples without fixed timesteps; they're there for comparison.
There are various settings you can toggle within the JARs, like vsync and the usage of Thread.yield and Thread.sleep. More details are contained in the included readme file.
To make the programs, I drew on help from these and other sources:
I've been testing on three types of computers:
1) The computers at school, which run Windows 7. They seem to be very fast, and GM programs and the Java examples alike seem to run fine on them.
2) My 3 or 4 year old laptop, which runs Windows Vista. The Game Maker examples and the Java examples all stutter a fair bit, but it might be a bit better with the Game Maker program; it's a little difficult to tell.
3) Our desktop at home, which is newer than my laptop and runs Windows 7. The Java examples seem to have the most trouble on this computer, relative to the Game Maker example. However, the phenomenon is pretty inconsistent between trials (for example, sometimes the programs run more smoothly than on the laptop), and I don't really know what's behind the differences between different trials.Potential causes:1) Hardware.
It could just be that the machines I test on are slow, but I doubt this is the case because as far as I know there shouldn't be much reason for them to be slow, and in any case that doesn't explain why GM games still run smoothly on them. It is true that GM games also display some stuttering on the same computers, but it's usually not as noticeable as the stuttering with Java.2) My code.
Of course I may have just written faulty code, but I think, if that were the problem, there probably wouldn't be so many existing discussions about the issue, would there? (Because people would just need one or two resources of this kind to solve their problem, and wouldn't have had these discussions for so long.)EDIT:
I am kind of a novice, though. I've been building my program from portions of various examples and tutorials; if there is an error in my code, it may be pretty likely that it comes from faulty implementation of the code from these various sources. Maybe I made an error in fitting all the different pieces into my target framework?3) Sleeping and timers.
This is the kind of problem discussed in this thread
. The idea is that sleep() is unreliable, and/or that the precision of available timers is insufficient. Wasn't this latter problem solved by System.nanoTime(), though? a) Potential solution: Running a thread in the background the whole time.
I've seen this work on at least one computer, but I think I've also seen it not do much another computer, and in any case it seems a bit hacky to me...4) Something to do with waiting for vertical retrace.
Here are some links related to this topic: a) Potential solution: A request for enhancement.
I think some of us have heard that there are or were people trying to incorporate vsyncing capabilities (or something similar) into Java itself:
But as far as I know this hasn't been achieved yet. Do any of you know where this effort currently stands? b) Potential solutions with native code.
The following links, one of them a JGO thread by Kevin Glass, claim to provide native methods to solve this:
But I haven't tried the first solution (I don't really know how to make it work...), and I suspect that the second one might be outdated. Does anyone know how to properly implement these solutions, or know if any current, equivalent solutions have been made, or could be made? c) Potential solution provided over in the XNA forums.
Someone has apparently experienced similar problems with XNA, and has provided a supposed solution:
This may be a solution that can get around not having access to vsync, but I've had trouble understanding some of the XNA-specific code provided in the link. Does anyone know enough XNA to be able to try an equivalent solution in Java?A Potential General Non-Solution: Maybe we're just being too sensitive to stuttering?
Someone in the aforementioned XNA-related link commented:
Ignore the GPU clock, and let the CPU clock control the update frequency. Sure, this means you will occassionally have dropped or doubled frames, but as long as the clocks are roughly close, this will be rare, and the results are fine for many games. Especially, people tend to notice the time drift in very simple test apps where they are doing things like just moving a box across the screen one pixel per tick, so they freak out about this, but the artifacts tend to become less obvious as the game becomes more complex, so they are often no problem at all in the finished product. The nice thing about this mode is that it keeps your update logic nice and simple, which is why this is the XNA Framework default (we call it fixed timestep mode).
This sounds kind of plausible, but I think there's one thing this doesn't account for: GM running more smoothly than Java.
Sorry for the long post! So, where does the future of this issue lie?