next »

[ஒழுக்கின்மை (Paul Eres)]

So it's like a hybrid between fixed and variable timesteps? That sounds interesting; what's the overall effect that achieves? Even greater smoothness?

i'm not sure as i don't know much about this myself, but this is how i understand frame rates in gm:

gm's default is that you set the frame rate you want to target, and it tries to run as fast as possible, but it won't run at a faster frame rate than your target; usually this is 30 or 60 (the default is 30)

you can also turn vsync on or off in gm. as i mentioned, vsync in gm does not prevent screen tearing even when it's on, all it does is reduce frame rate to an even-number fraction of the monitor's refresh rate (so for instance if your game is running at 55 fps normally, instead of 60, it'd reduce the frame rate to 30, and then go back to 60, jumping back and forth between the two depending on how much is going on on the screen, which makes things appear to double in speed and half in speed suddenly, rather than gradually move slower). always turn vsync off in gm since it doesn't prevent screen tearing even when it's on

anyway, sometimes it's preferable that the game entities not slow down when the frame rate slows down. if someone has a good computer and is running the game at 60fps, and someone else has a bad one and is running it at 40 fps, you don't want the game to be *harder* for the person with the good computer because all the bullets and game speed and whatever are going 33% faster for that person. you want the speed of the monsters, bullets, player, etc., to be equal at both 60 fps and 40fps instead of the one at 40fps experiencing slowdown. in cases like that you need delta time, where you measure the time since the last step, and adjust the speeds to correspond with that, so that if the game is running slower it doesn't *look* as if you are getting slowdown, even if you actually are

but that itself has problems because at very low frame rates things may jump over obstacles and whatnot, so you often have to create a minimum possible frame rate adjustment that it won't go beyond (something like 20fps, where you will get slowdown if you go below 20fps, but not until then). this isn't native to GM so you need to code it yourself, and use a dll for it to get more accurate time measurements than gm itself provides (i use "yourself's high resolution timer"). i wouldn't call placing these limits a 'hybrid', it's more like this: if your frame rate is above 20fps (or whatever lower limit you choose), it's a variable timestep, if it's below 20fps, it's a fixed timestep. in http://gafferongames.com/game-physics/fix-your-timestep/ this is called "semi-fixed timestep"

there are also more methods where you decouple the game logic steps and the drawing steps, which seems like a good thing to do (and i believe most modern games work like that?), but i don't believe GM can decouple those two; every game logic step in gm also has to be a drawing step (as far as i know)

also, as far as i know, *interpolated* timesteps are only important if your game uses a physics engine, it doesn't matter otherwise. i could be wrong about that though, it's just that whenever i've heard interpolated timesteps discussed it's always in the context of a physics engine. so if you don't use a physics engine in your game you may not have to worry about that?

[lasttea999]

Wow, lots of info. Thank you for such a thorough treatment of so many topics, Paul Eres! Perhaps all of these issues with Java will give me a healthy appreciation for Game Maker...

From some of the articles I looked at, I got the impression that interpolation is used whenever fixed timesteps are used. Just in case it is, I thought of a potential improvement to my current interpolation code. (I'll have to try it later, though.)

Currently, if I remember correctly, the program calculates interpolated position--- say, for an image--- as a float, and then casts that value into an int, like this:

Code:

drawnX = (int) (lastActualX + interpolation * (actualX - lastActualX));

But casting a float or a double into an int is kind of like using the floor() function, right? As in, it doesn't necessarily round to the nearest integer? So I'm wondering if it wouldn't be more accurate to do something like this:

Code:

drawnX = (int) Math.round(lastActualX + interpolation * (actualX - lastActualX));

[J-Snake]

Never round up, always round down to pixels. Rounding up is a common error of reasoning you might even find in professional books. Imagine pixels as a grid. If the physical position of a point is (0.9,0.9) then it is still in the grid/pixel-cell (0,0) but not in (1,1).

Also make it a habbit to use speed as the distance between the previous and the actual position since the way you are doing it can have a lot of flaws, just depending on implementation. I would like to know what are you storing in your "interpolation"-variable.

I hope you know what you are doing, if not I can show you how interpolation is looking like when done properly. Just let me know if you are still in trouble.

[lasttea999]

I hope you know what you are doing, if not I can show you how interpolation is looking like when done properly. Just let me know if you are still in trouble.

Oh, I'd love to see how it's done. Please, share your method with us!

Never round up, always round down to pixels. Rounding up is a common error of reasoning you might even find in professional books. Imagine pixels as a grid. If the physical position of a point is (0.9,0.9) then it is still in the grid/pixel-cell (0,0) but not in (1,1).

Interesting. I've thought about this concept before, but not really in the current context.

Also make it a habbit to use speed as the distance between the previous and the actual position since the way you are doing it can have a lot of flaws, just depending on implementation.

Isn't displacement (currentPosition - lastPosition) basically the same as speed in this situation, though? Maybe it depends on the order in which things are done--- drawing, modifying position with speed, etc.

Also, if interpolation depends on speed, I don't see how Game Maker could achieve interpolation with arbitrary drawing operations. For example, say I draw a rectangle moving around on the screen in GM. From the user's end, all he does is pass in values for the position of the rectangle when calling the draw function, so, for all the program knows, a rectangle drawn in one frame could be completely unrelated to a rectangle drawn in the next frame, right? So, how could GM interpolate? Is there some other (calculated) value equivalent to speed?

(Although, I mostly deal with sprites, which I guess GM could track. I haven't really tested for stuttering with, for example, GM's shape-drawing functions.)

I would like to know what are you storing in your "interpolation"-variable.

EDIT: The following, if I remember correctly, were taken or adapted from examples from here and here.

For the first build:

Code:

interpolation = Math.min(1.0f, (float) ((now - lastUpdateTime) / TIME_BETWEEN_UPDATES));

For the second build, it's something like this:

Code:

now = System.nanoTime() / 1000000000.0;
<stuff>
int currentTick = (int) (now * ticksPerSecond);
<more stuff>
interpolation = (float) (now * ticksPerSecond - currentTick);

[J-Snake]

When I find some time and go to my dev-computer I will write a short example and provide a run-example so that you see the result.

Gamemaker does not interpolate. As I told you it is just a fixed timestep with no vsync.

You need the speed property in general. Imagine you want to beam something from one place to other instead of letting it travel. Do you see the problem? Imagine you store previous position right before the fixed-update function. Now if you have 2 updates in a row the displacement won't correlate with the current speed anymore. All this is source of problems.

[lasttea999]

When I find some time and go to my dev-computer I will write a short example and provide a run-example so that you see the result.

Thank you very much!

Gamemaker does not interpolate. As I told you it is just a fixed timestep with no vsync.

Oh. I thought fixed timestep = jittery graphics; how does it keep its graphics so smooth, then? Is it just more lightweight than Java, or something? Or did you mean that Java always forces vsync, and that's why it's less smooth?

[ஒழுக்கின்மை (Paul Eres)]

the reason gm games don't jitter much is that a) most decent gm devs know to turn vsync off, and b) even when they don't turn vsync off most computers are fast enough to run most gm games constantly at 30 or 60 fps without ever dipping below that

[lasttea999]

a) most decent gm devs know to turn vsync off

Yes, that's the default setting, right. Now that I think about it... I think in my case, I heard about synchronization in GM a long time ago, saw that I never had it on anyway, and promptly forgot about it.

b) even when they don't turn vsync off most computers are fast enough to run most gm games constantly at 30 or 60 fps without ever dipping below that

