One more thing: almost nobody cares about running smoothly when running in a window. It's not how people play real games. Web toys, etc. - that's what people play in windows, with accordingly lower expectations.

Yeah I mentioned that - I thinks its true.Although back then, I played like Fallout 3 windowed and World of Warcraft and stuff - to see MSN or whatever

If you've got DWC turned off and running in a window, and vsync's on, the only thing left you can do is accurately sync to the hi-res timer. Unfortunately LWJGL's Display.sync() method somehow manages to do this wrongly if you need it to be dead accurate. Try this:

It will round the sleep time every frame, so it will sync to 63 FPS too. Same problem as the LWJGL Display.sync().

The stuttering that you see is due to two frames being submitted before a screen refresh can take place, meaning that one frame is lost. By having 63 FPS, you're dropping about every 20th frame. Result: visible but not "measurable" stuttering.

Why does this happen at 60FPS? Already explained that above, but here we go again. You have literally no control at all over when a frame is actually completed due to the command buffer, so there is no way to prevent the core cause of this problem. The command queue can potentially cause frames to be completed at irregular intervals, effectively affecting the chance a frame has to actually make it to the monitor before being overwritten by next one.

So even if you submit your commands perfectly synced to the screen refresh rate (exactly 60 commands per second) there is no guarantee that this will sync up with the screen refresh rate after going through the command buffer, the actual rendering process and then over to the screen. There are many things that can affect how long it takes for a frame to pass through all these stages.

- The driver thread is obviously sleeping while you're filling the command buffer. It's affected by the same timing problems as our own Java threads. - Even if the driver is woken up at the exact same time, there might be other programs running that are using your CPU, causing commands to be delayed. - Even your graphics card is a shared medium. Everything that's drawn on your screen goes through your graphics card, so why expect it to process the commands of your program immediately? We're talking pretty heavy context switches, delays in sending the data to the graphics card, delays in rendering the data due to other load, e.t.c.

Now to the funniest part: Why do people expect their monitors to have billion dollar atomic watches built in to their monitors? It's not that your monitor has a more precise clock than your computer. Rather, on the contrary I'd expect a cheap monitor to have a pretty inaccurate clock, possible running too fast or too slow, or even having heavy jitter. To ensure that no frames are lost, you obviously shouldn't synchronize to the same values as your monitor tries to synchronize to. You should synchronize to the monitor itself, and and all the syncing flaws it comes with. I'd guess that a monitor might update at between 59.5 and 60.5 FPS, giving you a lost or duplicated frame every other second.

Why are you guys so sensitive to this? I mean, your TVs have refresh rates of 60FPS, but movies are stored in 23.976 FPS. How can your screen handle that. IT CAN'T. It simply shows the same frame for either 2 or 3 updates, to achieve somewhat smooth movement. I bet you didn't even know that, and have never been bothered by it.

Things that won't solve this kind of stuttering: - Better sleep precision than what we have right now. - Newer more advanced game loops and delta handling than those in the game loop thread. - Syncing everything perfectly to 60 Hertz.

If you try any of these, you're syncing on the wrong side of the graphics card.

There is no way of completely getting rid of this stuttering. It is simply put an inherent flaw of computers running more than one process and one thread, your graphics card having a command buffer, your graphics card being used by more than one thread at a time and your monitor being imperfect, plus lots of other things.

VSync helps though. Your computer tries to supply a single frame for each screen update. However, you can still "miss a train" and get a duplicated frame. The time it takes for a frame to go from rendering commands to being displayed on your monitor is so susceptible to factors beyond your control that you're sometimes bound to lose a frame or two no matter how good you sync your game loop.

Obviously I can see the stuttering in the bouncing box demo posted by Cero. The reason that it is so easy to see is because you're moving the box one pixel per update, making it easy to see when one pixel is skipped. In a game, how many things move at a constant 60 pixels/second speed? For your information, running this with a green box on a red background will produce glaringly obvious artifacts on some very expensive monitors due to how they work. They simply assume that nothing you draw on it is going to be moving at 1 pixel per update constantly with the colors red and green.

