next »

[lasttea999]

What!!! D: Currently all this code isn't stuttering much? (Although I haven't tested on any slow computers yet.)

Well, I guess we gave it a good try, though. Thanks again for all your help.

[Chromanoid]

I just tried this Vsync stuff from the website with my program. The periodic stutter did not go away. Maybe I did something wrong, but be prepared

[lasttea999]

I see. By the way, in your code, what caps the FPS? I kept getting something like 80 or 90 FPS with your example, but something like 60 with my code + your code. Does that result from how fast the program is able to draw everything?

[Chromanoid]

Yes I think so. It may depend on OS etc. too.
Does it stutter with 60fps/your code?
if yes this might be the reason behind it:

I think there are some problems/bugs refreshing the painted component. Bombarding Java[2D] with screen updates seems to help with this issue.

By the way, in your code, what caps the FPS?

It sleeps until the desired time per step has passed.

Code:

  //in main
  game.start(1 / 120d, 5); //1/120=fixed time step, 5=maximum steps to keep up with real time when one frame took more than 1/120 seconds
  //...
  public final void start(final double fixedTimeStep, final int maxSubSteps) {
    //...
    long step=(long)Math.floor(1000000000d * fixedTimeStep); //time of one step in nanos
    //...game loop/update stuff
        while (true) { //sleep loop (1ms sleep per loop because sleep is not very precise)        
                Thread.yield(); //yield (don't know if it's useful. just thought it might increase precision, because we let other threads do their work and might not need to sleep after that.)
                long delta = start + step - System.nanoTime();
                if (delta <= 0) { //when delta is <=0 we go to the next step (maybe 1000000ns would be a better value for comparison because we wait for this timespan)
                    break;
                }                
                try {
                    Thread.sleep(1);
                } catch (InterruptedException ex) {
                }
            }

[lasttea999]

Thanks again for all your help. One of these days I might post a comment summarizing all of the links and stuff we've gathered here.

[lasttea999]

I feel that interest in this topic has waned, but allow me to make brief reports about recent developments.

I had thought that, currently, the most suitable option was the JGO loop; however, I found that that method (or at least, my implementation of it) seems to yield stuttering not only if there's too much being drawn (as with any program) but also if there's not enough being drawn, which seems kind of unreliable to me. For example I found that, in the current implementations of game_test and simple_test, the stuttering seems to be worse in simple_test, even though there seems to be less going on. The stuttering improved when I drew more things.

Alternatively, it may have something to do with not drawing enough strings, although I don't see why that would be the case.

EDIT: Just found that, in an older version of simple_test, there doesn't seem to be as much stuttering as the current version. I wonder what modifications could have yielded these results...

Also, finally tried Slick2D. Some of the examples seem to work nicely, but from what I've seen, Slick2D is meant for use with variable timesteps. In my own experiments, however, I've tried both a pure variable timestep and a fixed timestep (within the variable timestep?), and both seem to stutter. However, I've only just started trying things out with Slick2D; also, I don't think I implemented interpolation properly, so I guess the stuttering is to be expected.

[Bryant]

This thread is of great interest to me Thanks for keeping the conversation going, lasttea. I wish I had more to contribute, but I can't seem to get around fixed timestep stuttering either. 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.

Have you seen this thread over on the XNA forums? It seems this guy got around the problem by syncing the update rate to the screen's refresh rate. I haven't been able to test it, but it sounds reasonable.

[lasttea999]

This thread is of great interest to me Thanks for keeping the conversation going, lasttea.

Thank you!

Have you seen this thread over on the XNA forums? It seems this guy got around the problem by syncing the update rate to the screen's refresh rate. I haven't been able to test it, but it sounds reasonable.

Actually I haven't seen this, and unfortunately I might not be able to check this link out for a while (I'm a little busy at the moment), but if I understand correctly, "syncing the update rate to the screen's refresh rate" sounds precisely like the problem that seems to be causing the stuttering with Java--- one that, according to one of Chromanoid's links, Java currently has no solution for.

Actually, if the solution in your link doesn't involve anything exclusive to XNA (or anything that Java doesn't have), then it'll help greatly... Seems like a great contribution to me!

[Bryant]

His code relies primarily on this line right here:

Code:

refreshRate = (float)GraphicsAdapter.DefaultAdapter.CurrentDisplayMode.RefreshRate;

I guess XNA gives you the ability to ask the GPU how often it refreshes the screen. There's no equivalent in the Java framework you're using?

[Chromanoid]

@lasttea999 Did you try http://slick.cokeandcode.com/javadoc/org/newdawn/slick/GameContainer.html#setVSync(boolean) ?

[lasttea999]

His code relies primarily on this line right here:

Code:

refreshRate = (float)GraphicsAdapter.DefaultAdapter.CurrentDisplayMode.RefreshRate;

I guess XNA gives you the ability to ask the GPU how often it refreshes the screen. There's no equivalent in the Java framework you're using?

I think I heard that there isn't an equivalent... I guess I haven't checked directly, though; maybe there is one. I'll try to look into this.

