How do you test sprite animations?

I feel very much at home using shiru's screen tool for doing sprites. I realize there are specialized spriting tools, and that one could use photoshop or gimp, but somehow my workflow for drawing is both faster and more precise in NESST.*

That is, until i want to check the animation in realtime.

Right now, what i do is lining up all the frames side by side in the nametable, export it as bmp. Then import that bmp as an asset in an AfterEffects project with, say, a 32x16 canvas or the like, then 'animate' by switching ypos and xpos of the bmp import frame for frame.

What's lean is that if i export and replace from NESST, i get direct visual feedback in my AE window, which is continously looping the animation. It's also a small matter to change around the timing and progression of different frames, play it backwards, etc.

What's a bit fidgety is setting up the initial AE project.
And if i want a pixel perfect export to show, i need Adobe Media Encoder to produce a series of frame-for-frame png:s, after which i then use some random web based png to gif converter. This process is for some reason unreliable as the media encoder sometimes spits out a double frame for reasons unknown to me. I need to eyeball/compare the output with the intended framecount and delete the occasional extras.

Do you have any recommendations or suggestions on making the process leaner?

*It also helps me planning with resources, and it's easy to see when i can reuse a character/tile in several frames.

Aseprite is great to draw and animate pixel art. It's not expensive, besides. I've used it a bit. Until recently, I've been using a very old version of Photoshop I got at college circa 1999-2000, which includes Imageready. I draw my spriteset, cut the frames to a new project, then switch to Imageready (both programs are integrated). But Photoshop 6 is less and less stable in modern Windows, so I'm slowling switching to Aseprite, which has everything you've ever dreamt of regarding to pixel art.

The problem with drawing in one place and animating in another is that you have to "guess" how the animation frames will line up before actually testing, and tweaking the frames based on the result of the test is much more cumbersome than it should be. Time is just another dimension of the drawing, and creating good, smooth animation requires real-time editing in the time axis as well as in the X and Y axis.

I remember when I only used MS Paint to draw my sprites, and I used hacks such as drawing different animation frames in different instances of Paint so I could switch between them using Alt-Tab, and that sucked. I'd get an idea of how the drawings would line up, but the pacing was all wrong, and the workflow just sucked.

Nowadays I use Photoshop, with each animation frame being a layer in the image, and the basic animation tools are more than enough to quickly test the progression of the animation at the correct frame rate. I've used GIMP in the past too, but the way you set some animation parameters (such as the exposure time) using the layer's name is a bit odd and unintuitive.

I second aseprite. It's a really great animation tool. There is a free old version if you want to try it out (but it has a lot of good stuff added since then).

Also it can load and save GIFs without hassle.

Yeah, using gimp generally slows me down. It's probably personal, and it might be more stable than last time i used it regularly (several years ago. my assignments require subscribing to adobe CS so i might aswell use those), but i've always found it to be a bit unwieldy.

Alt-tabing between windows sounds really painful Kind of the equivalent to flipping through a block of drawings, but with less precision.

The NESST/AE combo is pretty good at this. I got NESST on the left, AE on the right. I see the cycle looping in AE, i see what's wrong/what could be better, while i edit. I change a few pixels, press export, and see the difference live, since AE constantly polls for updates to included images. So it's only guess-work the before the first export. The time domain is AE:s strong card, even though PS has gotten quite competent in that respect, too.

One thing that would improve PS considerably would be if there was an indexed colour mode which permitted layers (just ignore blending/layer fx and it'd be fine).



This is a major sell point for me. It would help sharing animated drafts with collaborators at a quick pace.

How do you aseprite users deal with tiles? Say for instance that the animation code will not update the two upper tiles but the two lower in a 4x4 metasprite. Do you just envision that and count grid lengths?

Yeah, I just put up an 8x8 grid and work against that. I don't actually cut a sprite up into tiles until I'm finished working on it, but I think it's fairly easy to keep tile sizes in mind while working. Tile reuse is more difficult, basically just have to copy and paste to simulate it though.

Same deal with nametables though, mostly I wouldn't work directly in NESST, I'd do it in GIMP just with a grid and keeping the rules in mind, and just copy-pasting to apply tiles, at least until I had most of the desired CHR worked out. I think NESST is a great final assembly tool, but for editing the CHR, unless I'm just doing late touch-ups I would probably go back to the source in another art tool.

In my own game I wrote my own tool similar to NESST, but I just import/export CHR sets as image files that I edit in GIMP etc. I did make a simple animation previewer (that just displays a list of sprites at a given rate) that makes late touch-ups easier, since it does inherently support tile reuse etc. I don't do the bulk of the work with that tool, but it's useful sometimes to make revisions.

Speak of the devil... Adobe Media Encoder decided to crap out and return a smudged output (maybe my 16x24 animation was too small or something, there's no preferences for this behaviour). I rebuilt the project in PS:s timeline editor - it crashed and won't behave after that (probably need to restart/clear memory).

After a bit of toiling, i found a better solution with the tools i have:

1)After Effects: add to render qeue.
2)Export as QuickTime .mov, draft quality, go.
3)Open in Photoshop
4)Save for the web (legacy); gif. It even retains the pixel sharpness when i goof around and scale it, so hooray!