Another better solution is to just render at an as high FPS as possible. If you're rendering at 120 FPS and a two frames are overwritten instead of just 1, it will only be a half as big difference compared to if you were rendering at 60 FPS and dropped a frame. It's much less visible, try it with any somewhat decent sync code (Display.sync(), the Sync class posted above, e.t.c). The higher your FPS, the less visible your stutter is. If you want to get rid of tearing too (which gets worse with higher FPS), use triple buffering. Remember that VSync and triple buffering can be forced in your drivers, and it should kick in for OpenGL accelerated Java2D too.

So drop it. You can't fix this completely. I'm so sick of people whining about a pixel here and there. It's not like your game will get bad reviews for this kind of stuttering. Commercial games have the exact same problem. This is not in any way related to Java or your choice of operating system. It's quite simply the way it is.

In response to all the recent responses. Please stop. It's sad to watch.

@theagentd - not everyone uses LWJGL for games. The whole reason it came about in fact in the dim distant past is that I wrote a library to do television graphics output which needed graphics at a rock steady 60Hz. This I achieved; however, I rely on actual vsynced fullscreen displays, which is the only cast iron way to do it right. Also it turns out a surprising number of objects in 2D games run at very precise unchanging velocities and they look jarring to people used to the slick smooth professional feel of console graphics and anyone brought up on home computers in the 80s.

Sadly you're right about the Sync class I posted, it will creep out of sync due to rounding, which is what LWJGL attempts to fix in its Display.sync() but fails. I don't use this loop myself I instead use a method that counts time over a big number of frames, resetting every now and again. But again, this is only a backup, to ensure that the game doesn't race if vsync fails.

Do not use interpolation. The only way you will get apparently smooth motion is a precisely fixed logic rate tied to a precisely fixed frame update rate.

If you get stuttering with vsync turned on, then the problem is not your code, nor LWJGL, but Windows.

Cas

...I would definitely use interpolation for rendering things in my game that will use fixed 50FPS updating to allow frame rates over 50 FPS. If you do it right, there is no problem at all with interpolation. BUT IT WON'T SOLVE THE REAL PROBLEM FOR F*CKS SAKE.

And yes, if you get stuttering with VSync on AND you're measuring exactly 60 FPS per second, then yes, it's something you cannot affect. If you're getting less than 60 FPS for a game that runs at >80 FPS with VSync off, then it's your own fault for having some frames take drastically longer time to render than other frames.

@theagentd - not everyone uses LWJGL for games. The whole reason it came about in fact in the dim distant past is that I wrote a library to do television graphics output which needed graphics at a rock steady 60Hz. This I achieved; however, I rely on actual vsynced fullscreen displays, which is the only cast iron way to do it right. Also it turns out a surprising number of objects in 2D games run at very precise unchanging velocities and they look jarring to people used to the slick smooth professional feel of console graphics and anyone brought up on home computers in the 80s.

Sadly you're right about the Sync class I posted, it will creep out of sync due to rounding, which is what LWJGL attempts to fix in its Display.sync() but fails. I don't use this loop myself I instead use a method that counts time over a big number of frames, resetting every now and again. But again, this is only a backup, to ensure that the game doesn't race if vsync fails.

Interpolation does not produce apparently smooth movement. The brain already predicts where something is going to be when it's supposed to be there, and when it doesn't appear there precisely on time, no amount of interpolation fixes it. So my advice is not to use interpolation positions but instead to get everything done at an unfailingly fixed rate and hope for the best.

Unless you're in fullscreen mode, you can't rely on vsync. But when you can rely on vsync, you're waiting on the correct side of the graphics card. You will get absolutely perfect 60hz displays with not a stutter in sight. That is what vsync is for. All that confusing stuff about command buffers and so on - no-one really needs to know! All devs need to know is: go fullscreen, turn vsync on, and that's the best you can do.

Although most here are talking about syncing with LWJGL, the OP should be mainly concerned with Java2D until he gains enough experience.

@OP Does this game stutter for you? Is there any screen tearing?Pressing 'X' will alternate between 60FPS and max FPS. I use a busy while loop that calls Thread.yield until the sleeping period is over. At both FPS's, I don't see any screen tearing on either good computers or slow computers.

btw - it irritates me greatly that movie framerates don't match monitor framerates But then, coz I've been working in broadcast video engineering for quite a while, little things like this really grate and stand out for me. I can't even watch DVDs or normal TV without the MPEG artefacts irritating the hell out of me!

