next »

[lasttea999]

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

Hello TIGSource,

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:

(Java programming classes at college)
http://www.yoyogames.com/
Matt Thorson's Grandma Engine
http://www.cokeandcode.com/index.html?page=tutorials
http://www.thenewboston.com/?cat=35&pOpen=tutorial
http://www.java-gaming.org/index.php/topic,24220.0.html
http://www.java-gaming.org/topics/solving-stuttering-with-fixed-timesteps-once-and-for-all/24975/view.html
http://www.lwjgl.org/
http://www.mojang.com/notch/

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:

http://www.compuphase.com/vretrace.htm

http://weblogs.java.net/blog/chet/archive/2006/02/make_your_anima.html

http://today.java.net/pub/a/today/2006/02/23/smooth-moves-solutions.html

    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:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6378181

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:

http://today.java.net/pub/a/today/2006/02/23/smooth-moves-solutions.html

http://www.java-gaming.org/index.php/topic,4127

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:

http://forums.create.msdn.com/forums/t/30892.aspx

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?

[dustin]

I've never gotten things to look greater using java's built in renderer.  I would highly recommend slick if you want to use java...

http://slick.cokeandcode.com/

It's a 2d accelerated library built on LWJGL.  It's very simple and very fast since it means all the rendering is done on the graphics card.  It ran great even on my 5 year old laptop.

[lasttea999]

Thank you for your feedback. I have looked at Slick, and if I remember correctly the timing was similar to my program. And I've already mentioned that LWJGL rendering didn't seem to be much of an improvement... So maybe Slick does a better job of implementing those features in some fashion that I've overlooked?

I guess I'll have to test a game made with Slick. I wonder if it lets you adjust the number of logic updates per second, though; that's something I'd like to be able to do. Again, if I remember correctly, LWJGL's built-in features don't let you do that, so I used LWJGL rendering while using my own timing mechanism.

[dustin]

Yeah I saw you had tried LWJGL but it's more complicated so there's more room to mess up.

I can give you something simple I made in slick+java a while ago if you want and you can see how that runs.  Probably easier then whipping up something yourself and you can figure out if rendering is the problem or not.

[lasttea999]

Thanks, that'd be great! Please note that detecting stuttering is easiest (at least as far as I can tell) when something moves horizontally at a constant rate.

[J-Snake]

It's because of the fixed timestep. Smoother GameMaker games are looking more smoothly because they are not using vsync. If you run your game in variable step this problem will be solved immediately. Also there were recently threads around this issue some steps below, I recommend you to look them up.

[lasttea999]

It's because of the fixed timestep. Smoother GameMaker games are looking more smoothly because they are not using vsync. If you run your game in variable step this problem will be solved immediately. Also there were recently threads around this issue some steps below, I recommend you to look them up.

Actually, I have been looking them up (and struggling to understand some of it), ha ha. I've been seeing your posts; I thank you for your feedback.

