next »

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

[Chromanoid]

The effect of interpolation should be more visible if your visible framerate is faster than the update rate or out of sync. Currently you use 60hz for updates and drawing which decreases the need for interpolation.

[rivon]

Well I have a (somehwat) fast computer and vsync has worked always AFAIK. Athlon X2 @ 2.9GHz + GF 9600.

And, of course not using 'sleep' causes stress on the CPU because it just computes and draws and stuff all the time. Cause the apps are written like that. That's why you limit FPS. So it doesn't do it all the time.

[lasttea999]

The effect of interpolation should be more visible if your visible framerate is faster than the update rate or out of sync. Currently you use 60hz for updates and drawing which decreases the need for interpolation.

Ah, thank you. Please forgive my ignorance!

Well I have a (somehwat) fast computer and vsync has worked always AFAIK. Athlon X2 @ 2.9GHz + GF 9600.

And, of course not using 'sleep' causes stress on the CPU because it just computes and draws and stuff all the time. Cause the apps are written like that. That's why you limit FPS. So it doesn't do it all the time.

Yup! Thing is, Slick2D seems, by default, to draw very fast, so I don't know why I'd have problems with doing the same in LWJGL. I haven't really observed how computers react to Slick2D games, though.

---

Well, I can think of a few more things we could try, but... I dunno. If we really have ruled out all those possible causes we've encountered so far, then I don't know what the problem could be. Is it really just that Game Maker involves more "native" code (am I expressing that accurately?) than Java, as I think someone mentioned earlier in this thread? Does Java do too much under the hood, as a TA at my university (I think) once told me? Does C++, Flash or Python fare any better?

What's strange to me about this problem is that it seems too fundamental and well-known a problem for us to have gone this long without having had someone pop in and say, "Oh, we dealt with this ages ago, everyone knows how to deal with that! Here's your solution!" Are we overlooking something completely ordinary here...?

[Geeze]

Java does garbage collecting on background - maybe that's one of the reasons? I'm also working on a slick2d project but in a very very early stage so I can't say a thing about stuttering.

[rivon]

Well, the stuttering in cas, delventhal and gafferongames was big like 5-10px which means that the framerate dropped dramatically (high frametime) so something processor-heavy must have happened - just like if GC has kicked in or something. But when nothing like this is happening, then all the examples behave quite equally IMO (at least 90% equally) so really the different timesteps aren't behaving much differently. So I'm sticking with pos = velocity * dt; :D