anyone wish to guess why it stutters?

The executable jar is here http://www.angelfire.com/clone/wolfbane/test.jar Does anyone wish to help me figure out why this stutters. I used the discete timming step loop as described by Markus Persson, and the GAGE timer. Here is the code for the loop:

public void go() 
      {
                  
            float interpolation;
            long time;
            
            previousTime = timer.getClockTicks();
            passedTime = 0;
        
        while (true) //run until quit app
            {
                  
                  
                  interpolation = passedTime/(float)milliseconds_per_gametick;
                  
                  frametime = timer.getClockTicks();
                  
                  clientTick(interpolation);
                  
                  fps = timer.getTicksPerSecond() / (timer.getClockTicks()-frametime);

                  time = timer.getClockTicks();
                  passedTime += (time-previousTime);
                  previousTime = time;
                  
                  
                  
                  while (passedTime>milliseconds_per_gametick)
                  {
                        gameTick();
                        passedTime-=milliseconds_per_gametick;
                  }
            
            
                  
                  ////////////////////////////////////////////          
                  //check exit condition
                  if (exit == 1)
                  {
                  gd.setFullScreenWindow(null);
                  System.exit(0);
                  }
                  ////////////////////////////////////////////      
            
            }//close while animation loop
            
      } //closes the go method 


/////////CLIENTTICK///////////////////////////
      private void clientTick(float interpolation)
      {
            
            Xposition(xPlayerPos.getValue(interpolation));

            render(); //draws everything to the backbuffer            
            bs.show(); //page flip backbuffer
                  
            
            
      }      
/////////GAMETICK///////////////////////////
      private void gameTick()
      {
            float xPos = xPlayerPos.getValue(1);
            
            if (xPos >= 800 || xPos < 0)
            vx = -vx;
            
            xPos += vx; 
            xPlayerPos.setValue(xPos);
      }

      
      private void Xposition(float xpos)
      {
            xP =(int) xpos;
            //System.out.print(" " + xP);
      }

At first I thought that it was the interpolation, but I looked at the x positions and they never skip back and forth. The x is always in increments of 2 or 3 pix so that is not the cause. The value on the right is the frame rate and that does skip around and sometimes beyond the refresh rate so I think that has something to do with the stutter.

I don’t udnerstand what your interploation is about.

Arent you updating position in your game-tick?
Typical the psuedocode for a game loop like this looks something like this

LOOP
FOR (NUMBER OF ANIM TICKS SINCE LAST TIME AROUND) DoAnim();
RENDER FINAL POSITIONS;
END LOOP

I am not sure myself what the interpolation is suppose to do. I am using Markus’s code:

public class IFloat
{
      private float last;
      private float value;
      
      public IFloat()
      {
            this(0);
      }
      
      public IFloat(float newValue)
      {
            last = newValue;
            value = newValue;
      }
      
      public void setValue(float newValue)
      {
            last = value;
            value = newValue;
            
      }
      
      public float getValue(float interpolation)
      {
            return (value-last)*interpolation+last;
      }
}

I guess I should trace all this again and focus more on what is happening during interpolation. Question? If I wish to have real time based movement (ex 10 pixels/sec) what should I interpolate?
Can someone please explain a little better what the point and theory of interpolation is?

Kommi, I just tried your jar file and it looks just fine to me. I can’t tell if it’s actually running in exclusive mode or just a full screen windowed mode. If it is a windowed mode, then maybe you need to add some sort of frame limiter to keep it from stuttering on a slower machine. I ran it on a P4 2.0GHz running XP with an NVidia FX graphics card.

Anyway, I’m no expert and still in learning mode too, but my understanding of the reasons for interpolation is that because actual framerates can fluctuate wildly, interpolation helps to keep the movement constant and smooth when framerates fluctuate, i.e. speeding up or slowing down when your framerate increases or decreases. I’ve tried to write an animation loop before without using any interpolation and could never keep my image moving at a constant speed. Since I write all of my stuff in windowed mode, every time drawing cycles were taken by some other window (like tooltips on the taskbar for example) my animation loop suffered.

Anyway, I wrote a little program testing Markus’s examples and my animation loop looks very similar to yours. I will post it if I can find a place to host it so you can at least compare if you want.

OK, I copied your hosting idea and uploaded it here. http://www.angelfire.com/clone2/immudium/MMB.jar Source is included as well.

Thanx, I get frustrated sometimes when I cant see a solution that stares me in the face. I realise my mistake now by reading an old gamedev.net tutorial. I will implemen it as soon as I can to see if it works. Thanx for your post, I will check it out as well. I will post my results to what I think is a good real - time based loop here a little later.

