Yeah I know this is a broad question and will get down rated, I'm just hoping for some answer before it gets closed.

Anyway, I'm using Slick 2D/Java to play around with graphics. I'm having some trouble with trying to move an image. The weird thing is, the code works just fine on my laptop, but the image sporadically moves to (0,0) and stops on my desktop. The only difference between the two is that it says the FPS is about 500 on my laptop and 6600 on my desktop. Can that affect it or does someone have any ideas for what to check on?

You don't want to eliminate the delta. It's there to give you a stable flow. Make sure your speed is a float. If you are working with ints then you will cut off any fractions,.
–
SidarOct 7 '12 at 17:31

1

An uncontrolled FPS would burn CPU/GPU time, which can be a problem because of excess heat and wasted electricity. This would be most noticeable on mobile platforms where battery life is limited. For laptops you could cause them to overheat, and for desktops you cause them to produce excessive heat and burn a lot of energy. So while it may not affect your program, it can certainly negatively affect your users' machines.
–
kurtzbotOct 8 '12 at 19:06

4 Answers
4

There's one scenario: you're calling the draw method so often you don't leave yourself the resources to do anything else. That's not your FPS negatively affecting how the game runs, though. The cause would be a badly written game, engine or framework; the FPS would just be a side-effect.

You have a glitch that surfaces on your desktop. Your desktop also achieves a crazy FPS rate. It's doubtful the latter is causing the former; but maybe they have a common cause and the high speed of your desktop is making surprising things happen.

As for the calling the draw method too often, that is likely. I'm calling it in every update. What's a better way to call it?
–
rphello101Oct 7 '12 at 16:43

@rphello101 There are a lot of problems you can run into when multithreading: race conditions, deadlock, and for instance, two different threads trying to access the same variable and do things with it at the same time (meaning one overwrites what the other just did. These are multithreading gotchas. The "gotcha" name comes from "got you".
–
doppelgreenerOct 7 '12 at 16:44

@rphello101 Calling the draw on each update is probably passable but not the ideal way to do it. XNA, for instance, handles them entirely separately so it can do things like draw less often (and drop the framerate) if your updates are taking a while to let the game "catch up". How to handle it though is a separate issue altogether worth its own question and answer, and not something I could answer in comments anyway. (and calling the update method 6600 times per second is completely unnecessary anyway)
–
doppelgreenerOct 7 '12 at 16:50

thanks for both replies. I'll check for gotchas and consider the latter. As for calling the update, it's Slick's own required method that gets called. I did, however, stop it from drawing on every update. Now it only draws when something changes.
–
rphello101Oct 7 '12 at 16:55

If you want your game to have consistent behavior across platforms, you really should have a fixed frame rate for your game logic and physics code. That way, your time step will be constant, which means that any (inevitable) roundoff and other errors caused by the finite time step will be the same for all players.

The one major exception to this is games that don't (always) run in real time. For such games, you want to keep the time step constant in game time, but you can allow game time to run as fast compared to real time as the player wants and the platform can handle.

It's OK — and, in fact, often very useful — to allow your graphics front-end code to have a variable frame rate, but even then, there's obviously no point in letting the graphics frame rate exceed the physics frame rate. (Actually, that's not completely true; if your drawing code can interpolate / extrapolate movement between physics updates, it may be useful to run it more often. However, doing that well involves some relatively advanced issues.)

There's also no point in letting your graphics frame rate exceed the screen refresh rate (which is typically around 60 to 75 Hz), even if your physics frame rate is higher than that e.g. due to accelerated game time. Any effort spent on drawing more than one frame per screen refresh is completely wasted, since the player is only going to see one of those frames anyway.