It took a while to figure out but that proved much quicker and a lot more trusty in terms of result. Sharing animation sequences won't be a hassle anymore.

That said, aseprite looks like a nice addition. The free beta was a bit lacking, but i can see how it encourages a more fluid style of animation.

The conversion tools in my toolchain take care of duplicated tiles, so I just draw my animation using full frames (with a 8x8 grid on, of course).

I should document my main graphics converter, it's incredibly useful, works from command line or reading scripts, and does all the dirty job for you. All I have is to modify my sprite sheets in png and recompile my game to see the changes, everything is done automaticly, so tweaking an animation which doesn't look right ingame is easy.

That sounds very useful indeed! Once the animation patterns are coded, that sounds like a really quick way to go. Animation parameters could be .include:d in the source from a separate txt or bin for convenience.

layers in GIMP? THere's a quick menu option to view as animation without actually exporting, and you can just move layers.

Yeah, it has an animation preview tool in the Filters menu. Usable in a pinch.

The huge drawback to this is that if you're using layers for animation frames, you can't also use layers as actual layers at the same time. (That's one of aseprite's biggest advantages.)

... do layer groups help with that at all? (I have no idea, I only discovered them recently)

Yes, the GIF only plays back the "top level" of layers, so you can have sub-layers under a group belonging to a single frame.

It's only very slightly helpful. It's not even close to being as useful as frames and layers being separate independent features. It gets really cumbersome because if you go down this path, every "frame" becomes a layer group with a bunch of layers inside it, and you've got to duplicate and manage all of them for every frame.

In an animation tool like aseprite, though, if you want a static background behind other moving things, you just draw it once and don't have to do any more management of it. In GIMP you now need to include a layer copy of that background in every single layer group... each with a unique name too! (Now imagine trying to make an edit to 20 duplicate copies of that layer later on... you've basically lost all the utility of having layers at that point.)


The one thing I do like that GIMP has is a filter to "optimize" GIFs. Aseprite doesn't do this, it will always save all frames fully rendered, so if I want to lower the filesize I might pass them through GIMP's optimizer after exporting from aseprite.

Depending on your work flow, there's also the command line tool "gifsicle" that can optimize GIFs. It uses a different heuristic than GIMP does as to whether any given pixel in any frame should be marked as transparent or not; I don't think either heuristic is fully aware of the LZW stage. So it's sometimes better and sometimes worse.

Yeah, I'm aware of severeal tools that can do it. I'm not terribly concerned about finding the minimum possible file size, it's just that the difference between any reasonable GIF optimizer (e.g. GIMP) and no optimizing at all (e.g. aseprite) can be pretty big.

I use Photoshop, but it's because I've long been familiar with the software for work, school, and hobby purposes.

With the right settings in place, it's useful for doing all the pixel work I need to do.

Off the top of my head, my NES graphics settings include:

• An NES palette as Swatches, ordered and labeled.
• 16 pixel grid with 2 subdivisions
• Pixel Grid turned on (displays at zoom of higher than 600% in CS4 and newer). I especially like Photoshop's pixel grid because it is visually non-distracting.
• All tools' anti-aliasing settings off. All scaling modes set to Nearest Neighbor.
• A series of custom keyboard shortcuts for common tasks, such as toggling grid visibility, H and V flips, rotates, snap to grid, etc.

Moreover, I've recorded actions for a lot of things like updating the chr file, etc.

Its Frame Animation feature is as functional as I need for preview animation, and it's nice to be able to preview animations on the fly while I'm working on the art.

I would highly recommend Pro Motion for any sprite animation. There's a reason Shovel Knight's graphics were done with it. I don't think any other pixel program comes close for pixel artwork/animations.

Of course, it isn't a complete solution the as any efficient toolflow for creating sprite animations also needs to do these basic conversion steps to not totally waste space :
1) Find which frames are unique among animation frames
2) Convert those to CHR / OAM data
3) Generate animation data with frame references, offsets etc for each converted animation frame

...but those things don't require that much software engineering at the end of the day, and they will pay off when you have a good tool to iterate on, removing the build-and-run cycle when working on graphics.

That looks really useful. Thanks for that link.