5

I'm animating a sprite on a pixel grid. I have a few options, with pros and cons for each. I have a fair amount of javascript experience (six years), but none with this kind of thing. The problem is I don't know how expensive each option will be.

The sprite needs to render quite fast, and be inexpensive enough to have at least five running at the same time while running collision detection.

Ideally, I would like to use a grid of elements inside of a wrapper, rendering colour and alpha channels to each element from a multidimensional array. The major pro here is that I can run pixel-by-pixel collision detection and click past the transparent parts of the sprite. With any image-based sprite, the onClick event will fire even if I click on a transparent pixel (I'll have to do a lot of work to pass clicks through transparent pixels, and it might be quite expensive).

The next option is to use css sprites. css-tricks.com/css-sprites/ This would be easy peasy, but as mentioned previously, onClicks won't pass through the transparent pixels. I can probably force it, but again, it may be expensive, and take a lot of time to impliment.

Another option is animated gifs, but they are huge, limited in the colour department, and hard to control animation-wise. I'd rather not go there.

And then there's the html5 canvas element, which I don't know very much about and would like to stay away from if at all possible. I don't know how any of my code would even work in relation to the canvas element and I doubt it would do what I want in the long-run.

So which is the best for performance? Would the first (and most preferable) be a viable option? Or have I missed something out?

wjagodfrey
  • 175
  • 2
  • 8

2 Answers2

2

With today's browsers you will be fine on desktop computers for building a sprite out of positioned pixel sub-elements (as long as they aren't too complicated or large), and just to be safe I'd limit yourself to about 10 active sprites. With Mobile things might get a bit slow and clunky, but considering you seem to be designing a game that requires precision "onclicks" I doubt that this will be a problem.

Your most flexible bet is to use HTML5 Canvas, as you have already worked out, but it will involve quite a bit more JavaScript coding. But this sytem will allow you to apply a number of effects to your sprites and will allow you to use pixel perfect detection by using getImageData (which allows you to read the exact pixel colour at any pixel offset).

If you wanted to avoid the techinical problems and challenges of having a full screen canvas system (which can be tricky), you can actually create as many smaller Canvas elements and move them around as your sprites (with the ease of HTML Elements).. Then all you have to do is design the code that draws your animation frames, and also tells if the mouse has hit or not hit the sprite using the aforementioned method (along with a click handler and some code to calculate where the user has clicked relative to your canvas elements position). Obviously, it would be best to do this in a generalised way so your code can be applied to all your sprites :)

To draw your images on the canvas you can use a spritesheet as you were mentioning in your question, and use the rather flexible drawImage() method which supports a slicing mode. This just needs to be tied up to a setInterval or requestAnimationFrame style game loop.


UPDATE - for those who wish to be very optimal

If you wish to take a more optimal route - which is a little bit more involved again - you can do the following. This method benefits if you have many sprites that are exactly the same with only a few (20 or 30) frames of animation:

  1. Power your sprites by normal DIVs with a background image sprite sheet that you shift the background position of. This is the most optimal you can be, save having static images as sprites, because the browser does all the work.
  2. for each sprite type draw your spritesheet on a hidden canvas element that is big enough to incorporate your whole spritesheet.
  3. When a user clicks on one of your DIV sprites, take the background position as coordinates, invert them, and you should then know where on your canvas element (looked up by sprite's type) the pixel data resides.
  4. Use the getPixelData method on your hidden canvas to work out if the user has clicked on the sprite or not.
  5. The above means you only have one canvas element in use - per sprite type, the browser handles all the graphics for you and you get pixel perfect collisions with an onclick.

Hope the above makes sense?

Community
  • 1
  • 1
Pebbl
  • 34,937
  • 6
  • 62
  • 64
  • Great reply. Would you say that the canvas method is less expensive, and in turn faster, than the pixel sub-element method? Because above all, I really need conservation of processing power. – wjagodfrey Oct 29 '12 at 09:18
  • It really depends on the size/complexity of your sprites. If they are 16x16 pixels or red squares with blue spots ;) then I would say no... but any larger or more complicated than that, having seperate sprite canvas elements would be much more optimal. The main problem with using a full screen canvas is always 'clearing a large area' as it is rather expensive. So by using seperate canvas elements you only need to clear smaller areas and gain the flexibility of using css to position your sprites. – Pebbl Oct 29 '12 at 09:23
  • Thank you very much, I'll look into doing as you say – wjagodfrey Oct 29 '12 at 09:33
  • @WilfredJamesGodfrey no problem - I've added a third alternative that should be more optimal, I've not actually used this method yet. But it's been something I've been thinking about with regards to my own online game... and I can't see why it wouldn't be better. – Pebbl Oct 29 '12 at 09:40
0

How about splitting your image spirit into 30x30 cells and only have elements where the cell is opaque and leave a gap where the cell is transparent so that clicks fall through. You lose a bit of accuracy in where the cells can be clicked though.

Kernel James
  • 3,752
  • 25
  • 32