I see. What I don't understand is, why most computers would be able to run a GM game just fine, but not my dinky little program... I used to think that my Java program would run faster because it'd be "lighter" than a GM program, but now I think: perhaps it's not the weight that matters here, but how well things are implemented. That is, maybe GM runs better because it was made better.

[dustin]

I'm not positive but my guess would be that java would be faster as long as your using something else to do the drawing ie. SLICK or LWJGL in which case all the drawing is done with C/Opengl

If your just using the java native drawing stuff then yeah I my guess would be GM would be faster then java.

[ஒழுக்கின்மை (Paul Eres)]

i'd have to see how it was coded to say why it'd be slower in java than gm, but perhaps you aren't using hardware acceleration? or maybe your code is just bad (rather than java being slow). or maybe you're trying to run it on a 4 year old netbook without a videocard (anything would run slow on that). could be any number of reasons.

[lasttea999]

If your just using the java native drawing stuff then yeah I my guess would be GM would be faster then java.

i'd have to see how it was coded to say why it'd be slower in java than gm

Should I just post the source already? It's not very well commented...

perhaps you aren't using hardware acceleration?

I don't really know how it works, but I got the impression that the authors of the tutorials I used all made a point of using hardware acceleration.

or maybe your code is just bad (rather than java being slow).

Could be, but my code looks pretty similar to a variety of (supposedly) nice examples. And again, that second example I posted that was supposed to "[render] the minimal thing you need to notice stuttering" still stuttered, so it seems it's not the game logic (which, by the way, was based on some GM code I wrote, which was in turn based on Matt Thorson's Grandma Engine).

