Creature sprites · The process
A few pixels must produce
thousands of movements.
A Baldur’s Gate II character can be only a few dozen pixels tall. The goal is not to redraw her. It is to keep the same silhouette, colours and animation, with a cleaner result on a modern screen.
- ×2chosen scale
- 10,323frames for CHFF4
- 8,527sprite BAMs inventoried
The two usual choices
Nearest stays sharp,
while Linear becomes blurry.
Nearest keeps every square. Linear mixes neighbouring pixels. One looks too blocky; the other washes away the small details.
Why not SeedVR?
The sprites are too small
to be processed with SeedVR.
SeedVR works well when an image contains enough material. Here, a face can fit into four or five pixels. A generative model would have to invent the eyes, armour or weapon again on every frame.
For maps, reconstruction helps. For sprites, guessing changes the character.
A tool made for pixel art
The same frame is compared
with nine methods.
ScalePix runs locally and puts several specialised algorithms side by side. The retained recipe is xBR2x, one pass, without antialiasing.
Why ×2, not ×4
The useful gain happens at ×2.
Once the display filter is applied, ×4 did not look different enough to justify its cost. Compared with ×2, every frame contains four times as many pixels.
Never one big sprite sheet
Every frame is processed
separately.
Each image is processed on its own. Order, animation cycles, centre points and transparency must remain exactly where the engine expects them.
- 01
Read
Open the original BAM and its structure.
- 02
Extract
Separate every cycle and frame.
- 03
Upscale
Run xBR2x once, without AA.
- 04
Verify
Keep centres, alpha and frame order.
- 05
Catalogue
Give the engine the matching HD frame.
Claude and Codex helped build the tools that inventory, extract, process and verify these frames. The repeatable work runs in batches; the visual decisions stay human.
False colours, real constraints
These colours act as
references for the engine.
The bright green, pink, red and blue areas are instructions. The game replaces them at runtime with the character’s chosen colour ranges.
Those indices have to survive the upscale. Adding arbitrary shades or painting a new gradient would break reliable recolouring.
Another kind of sprite
The goblin already contains
its real colours.
Unlike the playable fighter, this goblin is not false-colour palettised. Its green skin, clothes and equipment are stored directly in the frame, so the comparison appears naturally coloured.
A character is assembled
The game assembles the body
and its equipment.
The game does not store every final combination. It picks the layers matching the equipped items, aligns their direction and frame, then builds one character for the draw.
Final assembly in gameThe last step happens in the engine
xBR creates the pixels before
Catmull-Rom displays them.
Catmull-Rom is a controlled cubic interpolation. At −0.25, it softens the hardest steps without spreading the image like Linear.
Dshaders 0.3.5 was built around the older game pipeline and could not simply be dropped into 2.7. The game did contain a Catmull-Rom path, but it was made for opaque images and forced alpha to full. Transparent sprites needed their own integration.
Final proof · In game
The warrior is compared
in three render modes.
Three matched captures: same area, pose and colours. Only the sprite rendering mode changes.
Native sprite ×1NearestExact scene · exact pose
Native sprite ×1LinearExact scene · exact pose
xBRZ sprite ×2Catmull-Rom · sharpness −0.25No normal outlineThe result I am after
The final sprite stays faithful
to the original character.
No new character design, no invented details — just the original animation treated with more care on a modern display.