Although most here are talking about syncing with LWJGL, the OP should be mainly concerned with Java2D until he gains enough experience.

@OP Does this game stutter for you? Is there any screen tearing?Pressing 'X' will alternate between 60FPS and max FPS. I use a busy while loop that calls Thread.yield until the sleeping period is over. At both FPS's, I don't see any screen tearing on either good computers or slow computers.

Uh, I think you have sort of become confused by what causes tearing and what causes stuttering. On Vista or 7 you can't even get tearing in a windowed display as the compositor is already vsynced. The speed of a computer also has no relevance to tearing.

In response to all the recent responses. Please stop. It's sad to watch.

Thank you for your informative posts, but please drop the condescending attitude. When dealing with human beings, it doesn't matter whether you're right, it matters that you have the skills to convey your point of view.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Interpolation does not produce apparently smooth movement. The brain already predicts where something is going to be when it's supposed to be there, and when it doesn't appear there precisely on time, no amount of interpolation fixes it. So my advice is not to use interpolation positions but instead to get everything done at an unfailingly fixed rate and hope for the best.

Unless you're in fullscreen mode, you can't rely on vsync. But when you can rely on vsync, you're waiting on the correct side of the graphics card. You will get absolutely perfect 60hz displays with not a stutter in sight. That is what vsync is for. All that confusing stuff about command buffers and so on - no-one really needs to know! All devs need to know is: go fullscreen, turn vsync on, and that's the best you can do.

Cas

I don't really agree with you about interpolation, but lets drop it before it gets out of hand. And no, the primary reason for VSync to exist is to prevent tearing, which it does to 100%. With VSync, you will still get occasional stuttering if you get 65-70 FPS without VSync. Even though the game should be able to always produce 60 FPS, with just a margin of 5 FPS you're pretty sensitive to external factors, which may cause you to miss some trains. Jesus, I'm gonna be called Trainman soon.

Although most here are talking about syncing with LWJGL, the OP should be mainly concerned with Java2D until he gains enough experience.

@OP Does this game stutter for you? Is there any screen tearing?Pressing 'X' will alternate between 60FPS and max FPS. I use a busy while loop that calls Thread.yield until the sleeping period is over. At both FPS's, I don't see any screen tearing on either good computers or slow computers.

Sorry if I'm jumping in here, but I can't see any stuttering at all here due to the irregular movement. What I can see however is rounding errors. You jump higher when you have 1.5k FPS.

btw - it irritates me greatly that movie framerates don't match monitor framerates But then, coz I've been working in broadcast video engineering for quite a while, little things like this really grate and stand out for me. I can't even watch DVDs or normal TV without the MPEG artefacts irritating the hell out of me!

Cas

24 FPS videos irritate me too, because have way too low frame rate. I can't see any stuttering between these frames though. You do realize that the stuttering is about a lot more subtle compared to what you get in the bouncing box demo, right? If you can see that stuttering, I feel sorry for you.

In response to all the recent responses. Please stop. It's sad to watch.

Thank you for your informative posts, but please drop the condescending attitude. When dealing with human beings, it doesn't matter whether you're right, it matters that you have the skills to convey your point of view.

I tried to convey it, both with long explanations and with shorter statements. Sorry for that last post though, I'm getting tired (as in sleepy).

Why are you guys so sensitive to this? I mean, your TVs have refresh rates of 60FPS, but movies are stored in 23.976 FPS. How can your screen handle that. IT CAN'T. It simply shows the same frame for either 2 or 3 updates, to achieve somewhat smooth movement. I bet you didn't even know that, and have never been bothered by it.

Things that won't solve this kind of stuttering: - Better sleep precision than what we have right now. - Newer more advanced game loops and delta handling than those in the game loop thread. - Syncing everything perfectly to 60 Hertz.

If you try any of these, you're syncing on the wrong side of the graphics card.

There is no way of completely getting rid of this stuttering. It is simply put an inherent flaw of computers running more than one process and one thread, your graphics card having a command buffer, your graphics card being used by more than one thread at a time and your monitor being imperfect, plus lots of other things.

For all I know, this may be the case; but, if so, and it really does only matter on the hardware, then there's still the ever-present question: Why are Game Maker games fine?

Although most here are talking about syncing with LWJGL, the OP should be mainly concerned with Java2D until he gains enough experience.