or maybe you're trying to run it on a 4 year old netbook without a videocard (anything would run slow on that). could be any number of reasons.

I'm running it on an average (...?), relatively new desktop and an older laptop, and it runs better on the laptop.

Now. I have something embarrassing to confess...

Now if you have 2 updates in a row the displacement won't correlate with the current speed anymore.

After this I realized that I was updating the last positions of images with every logic update, which I think means that I was interpolating between logic updates rather than between rendered frames... 

I fixed it, and it seems like the stuttering got a little better. It still does stutter a bit, though, so I'll need to see if it actually got better, or if I'm just being optimistic... Furthermore, I'm still using displacement rather than speed; I'd like to see how J-Snake does it before I start making mistakes with that...

[J-Snake]

Here is an example for one single sprite to make the principle clear. You can apply it to all translating objects the same way. I chose 50 fps on purpose since it would jump like hell without interpolation. But interpolation will do wonders. Vsync is on.

(control with w,s,a,d, esc to exit, you need to install it)
http://depositfiles.com/files/irfny4vct

And here is the main XNA code. (Even when I turn off interpolation this fixed timestep implementation will stutter less than the native xna-solution in general)
Let me know how it runs.

  protected override void Update(GameTime gameTime)
        {
           elapsedTime += gameTime.ElapsedGameTime.TotalSeconds;

           if (elapsedTime > 3 * UpdateIntervall)  //In extreme slowdowns don't update more
            elapsedTime = 3.01 * UpdateIntervall;  //than 3 times in a row, rather slow
                                                   //down for better input-response
              
           while (elapsedTime >= UpdateIntervall)
           {
                elapsedTime -= UpdateIntervall;
                                                     ///// place your game-logic here below
                previousPos = pos;
                velocity = Vector2.Zero;
              
                KeyboardState kstate = Keyboard.GetState();

                if (kstate.IsKeyDown(Keys.Escape))
                 this.Exit();

                if (kstate.IsKeyDown(Keys.W))
                 velocity.Y -= speed;
                if (kstate.IsKeyDown(Keys.S))
                 velocity.Y += speed;
                if (kstate.IsKeyDown(Keys.D))
                 velocity.X += speed;
                if (kstate.IsKeyDown(Keys.A))
                 velocity.X -= speed;
                  
  
                pos += velocity;
            
                base.Update(gameTime);
            }
        }

        protected override void Draw(GameTime gameTime)
        {
            GraphicsDevice.Clear(Color.CornflowerBlue);
        
            Vector2 drawPos = pos;

            if (interpolate)
            {
                double frameSpeedX = velocity.X / UpdateIntervall;
                double frameSpeedY = velocity.Y / UpdateIntervall;

                drawPos.X = previousPos.X + (float)(elapsedTime * frameSpeedX);
                drawPos.Y = previousPos.Y + (float)(elapsedTime * frameSpeedY);
            }

            spriteBatch.Begin();

             spriteBatch.Draw(tex,drawPos, null, Color.White);
                  
            spriteBatch.End();

            base.Draw(gameTime);
        }

[J-Snake]

If you want to compare, here is the same program without interpolation:

http://depositfiles.com/files/61yl4ke2d

[dustin]

If your just using the java native drawing stuff then yeah I my guess would be GM would be faster then java.

I take this this means you are using the java library drawing stuff?  In that case it's an easy fix no need to be sad just switch to something like lwjgl..
http://lwjgl.org/
or if you want a simpler api just for 2d...
http://slick.cokeandcode.com/

[Chromanoid]

