4
\$\begingroup\$

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?

\$\endgroup\$
8
  • 1
    \$\begingroup\$ Are you working with a delta time? \$\endgroup\$
    – Sidar
    Commented Oct 7, 2012 at 16:43
  • \$\begingroup\$ Yes I am. I multiply the velocity (which is the cos/sin of the angle that the image is facing * move speed) by delta. You think that could be causing a problem? \$\endgroup\$
    – rphello101
    Commented Oct 7, 2012 at 17:00
  • 1
    \$\begingroup\$ Well if it's rounded to 0? xD \$\endgroup\$
    – Jonathan Connell
    Commented Oct 7, 2012 at 17:01
  • 4
    \$\begingroup\$ 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,. \$\endgroup\$
    – Sidar
    Commented Oct 7, 2012 at 17:31
  • 2
    \$\begingroup\$ 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. \$\endgroup\$
    – kurtzbot
    Commented Oct 8, 2012 at 19:06

4 Answers 4

Reset to default
5
\$\begingroup\$

Not really, no.

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.

Are you running into multithreading gotchas?

\$\endgroup\$
7
  • \$\begingroup\$ What's a gotcha? \$\endgroup\$
    – rphello101
    Commented Oct 7, 2012 at 16:41
  • \$\begingroup\$ 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? \$\endgroup\$
    – rphello101
    Commented Oct 7, 2012 at 16:43
  • \$\begingroup\$ @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". \$\endgroup\$
    – doppelgreener
    Commented Oct 7, 2012 at 16:44
  • \$\begingroup\$ @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) \$\endgroup\$
    – doppelgreener
    Commented Oct 7, 2012 at 16:50
  • \$\begingroup\$ 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. \$\endgroup\$
    – rphello101
    Commented Oct 7, 2012 at 16:55
2
\$\begingroup\$

Check this out: http://www.mysecretroom.com/www/programming-and-software/android-game-loops

It explains a good way to setup and control the speed of your games update and rendering. It might help you out.

\$\endgroup\$
2
\$\begingroup\$

You should implement a proper game loop to keep your game at a steady frame rate. By industry standards right now it should be 30-60 fps.

The disadvantages of having high frame rate:

  • Hugs system resources therefore slowing down any other activity the user likes to do.
  • Consumes more power, something to keep in mind when you are using a laptop.

Disadvantages of having a variable (not consistent) frame rate:

  • Your sound effects will be triggered at different times on different platforms.
\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .