For my 2 dimensional Tower Defense game I decided to try it out on a different computer. This turned out to be a disaster... The game runs completely different. randomely lags and everything goes much faster. I am guessing it is the way I do my animations and game loop. Here is the code for the loop:

And the way I do my animations is I have two variables and an if loop seeing if the first lvariables has become larger than the other and if it has than set that to zero, switch the image. If not increment the variable by one. Any ideas??

Was I before Chuang Tzu who dreamt about being a butterfly, or am I now a butterfly who dreams about being Chuang Tzu?

If gameSleep isn't much bigger than the actual time spent in your code, you start to notice the different run speeds. You should sleep for (time consumed - time between frames) instead of a fixed time, to get closer to a constant speed. If the difference becomes negative you have a performance problem.

Basically, When you call Thread.sleep(2), it's not guaranteed it will sleep for 2000ns. Sometimes it will sleep for 1000ns, or 3000ns, or something between or even beyond those values, depending on OS or hardware.This is why you have to check how much time passed since you last called sleep(), and change the sleep amount to fix the difference between what you want and what you got

PS: Have you tried moving repaint(); to the line before the try/catch block? I just noticed you are rendering stuff after sleeping.

Different Operating Systems also have different allowed sleep times. For instance on Older windows you can get a min sleep time of 15MS or worse. On any Operating System the amount of time your thread will sleep will randomly vary as well, sometimes the OS/JVM will just decide now is the time to sleep an extra 30 MS.

What I end up doing for my game loop is counting the time between each loop. and then using a FOR statement that counts down the total time for each 15MS for update logic; so if the thread slept for 30 MS I run twice, if it slept for 5MS I don't run at that step. However I always draw the screen even if it was too short of a step.

alright so I did some research on the pages suggested, thanks for the links, very helpful! Now I have another question: For one of the game loops I see delta being plugged into the update position method and update player sound and all that stuff... How would I implement that into the for loops that time my animations? Or is there a different way I should be animating?

Was I before Chuang Tzu who dreamt about being a butterfly, or am I now a butterfly who dreams about being Chuang Tzu?

Sorry for the late reply, had some crazy stuff going on. How would I "take the framerate hit" instead of using variable timestep, which I assume is the loop method that I am using right now.

I think he meant that using a fixed timestep by fixing the framerate. I don't think you're using any kind of timestep in your loop at the moment, as far as I can see. In a sense that means you're using a fixed timestep already, only you're not limiting the framerate. For example, at some computers your game may run at 60FPS resulting in a timestep for each update of 1/60 = 0.0166 seconds. On another computer your game may run at 120ms, resulting in a timestep for each update of 1/120 = 0.00833 seconds. In other words, the world will change twice as fast when the computer runs twice as fast.

One way to avoid this is by simply limiting the FPS. Which means that on a system that could run 120FPS your game would be limited to 60FPS (and do nothing for the rest of the time). For this I personally I like the loop that r4king's posted some time ago, it's here.

Makes total sense now, thank you. The only issue is that in his loop I see "update(delta)". How do I use delta to change the positions of my mobs, and the animations of things switching images? Here is the moving method for the mobs:

The delta is the timestep, which you need to integrate into your calculations for movement, animation etc so that with a higher FPS the movements and animations take smaller steps (instead of more steps of the same size). Here's how I would do this in your movement code, for example:

Now the nice thing about this approach is that you make things like walking and animation speed explicit. This means that by changing values such as ANIMATION_INTERVAL or WALK_SPEED you can tune animation and movement speed. Also, this means that your movement and animation will become independent on processor speed.

One thing to keep in mind, and which has been mentioned before: you can run into problems with this if the delta becomes too big. If you look at the simple calculation above you will see that with a very high delta the character will move a very long distance in one step, which may mean it warps outside of the screen, or right past an obstacle which it should have collided with. The discussions in the blogs that were mentioned earlier in this thread discuss this phenomenon, and how to avoid it (which is most easily done by "fixing" or maximizing the FPS, which puts an upper limit on the value of delta).

Very well written explanation, thank you very much. I will implement this as soon as possible .

EDIT: So I did this, followed Eli's tutorial (Very helpful by the way) and everything is up and running, but the walking for the mob is all messed up. I used to say to add 1/-1 to the x or y for the movement. That was a very smooth walking speed. Now it is all jerky, jumping forward when I use MOVESPEED * delta. I know this has something to do with delta... Any suggestions?

EDIT 2: When I replace MOVESPEED * delta with just a 1 like it used to be there is still no smooth walking speed. So it has something to do with the loop I am using. Here is the code foe anyone interested:

Ok, I figured out something. If I raise the variable "targetfps" to something higher, the movement is much, much smoother. The only problem is that the game should be totally smooth at 60 FPS, which is what it is set to in the example. 60 FPS is more than enough to be smooth. Also, when I set the move speed of the mob to more than one, it jumps pixels instead of smoothly going faster, like I would like it to. Anyone got a better way of doing all this?

Was I before Chuang Tzu who dreamt about being a butterfly, or am I now a butterfly who dreams about being Chuang Tzu?

Ok, I figured out something. If I raise the variable "targetfps" to something higher, the movement is much, much smoother. The only problem is that the game should be totally smooth at 60 FPS, which is what it is set to in the example. 60 FPS is more than enough to be smooth. Also, when I set the move speed of the mob to more than one, it jumps pixels instead of smoothly going faster, like I would like it to. Anyone got a better way of doing all this?

If it moves >1 per frame, then it will obviously more >1 pixel.

The human eye will see anything >=24 fps as moving. All the extra frames just smooth everything out in case an object is moving too fast for the brain to realise that it's the same object just in a different place.

The player won't notice.

You can't make anything go faster or slower without skipping/stopping on pixels. "Smoothly going faster" is not going to happen on a screen made up of pixels.

You are casting the delta to an int, which means that it will be zero unless you have lag, in which case it will be 1 or more.As you know, multiplying by zero = zero. So as long as you don't get lag, nothing moves.

Wow. I feel very silly. It works fine now, thanks! Now I want to go further though, and the way I used to have it, I could adjust the gameSpeed variable to make the game go faster. I'm guessing there is no real easy way to do this now though, correct?

Was I before Chuang Tzu who dreamt about being a butterfly, or am I now a butterfly who dreams about being Chuang Tzu?

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org