Thats a cool app you have, but the movement is still a little jerky :frowning: What happens if you put into exclusive mode? I take it that you are interpolationg the x and y coords of the image?

I have read an article that describes a game loop in which you figure the real time of a single frame :
fTime = (time_after_frame - time_before_frame) / ticks_per_second

You can then get your x position by doing :
xPosition += velocity * fTime

If you add up all the fTimes during a one second interval then they equal 1. This is really cool becasue it makes physics a breeze. Just change your velocity evey second according to acceleration. I am not sure if Markus’s interpolation does the same thing. I am going to try this tomorrow. If you wish to read the article you can do so here http://www.gamedev.net/reference/articles/article753.asp

Ha ha. The more I look at it the more I realize that I am describing exactly what Markus’s interpolation does. I guess I finally get it.

You’re right, I do interpolate both the X and Y coords. Unfortunately, I haven’t had a chance to try it in fullscreen mode. It is my current understanding that fullscreen and window mode require slightly different animation loops and I have been spending most of my time trying to optimize the loop for windowed mode since I explicitly limit the max fps. It shouldn’t be hard to remove the frame limiting, but it’s still on my “to-try” list.

Anyway, I think you’re right it is still a little jerky and it seems to me that the way to fix it would be to increase the value of GAMETICKS_PER_SECOND which actually might be a little on the low side. From my experiments, increasing the value of GAMETICKS_PER_SECOND helps to smooth movement but at the cost of increased CPU usage.

I had not thought of the physics benefit of the interpolation technique, but I suppose you’re right especially for acceleration. Rather than jumping to a new position when you increase speed, the interpolation should help it to ramp up it’s motion.

Thanks for the article link. If I understand right, it sounds very similar to what both Jeff and Markus have been describing as far as the basic animation loop goes (which does not include the interpolation stuff). Interesting that they would suggest using doubles. I tried this once after reading an article on the popular java based MeatFighter game but it seemed to me that using doubles caused even more stuttering problems when coupled with the PerfTimer, but I could just have been doing something wrong at the time and I definitely had not yet adopted the interpolation techniques by then.

Edit - One thing I forgot to mention, that example doesn’t handle pngs very well. (or is that Java?) Anyway, you are likely to get better performance if you use -Dsun.java2d.noddraw=true when using it with PNGs. At least that’s the way it works on my box, so I forgot about it since I always have it enabled by default when I run that particular project on my machine.

OK quick queestion concerning the GAGE2d Timer. Now it stores the amount of ticks passed. If you run it long enough, could you run out of space in the variable that holds the tick count?

[quote]OK quick queestion concerning the GAGE2d Timer. Now it stores the amount of ticks passed. If you run it long enough, could you run out of space in the variable that holds the tick count?
[/quote]
what is used to store the tick count? if its a long, no :stuck_out_tongue:

Can anyone test out my loop and see if it runs smoothly on your comp? The file is here: http://www.angelfire.com/clone/wolfbane/Game_Loop.rar. It contains the executable jar and the timer.dll files. If you click the gravity button it will change the gravity from a y to an x directional force. The number on the bottom is the frame rate and should display the same number as your monitor’s refresh rate. Please let me know if it stutters, is jerky, or doesnt start.\

Also I just discovered that putting timer.dll inside an executable jar is pointless since it wont be recognised by the app. In order for my app to work I have to have a timer.dll in the same directory as the executable jar. Any reason for his? Any way to fix this?

Also can anyone think of a theoretical reason why an animation loop wont go faster than 100 fps even if the refresh is set to 160 or 200 hz? My loop works properly from 60 to 100 hz but after that it wont go faster than if I turn the refresh up. My timing is one by measuring the frame time of 1 frame. Could it be a timer problem? or a Java problem? My monitor does support high refersh rates so if some one could do a test on their system that woul be great.

[quote]Also I just discovered that putting timer.dll inside an executable jar is pointless since it wont be recognised by the app. In order for my app to work I have to have a timer.dll in the same directory as the executable jar. Any reason for his?
[/quote]
Yes. The Java VM calls the native OS to load native libraries. The OS don’t no nuthin 'bout parsin no jar files.

Um. A Java based OS?

Short of that, no.

Could be the resolution of your timer code?

Hey, Web Start handles that. It will unpack the DLL and make sure it is loadable by the OS when it launches your app.

AH, yes I didnt mention that. You can always treat the JAR as an archive and do an “install” to a known place. But at the end of the day the OS still needs to load it from a proper library file in its filespace.