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

For my first game I implemented a tetris clone in javascript. My "canvas" and an HTML <table> with every <td> representing a single block. Instead of having a gameloop redraw every single pixel, I only update pixels that have changed, like a piece being rotated and moved down. Is that a bad practice?

share|improve this question
Using tables to represent pixel grids seems a bit like a problem. Surely JS and modern HTML (5?) provide a better way to gain access to a pixel surface? If you aren't seeing a performance issue it's probably okay for your limited needs, but I'd be surprised if that scaled. – Josh Petrie Dec 17 '12 at 17:24
The reason I did that us because I knew exactly what I needed to do. I am sure there are much better ways to this in HTML5, but I figured that I wasn't going to spend time on something that basic, especially in the beginning. – Pasha Dec 17 '12 at 18:44
@Pasha: I wouldn't be so sure. With tables you have a very primitive (bitmap), ineffective (memory and CPU consuming) thing (I'd be surprised if you get any decent performance with reasonable resolution even with recent improvements to JS). In HTML5 canvas you get full 2D API including drawing circles etc. In short you would have sufficiently HL API that you wouldn't need to ask such question. – Maciej Piechotka Dec 18 '12 at 0:56
I've never made a game before, and I figured that making a tetris clone with just the things that I knew would be a fun exercise. The game is very poorly written, I am sure. I don't even have a game loop, just a bunch of setTimeout calls. But, it's a working game of tetris, and that makes me happy. I am now taking a step back and diving into a game dev book. – Pasha Dec 18 '12 at 19:03
up vote 8 down vote accepted

No, it isn't a bad idea.

In fact, this kind of technique -- determining which (usually rectangular) regions of the screen were "dirty" and only redrawing those -- used to be standard practice for rendering to the screen before the modern era of 3D graphics, hardware acceleration via powerful dedicated GPUs, and so on. There isn't any need to waste computational power re-drawing parts of the frame that have not changed.

Now, in modern times this technique is of less obvious utility. Many games have so much changing from frame-to-frame (especially in 3D) that it might be worth redrawing everything all the time, even if the modern render pipeline was not specifically designed to function that way.

If you are using a technology that doesn't or can't take advantage of hardware acceleration, then it's probably a good idea, especially for a 2D game without much changing between frames.

In short, it's unlikely to be a bad thing, at worst it will not likely have any noticeable impact on your performance. At best it will help quite a bit, especially if your rendering involves literally setting individual pixels each frame (it's a bit beyond the scope of your question, but if possible you should use whatever higher-level rendering primitives are available in your toolchain, such as "DrawRect" or "DrawImage" if they exist rather than manually flipping each pixel in turn).

share|improve this answer

From what I've heard it's a great practice. The only problem is that practice is mostly troublesome. When you redraw every single pixel you might need to use buffering so you won't notice flickering between the drawing of the second image and the flush of the first.

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.