**TL;DR** - I tested three image models (GPT-Image-2, 2.5-flare, 2.5-sunburst) on four jobs: a spinning coin, a crow sword slash, cutting the crow into layers, and pulling the art out of a game mock-up. 153 generations, all measured. - **They draw a thing. They don't remember the sequence it belongs to.** A pose, a body part or a single asset works. "Frame 3 of 8" of a spin fails in all three models. - Frame-by-frame animation keeps the character but drifts in size - the crow's head changed size by up to 27% between frames. Even after lining the frames up to the beak and feet, all three models still jitter. None of the crow animations is usable as it is. - What worked better: cut the character into layers once (7 calls), then animate by moving the layers. Zero drift, zero extra calls per animation - but stiff, so use a real tool like Spine for the motion. - From a mock-up, all 60 of 60 assets were usable, and the rebuilt screen gets about two-thirds of the way to a perfect copy. The picture you give the model beats the prompt: a screen full of faces gets you faces. - The model ranking changed in every test. None of the output is game-ready yet - it's a starting point for an artist, not a replacement. --- Image models got really good at drawing a single game asset. One prompt, one nice-looking coin, transparent background, ready to drop into Unity. So I wanted to check two things. First: can they animate it? Not a video. The eight frames of a sprite animation - the thing a game actually needs - where every frame is the same object, same size, same place, just moved. Second: if I give an AI a mock-up of a game screen, can it give me the art for that screen? I ran four tests to find out. Three models, identical prompts, 153 generations. And I measured everything, because "looks pretty good" is not a result. ## Disclaimer First One run per test. One coin, one crow, one mock-up. I'm still learning how to get the best out of these models, and some of what I call "failures" below might be my prompts and not the models. In one case I know it was my prompt, and I'll point it out when we get there. So take the rankings with a grain of salt. The patterns are what I trust. ## The Setup Three models, all on the same Azure endpoint, so the only thing that changes is the model: - **GPT-Image-2** - the older one - **GPT-Image-2.5-flare** - the fast variant - **GPT-Image-2.5-sunburst** - the high-fidelity variant For the first three tests the method is the same. I generate one base asset, then send that exact image to all three models through the **edits** endpoint, with byte-identical prompts. The image goes in, so the model changes the asset instead of re-imagining it from a description. Then I measure. Pixel counts, not vibes. --- ## Test 1: The Spinning Coin ![The base coin: a chunky toon-3D gold coin with an embossed star](/blog/ai-sprite-animation/coin-base.jpg) The easiest case I could think of. A coin spinning in place, eight frames, 45° per frame. The nice thing about a coin is that there's a math answer. A disc turning around its vertical axis gets narrower by the cosine of the angle, so the three-quarter frames should be exactly **0.707** of the full width. I don't have to argue about whether it looks right. I can measure it. Here's what came back, one row per model: ![All three models' coin frames, showing that every three-quarter frame leans the same direction](/blog/ai-sprite-animation/coin-all-frames.jpg) And here's how it plays:

GPT-Image-2

2.5-flare

2.5-sunburst

Look at frames 1, 3, 5 and 7 in any row. They all lean **the same way**. The edge band - the strip of gold you see when the coin turns - is on the left in every single one. That's why the GIFs rock back and forth instead of spinning. That's wrong. Once a coin turns past edge-on, the band has to switch sides. I told every model which side, on every frame. All three ignored it. ### Why It Failed "45 degrees" and "135 degrees" look almost the same in a single picture. The only difference is *which way the coin is turning*, and that information doesn't exist in one frame. It only exists in the sequence. The model doesn't have the sequence. Every call is a fresh start with one image. Asking for "frame 3 of 8" is asking it to know something that isn't in the input. ### The Fix Was Fewer Calls, Not More A coin is symmetric, and so is a five-pointed star. So the second half of the spin is just the first half mirrored. Not an approximation - that's the actual geometry. Generate 0°, 45° and 90°. Flip them. You get all eight frames, and the back side is correct for free: ![Eight separately generated frames above, eight frames from three generations plus mirrors below](/blog/ai-sprite-animation/coin-generated-vs-derived.jpg)

8 generated frames (sunburst)

3 generations + mirrors (sunburst)

Two model calls instead of seven, and the jitter goes to zero, because the mirrored half is a pixel copy of a frame I already cleaned up. On this test sunburst won every measure: half the wobble of the other two, and the coin's height held within 1.3%. Remember that, because it doesn't survive the next test. --- ## Test 2: A Crow With a Sword A coin is the easy case. So the next one was a chibi crow swordsman, Capybara Go style, doing an eight-frame sword slash. ![The base crow: a chibi black crow in leather adventurer gear holding a curved sword](/blog/ai-sprite-animation/crow-base.jpg) Same method. One approved crow, scaled down to 60% of the canvas so the sword wouldn't get cut off, and eight prompts: ready, wind-up, swing start, strike, follow-through, lowest point, recovery, settle. Every prompt said the same thing about identity: same head, eyes, beak, leather gear and sword - **only the pose changes**. And no motion blur, no speed lines, no slash trail, no effects. ### This Time It Worked ![Three rows of eight crow frames, running through a full sword slash](/blog/ai-sprite-animation/crow-slash-all-frames.jpg) All eight beats, in order, in all three models. A wind-up looks like a wind-up.

GPT-Image-2

2.5-flare

2.5-sunburst

The clearest way to see the motion is an onion skin - all eight frames stacked on top of each other with the feet on one line: ![Onion-skin overlays showing a continuous sword arc in all three models](/blog/ai-sprite-animation/crow-onion-skin.jpg) That's a real slash arc. The difference from the coin is simple: **a pose is a picture.** "The crow crouching with the sword at the bottom of its arc" is something you can draw without knowing what came before. "45 degrees into a turn" isn't. ### But Look at the Heads Watch the GIFs again and the crow's head keeps changing size. That's not acting. That's the model redrawing the crow at a different size every call. I measured it with the beak - one orange shape that's in every frame and should never change size:

	GPT-Image-2	2.5-flare	2.5-sunburst
Head-size drift (worst frame)	11.9%	19.9%	27.4%
Slash-trail glare added	+12.2 pp	+9.0 pp	+5.3 pp
Height drift, standing frames	8.1%	2.3%	3.3%

Three measures, three different winners. The model that swept the coin came last on head size here. If you take one practical thing from this post: **don't carry a model ranking from one task to the next.** The identity held up really well, though. Across all 24 frames it's the same crow - same eye, same harness, same sword. The problems are size and placement, not character. ![Input crow beside the wind-up, strike and lowest-point frames for each model](/blog/ai-sprite-animation/crow-identity-detail.jpg) ### All Three Added the Trail Anyway All three broke the "no effects" rule, on the exact same frame - the strike - by adding a slash trail. A cartoon sword at full swing comes with a trail in the training data, and writing "no trail" five different ways doesn't remove it. When all three models disagree with your prompt in the same direction, it's not a prompt problem. It's a prior, and you won't argue it away. ### Fixing It After the Fact Size and placement can be fixed without generating anything new. Scale every frame so the beak matches the original, and pin the feet to one line:

Raw output (sunburst)

Beak-locked, feet on one line

Same eight images. No new generations. More watchable - but still not good. Even with the beak locked and the feet pinned to one line, all three models still look jittery. The outline, the gear and the sword shift a little from frame to frame, because each frame is still a fresh drawing. Lining the frames up removes the big jumps. It can't remove the small redraws. None of the crow animations from any of the three models is usable as it is. The catch is that you need a landmark. The beak works because it's one saturated colour, visible in every frame, with a fixed real size. So pick the landmark when you design the character, not when you animate it. --- ## Test 3: Stop Animating, Start Rigging If the problem is that the model redraws the character every time, the answer is obvious in hindsight: don't let it redraw the character. Cut the crow into layers once, then animate by moving the layers. I wrote a seven-layer plan - tail, far wing, legs, torso, head, sword wing, sword - and sent the same plan to all three models, one call per layer. The important part of the prompt wasn't the list. It was this: > Do not redraw. Do not re-centre. Do not resize. ![Three rows showing the original crow followed by its seven extracted layers](/blog/ai-sprite-animation/crow-layers.jpg) 21 extractions, 21 recognisable parts. No empty results, and no layer that came back as the whole bird. Which fits: a **part** is something you can draw on its own, just like a pose. ### Putting It Back Together Layers are only a rig if they fit back together. So I stacked all seven and compared them with the original crow: ![The original crow beside three restacked versions](/blog/ai-sprite-animation/crow-recomposition.jpg) In the difference maps, red is extra and blue is missing: ![Difference maps showing red and blue deviations per model](/blog/ai-sprite-animation/crow-difference-map.jpg)

	GPT-Image-2	2.5-flare	2.5-sunburst
Restack overlap with the original	80.1%	94.3%	85.3%
Colour difference	36.6	26.9	23.0
Worst layer out of place	20.6%	5.4%	27.8%

GPT-Image-2 returned the head at about double size - it drew a portrait instead of cutting out a part. Sunburst gave the crow boots a size too big. Flare nailed it. And the layer that has to move is the one that is hardest to put back. Even flare, the best of the three, handed back the sword wing sitting too far forward - far enough that it buries the leather vest underneath and leaves only 24.3% of it showing. Cutting a part out is easy. Pinning it back exactly where it came from is pin the tail on the donkey: the model is blindfolded, spun around, and pointed at the character. A few pixels off is all it takes, and unlike the donkey, a wing pinned in the wrong place tears the shoulder open the moment the arm swings. One thing I learned about measuring: I also tracked "how much of the original is covered", and GPT-Image-2 won it at 99.7% - *because* its huge head covers everything underneath. A metric that a bug can win is not a metric. I dropped it. ### The Payoff Take the seven layers, find the shoulder, and rotate the sword and wing around it while the body dips: ![Eight slash frames produced by rotating extracted layers about the shoulder](/blog/ai-sprite-animation/crow-rig-frames.jpg) ![The rigged slash built from flare's layers](/blog/ai-sprite-animation/crow-rig.gif) Eight frames. **Zero generations.** Every frame is the same pixels in a different place, so the drift is exactly zero. Here's the same rig on each model's layers - you can see GPT-Image-2's oversized head come along for the ride:

GPT-Image-2 layers

2.5-flare layers

2.5-sunburst layers

Per 8-frame action	Generated	Rigged
Model calls	7	0
Setup	none	7 calls, once per character
Head-size drift	up to 27.4%	0%
Change it later	regenerate	change a number

And the math flips the moment a character needs a second animation. Seven calls buys you the character forever, not just one action. To be honest about the trade-off: rigid rotation is not animation. At the ends of the swing the wing looks like a stiff plank, the joint shows a seam, and there's no squash and stretch. The generated frames are more alive and less consistent. The rig is more consistent and less alive. A hand-placed pivot and a couple more joints would close some of that gap, without a single extra model call. And the size of the move decides whether you get away with it. A breathing idle - the torso rising a few pixels, the head bobbing - looks genuinely good. The slash looks horrible: a plank on a hinge, swinging from wherever the model happened to pin the wing. Small moves hide a bad pivot. Big ones put it on screen. --- ## Test 4: Give It a Screen, Ask for the Art Three tests in, the rule was holding. So I tried the request I think most game devs actually have: *here's what my game should look like - make me the assets.* One mock-up of a mobile sort puzzle: fruit mascots on a shelf, pop-it tokens on a board, a funnel full of balls, stacked trays, and a HUD. ![The mock-up: a cosy mobile sort puzzle with mascots on a shelf, pop-it tokens on a board, a ball funnel and stacked trays](/blog/ai-sprite-animation/clone-mockup.jpg) This time there's no base asset. The mock-up itself goes into the edits endpoint, and each call asks for **one** asset from it - "the pink mascot from the shelf", "the coin counter from the top-left" - alone, centred, transparent background, as close to the mock-up as possible. 20 assets, identical prompts, three models. 60 calls, about three minutes. ### 60 Out of 60 ![Ten assets from the mock-up and the same ten from each model: mascots, pop-it tokens, the mystery token and a tray bar](/blog/ai-sprite-animation/clone-assets-1.jpg) ![Ten more: lock badge, coin counter, gear, level plaque, beads, tray bars and a salt shaker](/blog/ai-sprite-animation/clone-assets-2.jpg) Every single one was usable. Same glossy shading, same round shapes, same colour family. Even the text - "600", "Level 5", the "6" on the lock - came out clean in all three. Usable, and a little friendlier than asked. Nobody requested a face on anything, and the models handed them out anyway: every mascot came back with big anime eyes instead of the mock-up's small dots, the plain bead got a kawaii face despite "no face" in the prompt, and flare gave the salt shaker eyes and a smile. A salt shaker. It is funny once and a problem twice - across all 20 assets that is one unrequested face for GPT-Image-2, two for flare, and zero for sunburst. What separates the models is something you never see in one image: does the *set* hold together? Five mascots on one shelf should be the same height.

Across a set	GPT-Image-2	2.5-flare	2.5-sunburst
Height spread, 5 mascots	14.3%	5.7%	8.0%
Height spread, 3 beads	3.2%	1.3%	0.4%
Height spread, 3 tray bars	13.1%	20.8%	4.3%
"No face" followed, 3 beads	2 of 3	2 of 3	3 of 3

Flare kept the characters most consistent. Sunburst kept the shapes most consistent and followed the instructions. GPT-Image-2 drew everything bigger and less consistently - nothing broken, everything a bit off. ### The Mock-Up Beats the Prompt Two things went wrong the same way in all three models, and a third in two of them. ![The dusty blue mascot, the plain blue bead and the salt shaker from the mock-up, beside each model's version](/blog/ai-sprite-animation/clone-priors.jpg) The blue mascot in the mock-up is a muted, dusty blue. All three models made it bright sky blue. And the small dot eyes turned into big anime eyes, in all three. That's the usual kind of prior - what a "cute blue blob" looks like in the training data. The bead is a new kind. The beads in the tray are plain, so the prompt said **no face**. Two of three models drew a face anyway, and it's obvious why when you look at the mock-up: it's full of blue balls with faces. Flare even put a face on the salt shaker. Only sunburst stuck to the prompt. So this time, the thing that beat my instruction wasn't only the training data. It was the picture I gave it. --- ## Putting the Screen Back Together A folder of nice assets doesn't prove much. Test 3 taught me the real check is putting the pieces back, so I did the same with the whole screen: 1. I mapped every asset in the mock-up - 70 of them. 2. I painted all 70 out of the mock-up. That's the background, and the "did nothing" baseline. 3. I put each model's assets back in place, keeping their own proportions. 4. I scored only the areas where assets sit, so the background can't make the number look better. ![The mock-up with a box around each of the 70 asset spots: green where an asset existed, red where there was nothing to place](/blog/ai-sprite-animation/rebuild-instance-map.jpg) The first result came before any number: **my asset list had holes.** In the map above, green had an asset and red had nothing. Nine of the 20 tray bars had nothing - I never asked for flat blue, flat cyan or a green bar with bubbles. The pink bars had bubbles the mock-up doesn't have. The "8" and "15" locks didn't exist. The balls in the pile have faces, and I only had plain ones. And one mistake that's fully mine: I asked for four bubbles on the bars, and the mock-up has three. You don't notice any of that while you look at assets one by one. You notice when something has nowhere to go. So I generated ten more assets per model, 30 more calls: ![The ten missing assets from each model: flat and bubbled tray bars, the 8 and 15 locks, the cyan board disc and balls with faces](/blog/ai-sprite-animation/rebuild-new-slices.jpg) Then I rebuilt the screen: ![The rebuilt screen flicking between the mock-up and the sunburst rebuild](/blog/ai-sprite-animation/rebuild-flicker.gif) On a phone screen, that's the same level. ![The mock-up beside the rebuild from each of the three models](/blog/ai-sprite-animation/rebuild-compare.jpg) ### How Close Is Close? Comparing pixels is brutal. Even a perfect copy of the mock-up, moved by 3 pixels, only scores 72.6% on my measure. So that's the real ceiling, and every number below should be read against it. The score is how much of the error goes away compared with leaving the spot empty.

Score inside the asset spots	GPT-Image-2	2.5-flare	2.5-sunburst	Perfect copy, 3 px off
All 70 assets	47.3%	42.3%	49.4%	72.6%
HUD	51.2%	42.1%	53.4%	65.9%
Board tokens	59.1%	56.1%	60.1%	74.2%
Balls in the pile	51.8%	54.4%	53.0%	68.6%
Tray bars	47.1%	40.4%	48.9%	78.7%
Mascots	27.9%	33.0%	31.9%	79.2%
Lock badges	27.2%	6.6%	31.6%	54.2%

The best rebuild gets about **two-thirds of the way to a perfect copy.** The simple round things - HUD, tokens, balls - get about 80% of the way. Where it falls short shows up in the error maps. Bright means wrong: ![Error heat maps inside the asset spots for each model: the mascots and the seams between tray bars glow brightest](/blog/ai-sprite-animation/rebuild-diff.jpg) **The mascots are bright all over** - about 40% of the way. That's the same priors adding up: brighter colours, bigger eyes, each one a bit too big. **The trays are bright in stripes.** The mock-up bars are tall stacked blocks, and every model drew a flat pill. To be fair to the models, my prompt literally said "seen slightly from above". So the seams between the rows light up: ![Close-up of the trays and locks: the mock-up's tall stacked blocks beside each model's flatter pills](/blog/ai-sprite-animation/rebuild-trays.jpg) Flare drew the thickest pills, the closest shape to the mock-up, and still scored the worst on trays. A closer outline doesn't make a stack. What I should have asked for is the whole tray column, or one bar at the mock-up's real camera angle. The board tokens show the same pull without my help. In the mock-up they're cups seen at an angle, with a visible side. Their prompts didn't name an angle, and all three models drew them straight from above anyway. And flare's locks scored 6.6%. It redesigned the padlock - keyhole, ribbon, sticking out of the badge - the same way on all three locks. ### I Almost Published My Own Bug My first rebuild said the trays were a disaster: 35%. I already had the explanation written. Then I checked my own code. I had placed every bar at the bottom of its slot. Stacked bars only show their top edge, so every row sat about 30 pixels too low, and the whole bottom row was hidden under the panel. After the fix, the trays went to 49% and the overall score from 44% to 49%. The explanation survived, just smaller. But the original number was my mistake, not the models'. Before you explain your worst result, check that it isn't your own bug. --- ## The One Rule Four tests, 153 generations, and it all comes down to one sentence: > **These models draw a thing. They don't remember the sequence it belongs to.**

	Coin spin	Crow slash	Crow layers	Game screen
Each call asked for	a step in a rotation	a pose	a part	an asset from a mock-up
Can you draw it on its own?	no	yes	yes	yes
Result	failed, all 3	worked, all 3	worked, all 3	worked, 60 of 60

A part is a thing. A pose is a thing. An asset is a thing. "Frame 3 of 8" is not. Test 4 added a second sentence, and I think it matters most for anyone making game art from a reference: > **What you give the model matters more than what you tell it.** Give it a screen full of faces, and two out of three models will give you faces, no matter what the prompt says. ## What I'd Actually Do **Bring in an art director or an animator, and hand them the tools.** That is the honest answer. None of this replaces the person who knows why a silhouette reads or why a swing needs anticipation - it changes what that person spends their day on. They stop drawing the eighth frame by hand and start directing the generation, judging the set, and fixing the ten percent that matters. A prompt is not an art direction, and a diff map is not an eye. **And use a real animation tool.** My rig is a hundred lines of rotation around an estimated shoulder, which is why the slash reads like a plank. [Spine](https://esotericsoftware.com/) - or any proper 2D skeletal tool - gives you weighted meshes, real joints, easing and secondary motion on the same layers the models cut for you. The generation step stays exactly as described below. The animation step belongs in software built for it. The rest of what I would do: For animation: 1. **Generate the character once.** Pad the canvas first - every base I generated ran its sword off the edge, even when I asked for margin. 2. **Cut it into layers once.** Seven calls per character. 3. **Animate by moving the layers.** Every action after that is free, consistent, and easy to change. 4. **Keep generation for what it's good at** - a new character, a new costume, a key pose. Not frame-by-frame motion. 5. **If you must generate frames**, ask for poses, not steps in a sequence. Use symmetry when you have it, and line everything up to a landmark afterwards. For a whole screen: 1. **List every asset before you start.** Every colour, every state, every number on screen. 2. **One asset per call, with the mock-up as the reference.** It holds the style better than any description I could write. 3. **Say the colours and the camera angle out loud.** Muted colours come back bright, and everything comes back seen from above unless you say otherwise. 4. **Crop the reference if it's full of something you don't want.** A "no" in the prompt loses to a screen full of the thing. 5. **Rebuild the screen before you trust the set.** Every problem in test 4 was invisible one asset at a time. ## Not Game-Ready Yet Straight answer: none of the three models passed. Nothing in this post is a sprite I would drop into a real game today. Every result here is a starting point, not a finished asset. Getting one frame to production quality is still worth about another ten prompts on its own - fix the hands, pull the colours back, re-cut a layer, line it up again - and then a pass by hand at the end. Multiply that by eight frames and the "free art" story falls apart. It is getting better. A 2.5 model came out ahead on almost every measure I took, and the layer trick is good enough that I will keep using it. But better is not done. We are not there yet. ## What I Still Don't Know A lot. An endless list, and every test I run adds to it faster than it crosses anything off. That is the actual state of this: not a solved workflow, a thing you keep working at. The one thing I am sure of is the direction - each generation of these models is visibly better than the one before, and the gap between "nice picture" and "usable asset" keeps getting smaller. One run per test. One coin, one crow, one rig plan, one mock-up. The model rankings moved in every test, which is exactly what you'd expect from one run with small gaps. Trust the patterns, not the order. I haven't tried a hard character yet - a flowing cloak, hair over the face, overlapping armour. That's where I'd expect the layer cutting to break. I also never checked the hidden areas the models painted in behind the layers. The first time a layer moves far enough, we'll find out. And the screen rebuild only covers the assets. The board, the wooden frame, the tray track, the shelf and the wall - three-quarters of the screen - were never generated. I also haven't tried the fixes the rebuild points to: slicing the tray as a whole column, cropping the reference for each asset, and naming the camera angle. That's next, and I'll share what I find. If you run something like this and get different results, I really want to hear about it. --- If you want to build games with AI this way - trying the tools on real projects, then checking honestly what actually worked - that's the mindset we teach. You're the director, not the typist: the AI generates, and you decide what's good enough. Check out our [Vibe Coding course](/vibe-coding).

Vibe Coding Course - learn to build games with AI

Want to learn how to build real games with AI - and how to tell when the AI got it wrong? Join our Vibe Coding course and start building real projects from day one.

Join the Vibe Coding Course →

--- *Images generated with GPT-Image-2, GPT-Image-2.5-flare and GPT-Image-2.5-sunburst on Azure. The measuring scripts and charts were built with the help of [Claude Code](https://claude.ai/code) - practicing what we preach.*

SBS Games Blog

AI Can Draw Any Frame. Animation... Is Not Its Strong Suit.