Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've been working on my first HTML5 prototype and I found a good model that uses the regular Update and Draw loop we see in game dev. My question is, where does one end and the other begins?

The question popped when I wanted to rotate and draw an Image, and I kept wondering if the work of changing the tranformation matrix (that I presume would be a bit expensive since it works on the whole pixel array of an image) and calculating the right position do draw it would characterize drawing work, or maybe not, since after that I may need to check for collision or something similar.

Thinkig of it, seems like a silly question, but I would like some advice from more experienced developers. Where does does update ends and draw starts?

Thanks in advance.

share|improve this question
Don't forget to use requestAnimationFrame. – jcora Oct 8 '12 at 15:15
Two helpful articles How to make a simple HTML5 Canvas game and CASE STUDY: ONSLAUGHT! ARENA might be useful. – richtaur Oct 8 '12 at 19:58
Thanks @richtaur, I've already seen those examples, I used this model and it seems very good imo. – Galvas Oct 8 '12 at 20:03
up vote 7 down vote accepted

In your case you'd move around game objects based on their velocity, do collision detection and handling, and only then you'd render the game objects with their new positions and rotations.

  • During the update phase you change your game state, amongst others calculating new positions and rotations for your game objects based on user input, gameplay rules and physics.
  • The draw phase should only be about creating a view (like a snapshot) of your current game state. In this phase the game state shouldn't be modified anymore so as to create a consistent image.

Side note: The transformation matrix should be separate from your sprite's pixels. Updating it with a 2D-translation can be as cheap as 2 additions. If this doesn't make sense read up a little more or even ask a new question about it.

share|improve this answer

Determining (calculating) the transformation of the entire image is usually considered update work. You calculate it only once per frame and pass it on to the GPU however your API allows you to. The passing of that transformation to the GPU is considered part of the Draw work.

The GPU then does all heavy lifting (applying the transformation to every pixel) to make sure the pixels get lit correctly. Since the GPU can operate on many pixels at the same time (parallel processing), it happens very fast.

Also, it doesn't actually transform each pixel. Behind the scenes, it creates 2 triangles that merge to form a quad the dimensions of your image. The transformation is only applied to the 6 triangle points (vertices). the color of each pixel inside the triangle can be determined by interpolating the info contained in the 3 points instead of transforming each pixel.

share|improve this answer

A good rule of thumb of thumb is to imagine that you're doing a blind replay. That is, say you have a recording of player actions from a past game, and you want to find out how the player scored by replaying that game, but you only care about the outcome — there's nobody there to look at the game as it (re)plays.

Anything you need to do to figure out how the game ends belongs in the update phase. Anything you can safely skip in a blind replay belongs in the draw phase. Generally, you want to do as little work as possible during the update phase, so anything that can be moved from the update phase to the draw phase usually should be.

This way, you'll (hopefully) end up with a clean separation of update and draw logic.

That said, it should be noted that there are some perfectly valid techniques that can muddle the distinction: for example, classic 8-bit 2D games often use(d) pixel-by-pixel sprite collision detection (often done at least partially in hardware), which ties sprite rendering (drawing) and collision detection (update) all but inextricably together. If you use such techniques, you'll just have to accept that you'll have a combined update-and-draw phase, or at least that your update phase will include some things that are really more about drawing, but which need to be in the update phase because they affect game logic.

share|improve this answer

Your Answer


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.