Creating sprite sheets has never been easier: toss a folder at my new program and watch magic happen! This article details both why and how I engineered new software to address a common concern among game developers. This project was a month-long commitment.

Motivation

When developing games from scratch, I believe a neatly-organized folder of animated GIF’s/WEBP’s to be the best way to manage sprites. Anything more than that and you add needless complexity. I wanted a program that would convert such a folder (and its subfolders) into an optimized collection of sprite sheets. All existing software was lacking in this department, so I decided to roll my own solution.

Maintaining multiple user interfaces

First and foremost, I wanted to ensure all features would be available through a simple command line interface. Writing software this way makes it easier to integrate into existing development pipelines.

I also wanted to provide a graphical user interface (GUI) for those who prefer a visual, point-and-click experience.

Dividing code into modules simplifies this challenge. It also reduces redundancy and improves readability:

Did I mention QtCreator has a really nice WYSIWYG editor for creating GUI’s? I used it to design the main window, pictured below:

Reusing code where it counts

When developing a new piece of software, you should constantly reassess your goals and look for opportunities to lighten your workload: not by cutting corners, but by leveraging existing libraries where possible. I saved a lot of time by reusing boilerplate code from Google’s libwebp for processing WEBP’s and GIF’s.

Providing reference implementations

If you want people to adopt your software, make it easy for them by providing reference implementations. I wrote two: one in C using SDL2 for rendering, and another in JavaScript using an HTML5 canvas. Both display animated sprites on the screen, and demonstrate how to use EzSpriteSheet’s output in a meaningful way.

Try the JavaScript demo live in your web browser: https://z64.me/bin/ezspritesheet.js

The most important step

You don’t want all that hard work to amount to a program with a reputation for instability, do you? Before delivering a product to the masses, you should make sure it’s free of defects. In other words, it’s time for some quality assurance.

My favorite software for the job is Valgrind. Run a program through it and it will tell you if it detects any of the following:

• Uninitialized variable/memory usage
• Invalid memory access
• Memory leaks

Those things compromise stability, and your software may behave differently on different machines. For example: some CPU’s set uninitialized variables to zero when advancing the stack pointer, whereas others leave them set to seemingly random values. Valgrind helps you avoid surprises like this.

==993667== 
==993667== HEAP SUMMARY:
==993667==     in use at exit: 0 bytes in 0 blocks
==993667==   total heap usage: 43,399 allocs, 43,399 frees, 57,924,516 bytes allocated
==993667== 
==993667== All heap blocks were freed -- no leaks are possible
==993667== 
==993667== For lists of detected and suppressed errors, rerun with: -s
==993667== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

This is what you want: Valgrind is happy! Publish that code with confidence!

It’s already being used in a production environment

This racing game uses EzSpriteSheet to produce a texture atlas for its HUD elements:

Features

As of this writing, EzSpriteSheet is more feature-rich than its competition:

You read that right: it’s open source

And you can find it on GitHub.com/z64me/EzSpriteSheet

Attribution

The following libraries and software made this project possible:

• stb
• giflib
• libwebp
• libpcre2
• QtCreator
• RectangleBinPack
• Sprite art courtesy of @DynoPunch