next »

[lasttea999]

Thanks for posting your progress! Did you try lwjgl or jogl?

I have tried LWJGL in the past. Maybe it's time I give it another go?

Maybe it's time to post at java-gaming.org

Maybe, but do you think people there will be willing to pursue it beyond the two JGO threads we've referred to already? It seems like interest has waned in both threads. If so, then

Maybe you can refer to this topic and just post a minmal code example (with slick) that does not run smooth...

sounds like a good idea!

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)

[Bry]

I've had some luck by setting my update rate to a really high interval (like 200 FPS), but it's still not perfectly smooth.

I thought I had tried this with my rendering rate and perceived no improvement, but I tried again (going from 60 FPS to 120 FPS) and the stuttering seemed to improve (at least on one computer) pretty significantly. However, as with Bryant Drew Jones, it's still not perfectly smooth. What's more, I'm not sure my laptop likes it, as I've said before.

EDIT: My desktop still runs it at around 60 FPS... :O

Sorry, I meant to say that I tried setting the update loop to run at 200FPS, but the rendering would still occur at 60FPS. Here's some sample code written using Lua and LOVE2D:

Code:

function love.run()

if love.load then love.load(arg) end

local totalTime = 0.0
local deltaTime = 1 / 200

local currentTime = love.timer.getMicroTime()
local accumulator = 0.0

    -- Main loop time.
    while true do
   
    local newTime = love.timer.getMicroTime()
    local frameTime = newTime - currentTime
   
    if frameTime > 0.25 then
    frameTime = 0.25
end
   
    currentTime = newTime
   
    accumulator = accumulator + frameTime
   
    while( accumulator >= deltaTime ) do
   
    if love.update then love.update(1.0) end

    totalTime = totalTime + deltaTime
    accumulator = accumulator - deltaTime
   
    end
   
    if love.update then love.update(accumulator / deltaTime) end
    accumulator = 0.0
   
        if love.graphics then
            love.graphics.clear()
           
            if love.draw then love.draw() end
            love.graphics.present()
        end


        if love.timer then love.timer.sleep(1) end

    end

end

Unfortunately this isn't a *pure* fixed update loop. You may notice that I make one final call to update() with a fraction of deltaTime. For me, this extra step smoothed things out quite a bit. It's still not perfect, and the system is no longer deterministic. But it was a useful little experiment.

[lasttea999]

Sorry, I meant to say that I tried setting the update loop to run at 200FPS, but the rendering would still occur at 60FPS. Here's some sample code written using Lua and LOVE2D:

I knew what you meant, but I'm currently settled on a rate of 60 updates per second  I have a game I want to remake that runs at 60 updates per second, and I want to avoid getting a different "feel" to the controls by changing that rate.

It is an interesting experiment, though; thank you. I guess it stutters more at lower update rates, then?

[Bry]

Sorry, I meant to say that I tried setting the update loop to run at 200FPS, but the rendering would still occur at 60FPS. Here's some sample code written using Lua and LOVE2D:

I knew what you meant, but I'm currently settled on a rate of 60 updates per second  I have a game I want to remake that runs at 60 updates per second, and I want to avoid getting a different "feel" to the controls by changing that rate.

It is an interesting experiment, though; thank you. I guess it stutters more at lower update rates, then?

It seems to be that way. But who knows, really. The longer you stare at the jittering the less objective you get when measuring improvements

[lasttea999]

It seems to be that way. But who knows, really. The longer you stare at the jittering the less objective you get when measuring improvements

This seems to be the case in general. My own stuttering, on the other hand... It's pretty obviously visible :I

Man, there are so many discussions on this topic all over the place!

Also, some links:

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

An... enhancement request? to allow Java "to synchronize onscreen rendering with vertical retrace," I think.

http://www.java-gaming.org/topics/how-can-i-make-this-simple-game-loop-better/19971/msg/165883/view.html#msg165883

A new approach that may be complicated and different enough to have some potential to perform more successfully than our previous attempts...

EDIT: Apparently, tearing is still visible... Still haven't tested this yet, though.

Also, about testing the XNA forums method: I *may* be completely unable to test it without figuring out how some of the XNA-specific stuff works. Anyone know XNA?

[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?