Animation: pixel art that moves — frames for pixeledit, motion craft, sheet delivery #39
Labels
No labels
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
cmoriarty/trog#39
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Split out of #38 at the user's direction: animation deserves its own focused effort rather than riding along.
Why
Nothing this studio has made moves like the bar moves (Celeste, Dead Cells). The #38 ladder fixed engineering feedback (playtest with frames) and stills (pixeledit + draw/tweak tools); motion is the biggest remaining gap to the stated quality bar, and it has been the weakest area since #20 (pix3lwalk covers walk cycles only; object motion failed twice in #17).
Starting points (from #38 / docs/pixel-art-craft.md)
frameslist (each frame = ops, or ops-as-diff against frame 1), rendered to a sheet + manifest — the same shapeanimated_spritealready delivers from the diffusion path, so the game-side loading contract is already defined (sheet PNG + frameWidth/frameHeight/fps JSON).tweak_pixel_artper frame ("left leg forward"), assemble the sheet. Zero new renderer work; tests whether program-space tweaking preserves identity across frames — the thing diffusion i2v struggles with.Bar
Judged in a playable game, same as everything since #37: a character whose idle/walk/action cycles read at played size, delivered as sheets the code agent actually wires up.
trog test bakeoffremains the harness; an animation-focused fixture brief probably wants adding.