HTML5 Canvas and Game Programming

I hope this is not too open.

I am wondering if there is a way (more convenient for the battery) to do this -

I have a small HTML 5 game drawn on canvas (say 500x500). I have some objects whose positions I update every 50 ms or so. My current implementation re-draws the entire canvas every 50 ms. I can’t imagine that it’s very convenient for working on mobile platforms.

Is there a better way to do this? This should be a big picture with games.

EDIT:

upon request, here are a few more updates:

Currently, objects are geometric primitives drawn through arcs and lines. I don't mind creating these small png / jpg / gif files instead of helping. This is small graphics - just 15x15 or so.

As the game progresses, more and more screens change at a time. However, at the beginning, the screen changes relatively slowly (objects randomly moved several pixels every 50 ms).

+4
source share
4 answers

Almost every game with continuous animation, like this one, redraws all frames; smart update algorithms are only applicable when a small part of the screen changes, and there is a good rule to find out what overlaps this part.

Here are some optimization tips:

  • Make sure the GPUs process as much as possible, not the CPU. (This may not be possible if the user's browser does not use a GPU to render the 2D canvas, but you can expect updates to change as the popularity of games in HTML5 gains popularity.)

    • This means that you should avoid complicated smart algorithms in favor of doing as little work in JS code as possible, except that avoiding doing a lot of the drawing when it is easy to determine that it will be invisible (for example, outside the screen border), like usually worth it.

    • If your target platforms support it (as a rule, this does not apply to current mobile devices), try using WebGL instead of 2D Canvas. You will need to do more detailed work, but WebGL allows you to use operations that are more likely to be provided using GPU hardware.

  • If your game is idle - that is, nothing really revives at the moment - stop redrawing. Stop the update cycle until the user interacts with the game or a timeout occurs.

You may find it helpful to add to your questions the question of what types of graphics you draw (for example, do you use sprites or geometric primitives? Do you draw images rotated / scaled? Most of the changes to the screen or just a few small objects? You mix a lot of layers ?) and maybe even a screenshot or two; then we can suggest which optimization options are suitable for your specific game.

+7
source

Do not draw the background, make its image and set the CSS background image on the canvas.

Using requestAnimationFrame should help offline.

http://paulirish.com/2011/requestanimationframe-for-smart-animating/

Only redraw if something has really changed. If you have not already done so, imagine the concept of invalidity. (i.e. the canvas is valid, so nothing is redrawn until something moves). Everything that moves inside the canvas window makes the canvas become invalid, so it needs to be redrawn)

+3
source

If you want to be battery friendly, you can use Crafty . This game engine uses modern CSS3 technology, so it does not need to constantly update the canvas. Take a look at this example game here .

+1
source

As you do not want to redraw the entire canvas in each frame, it can only be the "Dirty-Check" or "Dirty Matrix" algorithms.

A dirty check seems more effective than a whole redraw. but I think it depends on your rendering implementation.

there is no need to use it if you use canvas2D for rendering. Almost every game has complex sprites and animations. if you use dirty checking when you need to update part of a sprite or background map, you need to find out what overlaps this part. and then clear this small area of ​​the canvas, and then redraw each sprite or map. etc. that overlaps. This means that you had to run the canvas render api more times than the usual rendering implementation due to the overlapping part. Canvas2d rendering performance is usually inefficient.

But if you use WebGL, that could be the difference. although I am not a family with WebGL, I know that it may be more efficient. Dirty-Check should be a good choice as per your suggestion.

0
source

All Articles