Just getting into game development and wondering about fps. For example, Binding of Isaac can run at 60 fps, but looking at its sprite sheet, the walk animation is only 12 frames. The game animation definitely doesn't look like its running at 60 fps, but I think the collision, movement, etc. systems are?

I'm working on a game I plan on running at 60 fps, is this a good frame rate for a first game, and how do you fit sprite frames into a higher frame rate? I assume if you have a 12 frame/second animation, you can run each sprite frame for 5 in game frames.

I've seen people talk about issues in running a 12 frame cycle in a 30 fps game, because the ratio isn't a whole number, so it doesn't scale. Will this be a problem if someone wants to run the game at a lower frame rate? Or is the frame rate locked and the game slows down if a computer can't run it?

Sorry if I'm asking some obvious questions, I'm pretty new to this.


2 Answers 2


The frame rate of your game can be a different concept from the number of frames in a particular sprite sequence and how quickly you shuffle between them.

60 FPS as the overall render frame rate target for you game is a fine idea. But when you're animating sprites you might not always want to have a fixed 1/60th of a second pass before switching to the next frame - you may want to linger on certain "high impact" frames, for example, to create a particular visual feel. Or you may want to just evenly linger on every frame enough that a 12 frame cycle takes one second to complete, as you note.

Generally an animation sequence will support the notion of the amount of time to spend on any given frame, somehow. You might then have code that updates the sprite do something like this, conceptually:

void Sprite::Update(float elapsedTime) {
   timeRemainingThisFrame -= elapsedTime;
   if(timeRemainingThisFrame <= 0.0) {
     // for brevity, only advance one frame every time, but you may want
     // to account for very long frames due to perf spikes that may require
     // you to skip more than one frame.
     currentFrame = (currentFrame + 1) % frameCount;
     timeRemainingThisFrame = frameData[currentFrame].timeForFrame;

Generally you don't want to fix the rendering framerate, except to perhaps tie it to the vertical blank so you don't get tearing. But you might be running your underlying game simulations at a different framerate (say, 30 FPS for physics).

  • \$\begingroup\$ Good idea about variable framerate for animations. Are there any well known examples of its use? \$\endgroup\$
    – Kromster
    Nov 15, 2017 at 18:41
  • \$\begingroup\$ So should things like movement, hit detection, etc. be tied to frames or time? Also what are vertical blanks? Thanks for the response. \$\endgroup\$
    – Aeolus
    Nov 15, 2017 at 18:43
  • \$\begingroup\$ @Kromster It's how I set things up, since I think it's easier (and cheaper) than duplicating frames to extend the time an image stays on screen. I'd imagine anything that creates a similar "pause" effect that only applies to the one animation (as opposed to "big hit" effects that temporary pause all action) would do something logically equivalent. But I don't know of specific examples offhand. \$\endgroup\$
    – user1430
    Nov 15, 2017 at 18:50
  • 1
    \$\begingroup\$ @TheTesseract'sShadow "Vertical blank" is sortof an anachronism at this point, but en.wikipedia.org/wiki/Vertical_blank_interrupt. The effective meaning is to tie the rendering rate to the refresh rate of the monitor. Generally you should tie things to elapsed time, not frame rate, because framerate is usually variable. The exception is usually physics, but then you want to fix your timestep so each physics simulation tick is uses the same delta time, possibly running it multiple times per "frame" to catch up. It's probably not something you want to worry about just yet. \$\endgroup\$
    – user1430
    Nov 15, 2017 at 18:53

how do you fit sprite frames into a higher frame rate?

The trick is to run animations at spritesheet framerate (e.g. 12fps) and run character/entity movements (physics, camera, particles, GUI, etc) at full 60fps.

This way you will save on drawing spritesheets, but perceived animation smoothness will still be high. Especially if you add particle effects, camera panning and other nice non-drawn-animation based effects.

Will this be a problem if someone wants to run the game at a lower frame rate?

Typical game has display (in a broad sense) and internal state decoupled. So no matter what display pipeline you have (within sane bounds) you still have the same game mechanics working with the same player input.

Generally games try to skip frames and avoid slowing down. Otherwise games difficulty will suffer - players will deliberately slow down their PCs to take advantage of increased reaction times. When skipping frames, animation and movement will look chopped, since you will have to drop some movement or even animation frames. There's no way around it.

  • \$\begingroup\$ So would each sprite frame run for 5 game frames in this example? Also is 60 fps an acceptable framerate for pixel art? Is there any reason not to lock it at that rate? Thanks. \$\endgroup\$
    – Aeolus
    Nov 15, 2017 at 18:34
  • \$\begingroup\$ @TheTesseract'sShadow As Josh wrote - fixing fps is rarely viable, since every now and then a frame could get skipped due to various reasons (even on powerful hardware). Better account for "interactive" fps from day 1. \$\endgroup\$
    – Kromster
    Nov 15, 2017 at 18:44
  • \$\begingroup\$ Does that mean scaling sprite frames to different frame rates? What about movement? Should values be scaled or.attached to time? \$\endgroup\$
    – Aeolus
    Nov 15, 2017 at 18:50
  • \$\begingroup\$ @TheTesseract'sShadow it's not known upfront what fps you will have (unless we speak about very uniform platform, alike game consoles), so each new frame you check which animation frame should be picked based on current games time. Movement logic typically evaluated from known speed, previous position and time elapsed since last frame. \$\endgroup\$
    – Kromster
    Nov 15, 2017 at 18:57
  • 2
    \$\begingroup\$ @TheTesseract'sShadow You store the "previous timestamp" (which you set to "now" when the game starts). Every frame, you get "now," and compute elapsed as "now" - "previous." And you use that to drive calculations. That ensures things move correctly regardless of how long your frame actually takes, because games almost never run at a consistent framerate. \$\endgroup\$
    – user1430
    Nov 15, 2017 at 19:06

You must log in to answer this question.

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