You should get smooth movement with Java 2D (I've seen games in Java2D w/o this problems). There must be a problem with your updates. Did you post this problem on java-gaming.org? I checked cpu usage, GC etc. of your simple_test (saw the jittering) with JConsole there are no signs for performance issues.
Do you use Thread.sleep (it is inaccurate in some cases)? Did you see this thread http://www.java-gaming.org/topics/slight-jerkiness/24311/msg/206952/view.html#msg206952 ?

[lasttea999]

Thank you for your example, J-Snake! Unfortunately I think I'll have to get back to you about how the program runs; I'm having installing problems and internet problems. (EDIT: works pretty well on my laptop; stutters, but only occasionally, similar to GM, I think.) Do you know what kind of timing mechanism your program uses, by the way?

Thank you, dustin. Are you still able to post an example made with Slick2D?

Did you post this problem on java-gaming.org?

Do you use Thread.sleep (it is inaccurate in some cases)? Did you see this thread http://www.java-gaming.org/topics/slight-jerkiness/24311/msg/206952/view.html#msg206952 ?

I haven't posted there yet, but I had read the topic you posted, and also the tutorial topic on game loops, so I'm wondering if, at JGO, the issue will progress beyond what was posted in those topics.

Also, I do use Thread.sleep. The solution in the topic you posted is to make another thread run in the background the whole time, right? It sounds kinda hacky, and while it seemed to make the program run a bit better on our desktop, it didn't seem to do much on my laptop, which usually yields better results than the desktop.

I checked cpu usage, GC etc. of your simple_test (saw the jittering) with JConsole there are no signs for performance issues.

Wait, so you saw the jittering, but no performance issues were detected? Weird... What could it be? As far as I can tell, the updates in simple_test are very minimal. By the way, you can see some of the code I'm using here; I'd love to get your input about it.

The thing about my code is, it's several different examples stuck together. I'm hoping it's not some obscure issue that fell through the cracks when I changed things to fit, although I was trying not to disturb anything in the process.

[dustin]

Thank you, dustin. Are you still able to post an example made with Slick2D?

Oh yeah sorry I forgot about that... here it is.  It was a while ago for a competition here but it ran at a smooth 60 fps on pretty much everyones computers who tested it...

http://dl.dropbox.com/u/15098202/savageBalloon3000.jar

Hopefully it still works although I can't see any reason why it wouldn't...

[lasttea999]

Hopefully it still works although I can't see any reason why it wouldn't...

Sorry if this is a silly question, but... do I have to install something that's not this JAR? It won't run when I try to open it. Or, it may be closing immediately on start-up.

[dustin]

Whoops sorry I guess that's why I had a zip file in the folder too.  I guess you probably want the zip and everything it has in it...

https://sites.google.com/site/nitsudrhodes/SavageBalloon3001.zip?attredirects=0&d=1

[J-Snake]

Thank you for your example, J-Snake! Unfortunately I think I'll have to get back to you about how the program runs; I'm having installing problems and internet problems. (EDIT: works pretty well on my laptop; stutters, but only occasionally, similar to GM, I think.) Do you know what kind of timing mechanism your program uses, by the way?

This is looking far better than Gamemaker since you have a fluid and a clean picture (no tearing). It stutters only when you have some interrupts in the background, other than that you will have a nearly silky-smooth picture.

@timing: it is the same timing as the variable step game-loop:

The fixed timestep is implemented inside the variable step (the update-function). The update function updates either as fast as it can (no vsync) or it tries to update at the rates of your screen-refresh (vsync on). After the update the draw-function is called. So if vsync is on the draw-function is called for every screen-refresh, what makes it ideal to interpolate.
But I can even turn vsync off for better performance and more consistent fixed-update-calls and the picture will still look a lot cleaner than in Gamemaker thanks to interpolation.  

You can apply this code to your example, if you don't get the results then you are either using gui-graphics (not hardware-accelerated) or you are using a platform similar to flash which is conceptually drawing on its virtual movie-frames first instead of directly to screen-buffers (already mentioned it), it is your job to find out now.
Best way to test it is just to run your code in variable step (simply add no timing mechanisms and just update). You should have a fluid picture (variable step is the king of smoothness). If not then one of the things I said have to be true, you are using the wrong framework/setup.