EDIT: Ooh! http://www.exampledepot.com/egs/java.awt/screen_ScreenBits.html (Note: haven't investigated this closely yet)

Is that all that's required to emulate the XNA example?? If so...

@lasttea999 Did you try http://slick.cokeandcode.com/javadoc/org/newdawn/slick/GameContainer.html#setVSync(boolean) ?

I did, and it didn't seem to do much. Still, I'm a bit skeptical about my Slick2D experiments--- they were brief and rushed--- so I may have done something incorrectly. However, I think I vaguely remember hearing that setVSync() only works in fullscreen applications?

EDIT: Don't know how credible this source is, but: http://www.gamedev.net/topic/372033-java2d-vsync/page__view__findpost__p__3459925

EDIT EDIT: Wait, I guess that last link has nothing to do with OpenGL (LWJGL, Slick2D), huh...

[lasttea999]

So I looked at the XNA thread; it seems pretty interesting. I haven't tested anything yet, though, and unfortunately I'm finding the code kind of difficult to understand (mostly the XNA-specific stuff). I think it might be the case that the OP's example isn't doing anything Java can't do, though.

I wonder if it would be possible to contact the OP and ask for a pseudo-code version of his example that could apply to multiple programming languages...

Now, let me briefly summarize where I think we currently are:

0) Potential non-solution from the XNA forum thread Bryant Drew Jones linked to:

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).

Again, this stuff sounds kinda plausible, but I think there's one thing this doesn't account for: GM running more smoothly than Java.

1) Potential solution from the XNA forum:

[...] implement the classic slowdown syndrome present in all the old school consoles that merely called WaitForRetrace() at the end of each frame to synch to the TV's refresh.  If the frame's update code took too long and missed a retrace, then it'd wait for the next one, and the game would suddently drop to 30 fps.  Bad, yes, but at least every frame is being processed and SEEN by the gamer.  This is better than 2 fps where 29 of the 30 frames processed is NEVER SEEN by the gamer.

I think this kinda related to what one of the articles Chromanoid posted talks about. Doesn't the article say that Java currently doesn't have a (non-native) way to do this? By the way, this is why I made the mistake of saying Java probably couldn't check for a monitor's refresh rate; I mixed the two topics up.

2) Potential solution from the XNA forum:

The OP's example. Still don't know how it works, and therefore still haven't tested it in Java. I think this is one of the first examples we've considered that incorporates the monitor's refresh rate and a margin of error. Not quite sure how the example differs from a fixed-variable hybrid. (Getting less sure what the precise definitions of fixed timestep and variable timestep are, actually...)

3) Other solutions, which we have yet to find. Also, if I remember correctly, I still don't get much (if any) stuttering in Chromanoid's gameloop examples, but I haven't succeeded in implementing them into my own framework without seeing stuttering.

[lasttea999]

1) Potential solution from the XNA forum:

[...] implement the classic slowdown syndrome present in all the old school consoles that merely called WaitForRetrace() at the end of each frame to synch to the TV's refresh.  If the frame's update code took too long and missed a retrace, then it'd wait for the next one, and the game would suddently drop to 30 fps.  Bad, yes, but at least every frame is being processed and SEEN by the gamer.  This is better than 2 fps where 29 of the 30 frames processed is NEVER SEEN by the gamer.

I think this kinda related to what one of the articles Chromanoid posted talks about. Doesn't the article say that Java currently doesn't have a (non-native) way to do this? By the way, this is why I made the mistake of saying Java probably couldn't check for a monitor's refresh rate; I mixed the two topics up.

Found some interesting-looking articles on this topic:

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

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

http://www.java-gaming.org/topics/why-java-games-look-choppy-vertical-retrace/14696/view.html

Still haven't tested any of this, though.

[lasttea999]

EDIT: My apologies for posting so many times in a row!

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

I can't tell if my laptop has more difficulty running my program or a typical GM program, though (assuming my usual test program is typical). I'm wondering if GM actually does this sort of thing, and reports update rate rather than rendering rate for its FPS variable.

Actually, Game Maker Help says:

Number of frames that are actually drawn per second.

---

Found some interesting-looking articles on this topic:

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

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

http://www.java-gaming.org/topics/why-java-games-look-choppy-vertical-retrace/14696/view.html

Still haven't tested any of this, though.

So I tried the library Kevin Glass provides in the second link, but it's probably from around 2004, and I think it might not work with current versions of DirectX. Not that I've tried it with DirectX (I don't think my computer has it), but after having done some research, it sounds like the code relies on some sort of past version.

EDIT: Wait... All Windows computers come with it, huh. Which probably means the library doesn't work with most computers any more?

Still haven't tested the XNA forums method.

[Chromanoid]

Thanks for posting your progress! Did you try lwjgl or jogl? Maybe it's time to post at java-gaming.org there are more people with interest in java game development there. Maybe you can refer to this topic and just post a minmal code example (with slick) that does not run smooth...

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

[Bryant]

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?

[Bryant]

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?