By variable step, do you mean that all movement is interpolated with a delta value? Come to think of it, (if that is what you're referring to) I think the guy who created (?) Slick2D does that too. Hmm.

[PompiPompi]

The first thing I would do is to try and make an application that renders the minimal thing you need to notice stuttering. If there is no stutter there, then you need to profile\optimize your engine.
The second thing is, you need to learn how to profile\optimze a non native program. I don't know how to do it, but I know there are differences from C++ for example.

[lasttea999]

The first thing I would do is to try and make an application that renders the minimal thing you need to notice stuttering. If there is no stutter there, then you need to profile\optimize your engine.

Thank you, that sounds like it'd be illuminating. This will probably be an image moving back and forth at a constant rate.

The second thing is, you need to learn how to profile\optimze a non native program. I don't know how to do it, but I know there are differences from C++ for example.

Unfortunately I'm too much of a novice to have known that there was such a difference between C++ and Java. Does that have to do with higher- and lower-level programming languages, or something along those lines?

[Mikademus]

Truthfully, you're asking too wide a question: "why is my graphics stuttering?". It can't be answered because it depends on the techniques you're using and the constraints of your platform, language and frameworks.

The best thing to do is look up the basic concepts and standard techniques behind computer animation and see if that helps, helps with tracing down the issue, or helps you ask more specific questions.

Especially look up:
* double buffering
* vsync
* java garbage collection
* hardware acceleration

[PompiPompi]

I am afraid stuttering is not that straight forward to deal with. It can be quite complicated.
For instance, you might have "bursts" of CPU usage eventhough your overall CPU usage is well bellow 100% if you look at the task manager.

[ஒழுக்கின்மை (Paul Eres)]

just as a side note, vsync in game maker does not work. you actually get less screen tearing (and the game runs faster) if you leave vsync off. no GM game should every have vsync turned on

[lasttea999]

Thanks for the feedback, everyone!

It's because of the fixed timestep. Smoother GameMaker games are looking more smoothly because they are not using vsync. If you run your game in variable step this problem will be solved immediately.

just as a side note, vsync in game maker does not work. you actually get less screen tearing (and the game runs faster) if you leave vsync off. no GM game should every have vsync turned on

Wait, so variable time step => no vsync? I guess I haven't researched vsync enough to know exactly what it is, although I have seen it pop up quite often in discussions... Doesn't that only come into play when dealing with fullscreen graphics, though? Also, I had thought vsync was supposed to be helpful, but here it sounds like that's not quite the case?

Also, it seems like the majority of articles I've read about fixed and variable time steps tend to favor the fixed option over the other (EDIT: kinda hard to tell). Could it be possible that my problem lies not in the time step itself, but in the interpolation of graphics?

Truthfully, you're asking too wide a question: "why is my graphics stuttering?". It can't be answered because it depends on the techniques you're using and the constraints of your platform, language and frameworks.

Good point. I do know that at least one of my builds (and I think the other build may be using it under the hood (?), too), and I think Game Maker also uses double buffering. Still trying to figure out vsync, as seen above.

The reason I haven't been more specific, by the way, is that I didn't want to get too far into the Java details on a forum that deals not with Java in particular but with games in general... which may lead you to ask why I'm posting here at all, and the answer to that is that I didn't really want to bring up Game Maker and game loops in general in a Java-specific forum. Also, I'd like opinions from outside the Java community.

[J-Snake]

You can use vsync in variable step. The speed of your game-loop will be locked to your screen. This is ideally the best thing you can do to achieve silky smooth movement and a clean (not teared) picture in addition. Nearly all the big shooters are running in this game-loop, the main reason to turn off vsync is to give the game significantly better performance in worst case situations.

However note that a 120hz screen is not a 60hz screen. Your game will potentially run faster the higher the refresh-rate of your screen. It means that you need to scale all the movement in the game according to the elapsed time between each gameloop-call to keep the game-speed constant.

The problem is obviously just the fixed timestep, no garbage-collector, no performance...
simply because its rate can never exactly match the screen-refresh-rate, from time to time either a game-frame is overjumped (running faster than refresh-rate) or the same game-frame is drawn twice (running slower than refresh-rate). Whenever (usually frequently) one of these situations occur you see a jump, that's all there is to it.

[lasttea999]

The problem is obviously just the fixed timestep, no garbage-collector, no performance...
simply because its rate can never exactly match the screen-refresh-rate, from time to time either a game-frame is overjumped (running faster than refresh-rate) or the same game-frame is drawn twice (running slower than refresh-rate). Whenever (usually frequently) one of these situations occur you see a jump, that's all there is to it.

I certainly hope this is the case. What's your opinion on fixed time steps with graphical interpolation, though?

By the way, GM seems to offer a level of predictability that I think is based on a fixed time step--- the user deals with "step events", and I've rarely seen a delta value being used with movement. I've never used one myself, and my GM games seem to run just fine.

[J-Snake]

I am personally preferring the interpolated fixed timestep whenever I can. I seem in the minority to use it but for me it is the way to go. According to my experience it is sufficient just to interpolate translation (not rotation and animation) to create a smooth experience.

Gamemaker is using fixed timestep but it has no vsync. It means it is tried to render more game-frames. The con is the tearing you see on the screen but it is still a better solution than stuttering. If you are satisfied with how Gamemaker games are looking then you can go with this solution.

[lasttea999]

Alright, I'll think I'll try to stay with interpolated fixed timestep too, then. Thank you again, J-Snake and everyone else, for your feedback.

Again, it may be that I'm not implementing interpolation correctly, then, because when I do turn on interpolated graphics, it doesn't seem to make much of a difference.

Furthermore, I tried to follow PompiPompi's suggestion about making "an application that renders the minimal thing you need to notice stuttering", and this is what I came up with: click here. It does still stutter, so I guess the problem isn't, in fact, being caused by the movement engine (as J-Snake and perhaps others seem to have already suggested).

[ஒழுக்கின்மை (Paul Eres)]

interpolated graphics has nothing to do with interpolated timestep. interpolated graphics just means that pixels at fractional locations are drawn 'blurred' between two positions

also gm by default uses fixed timestep but it is possible to use delta time too (i do that in my game)

[J-Snake]

Again, it may be that I'm not implementing interpolation correctly, then, because when I do turn on interpolated graphics, it doesn't seem to make much of a difference.

Be advised that there are many misconceptions and ways to do the interpolated fixed timestep wrong. This "fix your timestep"-article shows you how to do it right. Just look below the "free the physics"-headline, this is how your fixed timestep - loop should look like, you implement it inside the variable step. The additional displacement(of your moving objects) assumed by the remaining time is what you add to the PREVIOUS position in your draw/render-function, that is the interpolation which is going to be displayed on the screen. Note, you are manipulating only the VISUAL output, not the state of your game-logic, otherwise you will screw it up.

In case you are working with Flash or a similar platform, it is not possible to implement it there since you can only render in "flash-frames" instead of directly to the screen-buffer. The flash-frames are then going to be displayed on their own in a fixed timestep just like a movie. It means that you won't get a new flash-frame for each screen refresh, if the movie is too slow sometimes a frame will be drawn twice and there is nothing you can do about it:(  

If you are satisfied with Gamemaker and your engine allows to turn off vsync and enable fixed timestep then your problem might already be solved, just try it out. But if you are seriously concerned with visual output and consistent game-mechanics I would suggest you to spend some detailed thought about how the fixed timestep and how a game-loop actually works.

[lasttea999]

interpolated graphics has nothing to do with interpolated timestep. interpolated graphics just means that pixels at fractional locations are drawn 'blurred' between two positions

Wait, maybe I'm confusing terminology. By graphical interpolation I'm referring to the method of taking an alpha or interpolation value and trying to guess, in a sense, what the rendered frame would look like between logic updates, like:

Code:

drawnX = lastActualX + interpolation * (actualX - lastActualX);

also gm by default uses fixed timestep but it is possible to use delta time too (i do that in my game)

So it's like a hybrid between fixed and variable timesteps? That sounds interesting; what's the overall effect that achieves? Even greater smoothness?

I'm pretty sure my engine does what the "fix your timestep" article says... That part of my engine mostly comes from a tutorial on a Java forum written by someone who I'm guessing has a good understanding of those concepts. You can find the tutorial here.

The code goes mostly like this:

Code:

while (running) {
double now = System.nanoTime();
int updateCount = 0;

//Do as many game updates as we need to, potentially playing catchup.
while(now - lastUpdateTime > TIME_BETWEEN_UPDATES && updateCount < MAX_UPDATES_BEFORE_RENDER) {
update();
lastUpdateTime += TIME_BETWEEN_UPDATES;
updateCount++;
}

//If for some reason an update takes forever, we don't want to do an insane number of catchups.
//If you were doing some sort of game that needed to keep EXACT time, you would get rid of this.
if (now - lastUpdateTime > TIME_BETWEEN_UPDATES) {
lastUpdateTime = now - TIME_BETWEEN_UPDATES;
}

render();
lastRenderTime = now;

//Yield until it has been at least the target time between renders. This saves the CPU from hogging.
while (now - lastRenderTime < TARGET_TIME_BETWEEN_RENDERS && now - lastUpdateTime < TIME_BETWEEN_UPDATES) {
Thread.yield();

//This stops the app from consuming all your CPU. It makes this slightly less accurate, but is worth it.
//You can remove this line and it will still work (better), your CPU just climbs on certain OSes.
try {Thread.sleep(1);} catch(Exception e) {}

now = System.nanoTime();
}
}

I guess the main difference between that code and the code presented in the article is that this code uses yield() and sleep(1)?