next »

[Chromanoid]

Another issue is, should I start a new topic, or should I just reply to one of the threads we've mentioned? (Either way it'll be my first post at JGO. :O)

A new topic. And refer to Slick or if you get it stuttering LWJGL/JOGL to fire the people up :D.

[lasttea999]

Another issue is, should I start a new topic, or should I just reply to one of the threads we've mentioned? (Either way it'll be my first post at JGO. :O)

A new topic. And refer to Slick or if you get it stuttering LWJGL/JOGL to fire the people up :D.

Alright, I think I'll do this once I prepare a massive case, then; I don't want the new topic to be a repeat of the four or five existing threads. Lots of evidence to gather. Maybe I'll name the thread "Solving Stuttering Once and for All"...

[lasttea999]

Alright, I think I'll do this once I prepare a massive case, then; I don't want the new topic to be a repeat of the four or five existing threads. Lots of evidence to gather. Maybe I'll name the thread "Solving Stuttering Once and for All"...

Well... here we are!

http://www.java-gaming.org/topics/solving-stuttering-with-fixed-timesteps-once-and-for-all/24975/view.html

Please feel free to contribute to this new thread, or to continue contributing to the current one; I feel that input would be useful from perspectives both inside and outside the Java community.

[lasttea999]

Hello everyone, it's been a while! Allow me to report on some things I've been learning since the JGO thread was started.

So currently I know of at least 10 different versions of the fixed timestep loop--- all from various sources, some of those sources being examples of code that people (like Chromanoid) have submitted here and in the JGO thread--- so I prepared three different versions of the LWJGL example someone called Cero posted in the JGO thread, each of which incorporates one of the different fixed timestep code examples.

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.

Here's what I discovered:

-With certain settings, the stuttering can be improved pretty well on all tested computers (at least one school computer, our desktop, and my laptop).

-Rendering as fast as possible seems to yield fairly smooth graphics, but it seems that our desktop and my laptop have difficulty with that kind of rendering (I can't tell if it's difficult for the computers at my school).

-I finally saw that LWJGL's vsync actually does have an effect, and yields some of the smoothest rendering I've seen yet! (That is, with Java.) ...However, although this smooth rendering was achieved on a computer at school, it doesn't seem to work on our desktop or my laptop. In fact the API documentation for LWJGL says:

[About Display.setVSyncEnabled:] This call is a best-attempt at changing the vertical refresh synchronization of the monitor, and is not guaranteed to be successful.

That being said, I think at least one particular setting on one example may yield suitably smooth rendering all around: example_delventhal.zip without Display.sync, with yield and sleep, and without frequent yield and sleep. It still stutters with those settings, but, if I'm not mistaken, it only stutters a little more than does the Game Maker example.

Admittedly, I don't know how this setting fares on a computer on which vsync works; it may have to be turned off on such computers. But then again, on such a computer, vsync might yield smooth rendering on its own.

[lasttea999]

Sorry (again?) for posting so many times in a row...

That being said, I think at least one particular setting on one example may yield suitably smooth rendering all around: example_delventhal.zip without Display.sync, with yield and sleep, and without frequent yield and sleep. It still stutters with those settings, but, if I'm not mistaken, it only stutters a little more than does the Game Maker example.

Looks like I spoke too soon:

I had already known that, sometimes, our desktop (which usually yields the most visible stuttering) runs the Java programs I've been testing pretty well for some reason; but only for a while, and in a currently unpredictable manner. Even the Java2D builds run smoothly in this situation! It seems that this had been the case when I was testing my LWJGL examples earlier, because yesterday they seemed to yield lots of stuttering...

Admittedly, I don't know how this setting fares on a computer on which vsync works; it may have to be turned off on such computers. But then again, on such a computer, vsync might yield smooth rendering on its own.

Looks like the program runs just fine under these particular settings, at least as far as I can tell.

By the way: currently, the only way I know how to test if vsync has an effect is to turn off Display.sync (and frequent yielding and sleeping) and see if toggling vsync does anything. On my school's computers the FPS drops from several hundred (without vsync) to 60 (with vsync), whereas on our desktop and my laptop the FPS seems to stay at several hundred regardless of the state of vsync reported by the program.

Also, I'm still not really sure about the following point, which I presented in the JGO thread:

I guess it's also possible that the smooth rendering that seemed to be achieved with vsync on the computers at my school could only have been achieved with the speed of those computers (they seem pretty fast).

In other words, I don't know if my programs might still yield stuttering on other computers for which vsync has an effect; it could just be that, as usual, the main reason my programs run smoothly on my school's computers is that they're fast (or more powerful in some other fashion).

[lasttea999]

