Responsive Sprite Animations with ImageMagick and GreenSock

Originally published at: http://www.sitepoint.com/responsive-sprite-animations-imagemagick-greensock/

CSS Sprites are not new. Since being popularized on A List Apart in 2004, the humble sprite has become a staple technique in many a web developer’s toolkit. But while the speed benefits afforded by sprites are well-understood, their uses in modern web animation are rarely discussed. The principle remains the same: combine multiple images into a single ‘master’ graphic, of which only selected portions are displayed at a time.

In this article, we’ll explore an easy way to create responsive CSS sprite animations that are lightweight, mobile-friendly, and even interactive. You don’t need any special graphics software, just a bit of CSS and JavaScript know-how. Let’s get started.

Building A Sprite

Sprites originate from the world of video games, so we’ll pay tribute to their heritage and animate Ryu from Street Fighter. Needless to say, all artwork belongs to Capcom.

We need to combine each frame of our animation into a single image. There are dozens of tools out there to aid with the creation of sprites, many of which will even generate an accompanying stylesheet for you. Compass’s built-in spriting features are immensely powerful, and SpritePad is a good example of a web-based generator. For our purposes, however, a simple command-line approach works fine.

ImageMagick, the ‘swiss army knife’ of image processing, is a free and open-source image manipulation tool that’s perfect for automating tasks that could become laborious, such as combining images. ImageMagick is also available for just about every operating system. Mac users can install it via Homebrew, Windows adherents can download an executable installer from the official website, and Linux devotees probably don’t need me to explain anything.

Save the identically-sized frames of your animation in a folder as a sequence of PNGs. Break out a command-line terminal, navigate (cd) to the directory where your images are saved, and execute the following command:

convert *.png -append result-sprite.png

This command instructs ImageMagick to vertically concatenate all the .PNG files in our directory (since ‘*’ is essentially a wildcard) into one complete sprite called “result-sprite.png”. This is the graphic that we will apply as a background-image in CSS to the element we want to animate, altering its position to cycle through each frame in sequence.

Continue reading this article on SitePoint

It was really an awesome article, Tom. I will definitely use this technique someday, thanks for teaching us :smiley:

Thanks Tanay, I’m really pleased you found the technique useful!

I’d be very interested to see what you create. Happy spriting.

Nice article!
i would like to use responsive sprites in a project at our company, but i have encountered a problem with rounding of the background-postition. I forked your pen (http://codepen.io/anon/pen/zGvOZV) and put in our testing sprites and like you can see, when the sprites container is not exactly the width of one frame, the entire frame moves up and down by one pixel. I was wondering if you had an Idea how this could be fixed.

Thanks in advance

Hi TWeber,

Thanks for this, it’s an interesting problem.

I’ve dug into the cause, and I believe it’s related to the way you’ve scaled your sprite. Your original 10-frame sprite is 4000 pixels in height, making for a neat 400 pixels of vertical movement per frame. It is also an extremely precise image, requiring accuracy down to a single pixel to retain its composition (namely, the one-pixel border).

In your Pen, the image is scaled down to 3413 pixels in height, which equates to 341.3 pixels per frame. This is rounded up or down depending on the frame number, resulting in the slight positioning shift that you see, and made more noticeable by the one-pixel border flickering in and out of view.

So, I would say that this problem is caused by the inherent difficulty of retaining accuracy down to a single pixel in a responsive environment. As a workaround, I suppose you could include a small amount of whitespace around each frame (padding, essentially, and transparent if need be) to make the one-pixel shift less noticeable.

I hope this is helpful. If anyone else has suggestions for how to address this issue, I’d love to hear them!

Thanks again,

Tom

This is the problem with sprites when you need absolute pixel precision and you should never make a sprite where it exactly joins to another sprite either because when the page is zoomed the sprite will show artefacts from adjoining sprites as the image is rounded up or down. Always allow at least a 3 pixel gap between your sprites.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.