Player sprite just doesnt move smooth?

Game Play & Game Design
#21

So why don’t you enlighten us all and provide a simple applet that renders a moving image or tilemap without hickups?
Btw, this is not about Android / J2ME/BlackBerry.

#22

all sounds a bit gey. I was wondering why everything did this, its really noticable in my windowed but fullscreen sized game :confused:

#23

Try to avoid using sleep(). Use update(delta).

#24

I would like to give you my AllBinary Platform to make life easier, but I need to find funding first.

What I can say is lots of things can cause it, but in general it is a code performance issue(s) in your own code. The problems include:

Thread.sleep needs to change to lower times when you have longer running frames and such
Creating to many objects causing gc to run during gameplay
Getting the system time to many times
Long running paint methods
Long running frame processing

Note: Applets are a little slower so if the lag is barely noticeable then you might remove what little lag you have left by just using JNLP or getdown.

#25

You really need your libraries to write a 20 lines long applet which moves a filled circle?
Hm… sounds like an excuse

#26

I made a simple test with processing (javascript)

http://www.krautsoft.com/html5/incubator/Moving/index.html


void setup() {
	size(800,600);
	frameRate(60);
}

void draw() {
	background(150);
	int m=millis();
	int amount=50;
	for(int i=0;i<amount;i++){
	int n=m/(i+1);
	ellipse(n%width,height*i/amount,20,20);
	}
}

Please take that code (for free!!!) and make a butter smooth applet. ;D

#27

No, but why would I. A game != a filled circle

#28

So… you don’t want to prove your awesome statements/skillz? This would be a great opportunity to show off your AllBinary Platform.

#29

As stated in another thread (that’s lost for me), switching from Thread.sleep to Thread.yield has solved this problem for several people.
Also, small stuff, if you’re running in a JFrame, use an empty RepaintManager (since you’ll be using active rendering anyway),

  • which pipeline are you running with? I just booted some old Java2D games I wrote some years ago, and I have no stuttering. (They use the OpenGL pipeline for Java2D). Beyond that, and the fact that I use Thread.yield instead of Thread.sleep, the games wary hugely in both design and form, yet none of them stutter.
#30

If ten more persons come and claim they can animate a moving circle/rectangle without stuttering… I think I have to believe it. Why it is so complicated just to prove it and give a minimal example so that we all can learn from the rendering loop?
Doesn’t seem to be that simple…

#31

My point was that my rendering loop is nothing special whatsoever, except that it uses Thread.yield() instead of Thread.sleep()

#32

I use yield() these days still. sleep() just too unreliable.

Cas :slight_smile:

#33

I never ever used .sleep(), always .yield()

and its just not a code issue: this behavior only occurs on the DirectX pipeline. Using the OpenGL pipeline forces even a windowed game to VSync when using bufferedstrategy.
in that case, when using opengl, I obviously don’t even need my game slow down class; since its automatically vsynced.

no screentearing ever on opengl. obviously that pipeline has so many problems…

this is my experience with java2D + pipelines… my engine is switching to lwjgl soon; I hope it will be gone alltogether.

here is how I do the slow down: (btw Awt.Toolkit.sync() results in abysmal slowdowns)


public class FrameSkipper
{
    private int fps;
    private long timeThen;

    public FrameSkipper(int frameRate)
    {
        fps = frameRate;
        timeThen = System.nanoTime();
    }

    public void changeFPS(int frameRate)
    {
        fps = frameRate;
    }

    public void sync()
    {
        long gapTo = 1000000000L / fps + timeThen;
        long timeNow = System.nanoTime();

        while (gapTo > timeNow)
        {
            Thread.yield();
            timeNow = System.nanoTime();
        }

        timeThen = timeNow;
    }
}

so you initialize with the FPS you want, and then just call sync every frame.

also note: I currently do not use any threads; I would like to maintain a frame based synced game, which should be entirely possible (like your standard C++ game)

#34

I would love to see this also.

old thread but still a problem.

#35

I see a similar problem in our OpenGL Application in windowed mode but we think it’s because we aren’t using linear interpolation when we render, so every second or so (pretty predictable, depends on updates/second), we get a slight stutter where everything seems to “shift” and “snap back” while moving the character from side to side.

Trying really hard to discern whether this is due to some vertical sync issue, loop timing, or lack of interpolation.

We use Phys2D with a fixed timestep.

#36

On Windows, the compositor will drop frames since it doesn’t seem to sync up with OpenGL the way it does with DirectX. Just a simple bouncing box will occasionally make a jump due to a dropped frame. It’s still the same actual speed, but the discontinuity is very visible. I don’t know any way around this annoying behavior other than disabling aero or running fullscreen.

#37

We now enable vsync and run in full screen which produces the optimal results with our fixed timestep - no screen tearing, and no stuttering, looks like a knife through butter.

#38

When I use LWJGL (which uses OpenGL) I just turn on VSync and interpolate the movement of the sprite. Works great.