Added three new examples based on code by Cas, Notch and Tommy: box.net download (Note: haven't tested these much yet)

Still haven't made it so the programs detect the refresh rate of the display.

[Chromanoid]

  thanks for your persistence! fyi i read all your updates.

ps: gm example is smooth, the rest is *not* -.-

[lasttea999]

Thanks for your continued support, Chromanoid! Please feel free to chime in if you see any issues with my updates!

[moi]

hello, I just read the first post, but you'll never have a totally smooth experience with fixed timesteps

[Chromanoid]

With interpolation you should?

[moi]

Idk I experimented with 60fps fixed timesteps in XNA and the choppyness was really noticeable, it totally disappeared once I switched to variable timestep.
I reckon it could be a bug in my engine but it was some rather simple stuff.

[Chromanoid]

I think it was missing interpolation in your case...

You can look at what lasttea999 put together for stuttering analysis: http://www.box.net/shared/79ya5iejatbnl76hm3u2
There is also a variable timestep loop that stutters at least on my pc...

[moi]

another point: you otice stuttering more easily on a simple animation (on sprite for example) than on a complex scene with many objects

[Chromanoid]

Yeah! But it's depressing, that the GM thing looks so smooth

[lasttea999]

hello, I just read the first post, but you'll never have a totally smooth experience with fixed timesteps

For this, consider:

[...] the GM thing looks so smooth

and Game Maker, as far as we can tell, employs fixed timesteps. Also this:

There is also a variable timestep loop that stutters at least on my pc...

although I'm not very familiar with variable timestep loops, so there could be a greater chance that I prepared a faulty implementation.

I dunno, recently I seem to have observed that the GM example actually stutters more than I had thought. I think it's usually better than the Java examples and all around GM's the most consistent, but currently I suspect that:

-When GM stutters it can be more noticeable than some Java implementations? Especially on (only on?) those computers on which LWJGL's vsync can take effect.

-GM usually tends to run smoothly for longer periods of time than the Java examples, but not? on those computers for which the Java examples don't stutter (i.e. my school's computers). Furthermore, on those computers GM seems to alternate between no stuttering and stuttering more frequently than the Java examples.

(Although... note that most if not all of my observations throughout both this thread and the JGO thread are basically subjective...)

Also, another issue: While the simple GM example stutters on those school computers, I had difficulty detecting any stuttering (there was some stuttering, but very little of it) with the demo for a game of mine, Platform Battle 2. In fact I think this might also have been the case during some trials on our desktop (although Java stutters on it). This may have something to do with the implementation:

-With the simple example, nothing is scaled and the box is moved at 2 pixels, whereas, in PB2, although the object I observed (a moving platform in the tutorial) still moves at 2 pixels, the graphics are scaled to two times its "actual" size by a method by ChevyRay.

-PB2 uses a sprite for the platform and has a patterned background. (I do, however, think that I looked pretty closely...)

EDIT: Everyone, feel free to provide similar examples written in any other language; I'd like to see if C++ with OpenGL or DirectX fares any better! I think GM, by the way, was written in a language called Delphi?

[rivon]

Just get used to the fact that you CAN'T make a stutter-free game unless it's running at 200+ FPS on 200+ FPS screen. Everything slower will stutter for someone and not for someone else. It doesn't matter if its variable or fixed timestep. Also it doesn't matter which technology you use.
If you're stuck with 60fps screens for some people it will inevitably stutter no matter how hard you try.

[lasttea999]

Just get used to the fact that you CAN'T make a stutter-free game unless it's running at 200+ FPS on 200+ FPS screen. Everything slower will stutter for someone and not for someone else. It doesn't matter if its variable or fixed timestep. Also it doesn't matter which technology you use.
If you're stuck with 60fps screens for some people it will inevitably stutter no matter how hard you try.

I could totally understand that... that is, again, if stuff made with Game Maker didn't run smoothly on every computer on which the Java examples didn't.

Perhaps you haven't read some of our other posts (which is understandable; this has become a pretty long thread!). With Java we've tried updating the screen as fast as possible so that, even if the screen can't actually show more than X frames per second, it won't miss any frames. But even that doesn't let the program run as smoothly as the Game Maker program, and furthermore, while some computers experience difficulty running Java with that method--- my laptop starts whining loudly, and while other computers don't behave quite as dramatically as my laptop, they still do make various sounds that are clearly different from when employing other methods--- no GM test program has come close to making a computer behave this way (except perhaps when the program starts up).

[moi]

GM is all fun and games until starts fucking up your scrolling with tearing

[rivon]

I tested the examples. Results:
GM and example_simple - perfect
variablestep and tommy - almost perfect
notch - not so bad
chromanoid - bad
cas, delventhal, gafferongames - very bad

lwjgl - didn't run (missing manifest or something)

Turning vsync or display.sync or both off was bad I think in all of the cases. Yield and sleep didn't have much effect and interpolated drawing was probably a tiny bit better but it made almost no effect.

[lasttea999]

Thanks for your feedback, rivon!

I tested the examples. Results:
GM and example_simple - perfect
variablestep and tommy - almost perfect
notch - not so bad
chromanoid - bad
cas, delventhal, gafferongames - very bad

Turning vsync or display.sync or both off was bad I think in all of the cases.

Yeah, your results seem to suggest that you either have a fast computer or a computer one which vsync works, I think. I say this because of the following:

Yield and sleep didn't have much effect

On a slow (?) computer, if vsync doesn't work, not having yield and sleep tends to put stress on the CPU or something. Did the FPS stay around 60 (or whatever your monitor's refresh rate is) with vsync but without Display.sync and yield and sleep? If so, it probably means your computer is one on which vsync works. I wonder why this differs among computers?

Also, in my experience Display.sync (without vsync, if vsync works) makes things run a bit strangely on all tested computers.

lwjgl - didn't run (missing manifest or something)

Sorry, perhaps I should have mentioned this somewhere; lwjgl is a library so it's not supposed to run.

interpolated drawing was probably a tiny bit better but it made almost no effect.

You know, this is kinda how I feel, so I'm wondering if I implemented interpolation properly.