SpriteDX

Excuse much nonsense here. This is more of a lab notes than a blog.

Visualizing the Problem

Base Image

Visualization of Patches

Let’s zoom in:

The row 2 col 4 shows a even horizontal gradient.

In this case it is rather ambigous within the patch itself whether it makes sense to use white or black or even gray.

Pixel artist would choose white. here to draw a clean boundary. because the tile on the right is a outline tile and outlines of this image is single pixel wide.

However, for a model, this isn’t that obvious. There is some hidden context it is missing.

Hand Pixel Results

We used various pixel patch size. So far, 5x5 and 4×4 seems to give the most reasonable result.

160×160 makes up 25600 pixels
128×128 makes up 16384 pixels
So the h160 one requires 1.56x more work to hand pixel.
Overall, quality wise h160 looks the best and gives it more subtle feel.
h128 is acceptable.
From the point of view of SpriteDX, we need to be able to support various pixel patch sizes.
Even though we want to use h160 increasing this size means it will impact the rest of the assets like backgrounds. h160 means background assets will have to be large enough to accommodate that.
So, thinking is that we still opt for h128.

Various styles against a sample background:

h128 with 2x nearest neighbor zoom with bilinear blur seems to be giving good result.
h128 scale roughly matches the Ragnarok Online pixel DPI.

Various Sprite Scales:

Background Test:

Takeaways:

The problem of solving pixel alignment can be reduced to picking the “best color” from its pixel patch dimensions.
h128 seems to provide reasonable result with reasonable correspondence to other pixel arts.
Alternatively h80 also works if outline is not excessively used.
🤔 Could it be that we use the original generated pixel art animation. And just engineer a generated pixel art shader which picks the right color real time or at compile time.
- This should allow for adopting generated pixel art for any scale at runtime based on current need.
- That is, if character is zoomed out, we can present zoomed out render.
- Input would require though the size of outline, e.g. 0, 1, 1.2, 1.5, 2 etc.
Generating backgrounds can be done by passing character art with white background then asking model to add background, then running that image though Flux 2 Pro again to remove character.
Pixel scale of background does NOT have to match exactly to the background pixel scale. This actually provides some “depth.”

Next Steps:

I know I’m wasting lots of time in this effort, but I do want to get this part right.
As a next step, after lunch, I will work on pseudo-pixel art filter. Which generated pseudo version of upscaled pixel arts from legit pixel arts.
This should reveal whether it is possible to reliably create those input data for model training.

— Sprited Dev 🌱