@OP Does this game stutter for you? Is there any screen tearing?Pressing 'X' will alternate between 60FPS and max FPS. I use a busy while loop that calls Thread.yield until the sleeping period is over. At both FPS's, I don't see any screen tearing on either good computers or slow computers.

I can't currently test this right now, but if I remember correctly I didn't see any stuttering. However, it was a little difficult to be sure if there was or wasn't any stuttering/tearing. This is because (again, if I remember correctly) the gameplay is pretty fast, it's all vertical movement, and the movement isn't at constant speed, and all of those factors make it harder to see if there is or isn't stuttering.

EDIT: ra4king, perhaps you could make one of those sprites-moving-side-to-side examples with your method? Also, could you perhaps post your game loop and rendering code?

Why are you guys so sensitive to this? I mean, your TVs have refresh rates of 60FPS, but movies are stored in 23.976 FPS. How can your screen handle that. IT CAN'T. It simply shows the same frame for either 2 or 3 updates, to achieve somewhat smooth movement. I bet you didn't even know that, and have never been bothered by it.

Things that won't solve this kind of stuttering: - Better sleep precision than what we have right now. - Newer more advanced game loops and delta handling than those in the game loop thread. - Syncing everything perfectly to 60 Hertz.

If you try any of these, you're syncing on the wrong side of the graphics card.

There is no way of completely getting rid of this stuttering. It is simply put an inherent flaw of computers running more than one process and one thread, your graphics card having a command buffer, your graphics card being used by more than one thread at a time and your monitor being imperfect, plus lots of other things.

For all I know, this may be the case; but, if so, and it really does only matter on the hardware, then there's still the ever-present question: Why are Game Maker games fine?

Although most here are talking about syncing with LWJGL, the OP should be mainly concerned with Java2D until he gains enough experience.

@OP Does this game stutter for you? Is there any screen tearing?Pressing 'X' will alternate between 60FPS and max FPS. I use a busy while loop that calls Thread.yield until the sleeping period is over. At both FPS's, I don't see any screen tearing on either good computers or slow computers.

I can't currently test this right now, but if I remember correctly I didn't see any stuttering. However, it was a little difficult to be sure if there was or wasn't any stuttering/tearing. This is because (again, if I remember correctly) the gameplay is pretty fast, it's all vertical movement, and the movement isn't at constant speed, and all of those factors make it harder to see if there is or isn't stuttering.

EDIT: ra4king, perhaps you could make one of those sprites-moving-side-to-side examples with your method? Also, could you perhaps post your game loop and rendering code?

Care to drop a link or create a program that is exactly the same to this one but made in Game Maker?

Note that I don't know exactly how Game Maker works internally, but it seems like it employs a fixed timestep.

This example actually DOES stutter on my laptop... ha ha. But I had already observed a little bit of that going on; I have yet to test it on our desktop, on which the differences seem to be most apparent between GM and Java. Specifically, on my desktop GM seems to run more smoothly than on my laptop, and Java seems to run less smoothly. I'll try to report on that later.

Why are you guys so sensitive to this? I mean, your TVs have refresh rates of 60FPS, but movies are stored in 23.976 FPS. How can your screen handle that. IT CAN'T. It simply shows the same frame for either 2 or 3 updates, to achieve somewhat smooth movement. I bet you didn't even know that, and have never been bothered by it.

Risking sounding like an idiot, does this mean that if you settle for and intentionally update your game every 50 seconds, ie less than your screen refresh rate (which is usually 60hz), you would get smooth frame transitions like in films? And if not, why not? Short dummy explanation please:)

[size=8pt]Also interesting note, Peter Jackson is filming his new movie in double the fps ie 48fps. The day when movies will run in higher fps, rather than increased pixels, is coming!:)[/size]

Another point @theagentd, I never experienced stuttering in my Super mario games on my SNES - why shouldn't Java be capable of doing the same? Is there a reason it doesn't, or did my SNES games actually DO stutter and I've simply not noticed it?

@OP Does this game stutter for you? Is there any screen tearing?Pressing 'X' will alternate between 60FPS and max FPS. I use a busy while loop that calls Thread.yield until the sleeping period is over. At both FPS's, I don't see any screen tearing on either good computers or slow computers.

On my laptop I get greatly visible stuttering. When I press X however, it's really smooth.

