Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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
share|improve this question
    
What's the question? And the problem you've encountered? –  Byte56 Jun 16 '13 at 18:09
    
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? –  dØd Jun 16 '13 at 18:18
    
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. –  Byte56 Jun 16 '13 at 19:29
    
Trust me, computers nowadays are fast enough to draw everything many times per second. You dont have to optimize by not drawing too much –  stas Jun 17 '13 at 0:36
    
On a side note, why do his legs change color? –  stas Jun 17 '13 at 0:36
show 2 more comments

1 Answer

up vote 0 down vote accepted

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.

share|improve this answer
    
Why does UI need its own thread? Having UI within the game loop does not imply one blocking the other. –  congusbongus Jun 17 '13 at 5:08
    
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. –  sm4 Jun 17 '13 at 5:12
    
I'll accept this answer, helpful. Thank you. –  dØd Jun 17 '13 at 6:33
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.