Yeah, so with the computers I’ve tested, the only computer on which I get stuttering even after applying the extra sleeping thread method is the computer on which the Game Maker example stutters. How has the GM example been running for you?
Also, I suspect that the stuttering only seems to get worse with less going on— in other words, it’s just less noticeable with more going on, and doesn’t actually yield stuttering any less. But I haven’t really tested this guess precisely.
minimal stuttering, 100x times better than Cas’ method (which my game is using right now)
I dont think thats it. See - I have a side scroller, which makes it really apparent when walking in one direction.
Also I cannot capture it. Using FRAPS the stuttering disappears when recording - further confirming my theory
Fraps capture individual frames, like if you did a readback to the CPU after each Display.update() on LWJGL. Even if the frame doesn’t actually end up on the screen due to the asynchronous behaviour between your CPU, your GPU and your monitor, Fraps will still capture it.
Using OpenGL and the desktop window compositor you are never going to be rid of stuttering, end of story. Gamemaker directly interfaces with the DWC because it uses DirectX. It’s a Windows fail. The only ways around it are: go fullscreen or turn off DWC or go back to Windows XP.
Cas 
btw Saucer, did you try libgdx because of the stuttering ? was just curious, never used it before
No, I haven’t. Is it pretty widely used?
Absolutely.
LWJGL along with libgdx are 2 big engines, although different.
Pretty sure in JOGL you would have to do it all yourself, and I hear libgdx is a little more high level than lwjgl.
So i guess it has something like this aswell.
LWJGL is not an engine, just a simple binding to OpenGL, OpenAL and OpenCL, so pretty low level. LibGDX has a lower and higher level API and uses LWJGL underneath for its desktop versions.
Wait, I looked a little bit into libGDX: apparently it uses some C/C++ (= “native code”?)? Anyone know the details of what that does for libGDX?
Make it’s faster. There is example native box2d wrapper, bullet wrapper is coming. Lot of bytebuffer stuff etc. There is native code in every openGl wrapper too.
User don’t have use any native code so it’s hided from the end user pretty well.
…Wait yeah, you’ve brought up a good point: LWJGL, for example, uses native code, too! Hence the DLL. Oops. Thank you for the input, pitbuller.
yeah the point here was LWJGL has its own slowdown mechanism, Display.sync; not sure exactly, but I would guess JOGL doesn’t. And wasn’t sure libgdx exclusively uses LWJGL, I seem recall a JOGL option and stuff.
libGDX has a JOGL and LWJGL backend for desktop.
yes, so it would be interesting to see libgdx using JOGL syncing a gameloop @ 60 fps, if libgdx has a sync method, which I would guess it does
although most people will argue that it wont make a difference; just curious though
Yeah, I’m also wondering about issues like this, and whether engine-specific native code yields any significant difference in efficiency or speed. But I guess those are questions we could ask about any engine, not just libGDX. Anyone know the specifics?