I am making a Super Mario like 2D platformer and I've encountered a problem. I need to move this sprite :

enter image description here

When a player presses the right key, the sprite moves by 32 px to the right. The process of moving the sprite is as follows :

  • The sprite begins in a StandingIdleFirstStep state (Image 1).
  • Then the sprite enters a transition state (Image 2). The sprite is moved by 16 px to the right. This state is visible for 256 ms.
  • Finally, the sprite ends the movement in a StandingIdleSecondStep and has moved 32 px from its starting position (Image 3 - first and third step images differ).

During this entire process, the user cannot interact with the sprite. I can feed the process with a approx. 30 ms delta per frame.

Currently I'm thinking about this solution :

  1. User presses move right
  2. Set moving flag to true
  3. Move sprite by x+=16 px.
  4. Update sprite animation
  5. Draw everything

(after 256 ms)

  1. Check if currentAnimationImageIndex % 2 == 1.
  2. If true (odd image, can't stop there), move sprite by another x+=16 px.
  3. Update sprite animation
  4. Draw everything
  5. Set moving flag to false
  • \$\begingroup\$ What's the question? And the problem you've encountered? \$\endgroup\$
    – House
    Jun 16, 2013 at 18:09
  • \$\begingroup\$ Well, the problem is that I don't know how to approach this. If I add the StandingIdleFirstStep and StandingIdleSecondStep to the animaton cycle (add time to their images) the process gets messed up (the cycle waits until the display time passes). If I don't add those two states to the animation, then what should I do with them? \$\endgroup\$
    – dØd
    Jun 16, 2013 at 18:18
  • \$\begingroup\$ I'm not sure why you'd add time for them. They represent where the sprite was when it started the animation and where the sprite will be when the animation completes. Have you tried implementing your current solution? Implementing that will at least give you something to tinker with. \$\endgroup\$
    – House
    Jun 16, 2013 at 19:29
  • \$\begingroup\$ Trust me, computers nowadays are fast enough to draw everything many times per second. You dont have to optimize by not drawing too much \$\endgroup\$
    – stas
    Jun 17, 2013 at 0:36
  • \$\begingroup\$ On a side note, why do his legs change color? \$\endgroup\$
    – stas
    Jun 17, 2013 at 0:36

1 Answer 1


Try thinking this way:

UI thread:

  1. User presses move right
  2. Set moving flag to true

Game Loop Thread, measure elapsed time between updates

  1. show current character sprite frame
  2. if moving add elapsed time to total animation time, else show frame 1
  3. if animation time < 256ms show frame 2, if animation time > 256ms show frame 3 (ando so on for longer walk)
  4. update sprite position by distance (if it moves 128 pixels per second, move it 128 * elapsed time in seconds)
  5. perform checks
  6. draw everything

Don't try to do everything in one thread, don't let UI or waiting for another frame block the whole game.

  • \$\begingroup\$ Why does UI need its own thread? Having UI within the game loop does not imply one blocking the other. \$\endgroup\$ Jun 17, 2013 at 5:08
  • \$\begingroup\$ It doesn't have to be, but I believe it is so in most games. I did not express it very well. I wanted to say that "During this entire process, the user cannot interact with the sprite. " is not a good idea. User can change his mind just in that time and want to walk left etc. \$\endgroup\$ Jun 17, 2013 at 5:12

You must log in to answer this question.

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