Another point @theagentd, I never experienced stuttering in my Super mario games on my SNES - why shouldn't Java be capable of doing the same? Is there a reason it doesn't, or did my SNES games actually DO stutter and I've simply not noticed it?

Basically: PC Game Programming and Console Programming are very different things. When programming for a console you know the exact hardware and it will be the same hardware every time - this allows you to write very low level code that works perfectly with this hardware - but not at all with other hardware.

Which is why I would rather program console games ;D

John Carmack said this even about Rage, that it was easier to get Rage running at 60 fps on the consoles than it was on the PC, because of the way ID Tech 5 and especially Mega texture uses the memory, and that pc drivers for memory and video card are written so that they work with many different things - which doesnt allow, what he always calls "aggressive high performance operations" - because of too much driver overhead

Note that I don't know exactly how Game Maker works internally, but it seems like it employs a fixed timestep.

This example actually DOES stutter on my laptop... ha ha. But I had already observed a little bit of that going on; I have yet to test it on our desktop, on which the differences seem to be most apparent between GM and Java. Specifically, on my desktop GM seems to run more smoothly than on my laptop, and Java seems to run less smoothly. I'll try to report on that later.

So I tested this on my desktop and there is some stuttering, but I *think* it happens less often than with Java. When it does happen in the Game Maker example, it seems to be a slightly different sort of stuttering; it's more... "minuscule"? And the stuttering in Java is more "jarring." Also, it seems that my Java programs have a harder time maintaining an (reported) FPS of 60 (that is, on my desktop; on my laptop 60 FPS is usually maintained, I think).

Another point @theagentd, I never experienced stuttering in my Super mario games on my SNES - why shouldn't Java be capable of doing the same? Is there a reason it doesn't, or did my SNES games actually DO stutter and I've simply not noticed it?

Basically: PC Game Programming and Console Programming are very different things. When programming for a console you know the exact hardware and it will be the same hardware every time - this allows you to write very low level code that works perfectly with this hardware - but not at all with other hardware.

Which is why I would rather program console games

John Carmack said this even about Rage, that it was easier to get Rage running at 60 fps on the consoles than it was on the PC, because of the way ID Tech 5 and especially Mega texture uses the memory, and that pc drivers for memory and video card are written so that they work with many different things - which doesnt allow, what he always calls "aggressive high performance operations" - because of too much driver overhead

By the way, I'm totally going for an SNES/GBA sort of feel with the stuff I want to make. I can understand that the programming would be different between consoles and PC, though. I wonder if Nintendo will ever support indie games.

Note that I don't know exactly how Game Maker works internally, but it seems like it employs a fixed timestep.

I exp lots of stutter of the slow moving characters, I think this is because of rounding errors and could easily be fixed by enabling interpolation in GM. (In Game Options inside GM)

The high speed ones, ( like the one at the bottom ) is really smooth. However, I do believe, by careful examination, that it experienced stuttering as well. But very little compared to the two Java versions you posted (on the TIG forum). Using double buffering on your Java programs, however, reduced the stuttering phenomenally ( as you would expect ) and I would argue that the GM game and your Java examples with Double buffering produce the same quality of stuttering.

Note that I don't know exactly how Game Maker works internally, but it seems like it employs a fixed timestep.

I exp lots of stutter of the slow moving characters, I think this is because of rounding errors and could easily be fixed by enabling interpolation in GM. (In Game Options inside GM)

The high speed ones, ( like the one at the bottom ) is really smooth. However, I do believe, by careful examination, that it experienced stuttering as well. But very little compared to the two Java versions you posted (on the TIG forum). Using double buffering on your Java programs, however, reduced the stuttering phenomenally ( as you would expect ) and I would argue that the GM game and your Java examples with Double buffering produce the same quality of stuttering.

Thank you for your feedback. You say "using double buffering"... Isn't that something that the programmer uses? Like, with the BufferStrategy class? Game Maker and my Java programs all should be implementing double buffering whether the player likes it or not...

Thank you for your feedback. You say "using double buffering"... Isn't that something that the programmer uses? Like, with the BufferStrategy class? Game Maker and my Java programs all should be implementing double buffering whether the player likes it or not...

That's true. However, in the two examples you posted on the TIG forum you let the user choose, before the application launches, if he wants to use Double buffering or not... right? o.O

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