I trained a pixel art spritesheet LoRA on FLUX.2 Klein base 4B. For a first attempt using small sprites, I think it's pretty good.
First 3 rows are text-to-image. Last row uses edit workflow with image references.
| Website | https://svntax.me |
@svntax
- 1 Followers
- 2 Following
- 27 Posts
Game Developer | Full-Stack Developer | Likes pixel art, game jams, and hackathons.
Sadly, the actual spritesheets from this LoRA are just too messy. Prompt adherence is pretty good, but I think the dataset and the fact that Z-Image Turbo is distilled make the pixels noisy and inconsistent. Or maybe 64x64 sprites are just too large and more prone to issues.
In the process of training pixel art spritesheet LoRAs, I've noticed that Z-Image Turbo is capable of more general images like portraits, even though the dataset is purely spritesheets.
Sample images at 64x64 and 128x128 (same post-processing steps for all: k-centroid downscale, palettize).
I trained a Z-Image pixel art LoRA just for testing purposes. Even though it's a distilled model (and my dataset is rough), results are not too bad with a little post-processing.
I've been working on a Minesweeper-like game using a Godot + NEAR Protocol SDK I made years ago, now up-to-date with support for Intear wallet.
You play as a dwarf digging for gold & gems while avoiding traps.
You can set a subregion of a sprite so that smear effects are applied to that area only.
I tried making a procedural animation tool that generates smear frames for any image. It's bare-bones, but working.
RPG prototype with generated characters using Retro Diffusion's API, set up as a summoning mechanic.