Sprites de créatures · Le processus
Quelques pixels doivent produire
des milliers de mouvements.
Un personnage de Baldur’s Gate II tient parfois dans quelques dizaines de pixels. Le but n’est pas de le redessiner, mais de garder la même silhouette, les mêmes couleurs et les mêmes animations, avec un rendu plus propre sur un écran moderne.
- ×2échelle retenue
- 10 323frames pour CHFF4
- 8 527BAM de sprites inventoriés
Les deux choix habituels
Nearest reste net,
tandis que Linear devient flou.
Nearest conserve chaque carré. Linear mélange les pixels voisins. L’un paraît trop brut, l’autre efface les petits détails.
Pourquoi pas SeedVR ?
Les sprites sont trop petits
pour être confiés à SeedVR.
SeedVR fonctionne très bien quand l’image contient assez de matière. Ici, un visage peut tenir sur quatre ou cinq pixels. Un modèle génératif devrait réinventer les yeux, l’armure ou l’arme à chaque frame.
Sur une carte, reconstruire aide. Sur un sprite, deviner change le personnage.
Un outil pensé pour le pixel art
Une même frame est comparée
avec neuf méthodes.
ScalePix tourne en local et permet de comparer plusieurs méthodes spécialisées. La recette retenue est xBR2x, en une seule passe, sans anticrénelage.
Pourquoi ×2 plutôt que ×4
Le gain utile se trouve au ×2.
Une fois le filtre d’affichage appliqué, le ×4 n’apportait pas une différence suffisante. Par rapport au ×2, chaque frame contient pourtant quatre fois plus de pixels.
Jamais une grande planche
Chaque frame est traitée
séparément.
Chaque image est traitée séparément. L’ordre, les cycles, les centres et la transparence doivent rester exactement là où le moteur les attend.
- 01
Lire
Ouvrir le BAM original et sa structure.
- 02
Extraire
Séparer chaque cycle et chaque frame.
- 03
Agrandir
Appliquer xBR2x une fois, sans AA.
- 04
Vérifier
Garder les centres, l’alpha et l’ordre.
- 05
Cataloguer
Donner au moteur la bonne frame HD.
Claude et Codex m’ont aidé à construire les outils qui inventorient, extraient, traitent et contrôlent ces frames. Le travail répétitif tourne par lot ; les choix visuels restent humains.
Fausses couleurs, vraies contraintes
Ces couleurs servent
de repères au moteur.
Les zones vertes, roses, rouges et bleues servent d’instructions. Le jeu les remplace au moment du rendu par les gammes choisies pour le personnage.
Ces indices doivent survivre à l’upscale. Ajouter librement des nuances ou peindre un nouveau dégradé empêcherait une recoloration fiable.
Un autre type de sprite
Le gobelin contient déjà
ses vraies couleurs.
Contrairement à la guerrière jouable, ce gobelin n’utilise pas les fausses couleurs de palette. Sa peau verte, ses vêtements et son équipement sont directement enregistrés dans chaque frame.
Un personnage est assemblé
Le jeu assemble le corps
et l’équipement.
Le jeu ne stocke pas toutes les combinaisons finales. Il choisit les couches correspondant aux objets équipés, aligne la direction et la frame, puis construit un seul personnage pour l’affichage.
Assemblage final en jeuLa dernière étape se fait dans le moteur
xBR crée les pixels avant
l’affichage Catmull-Rom.
Catmull-Rom est une interpolation cubique contrôlée. Réglée à −0,25, elle adoucit les marches les plus dures sans étaler l’image comme Linear.
Dshaders 0.3.5 ciblait l’ancien fonctionnement du jeu et ne pouvait pas simplement être réinstallé sur la 2.7. Le jeu contenait bien un chemin Catmull-Rom, mais prévu pour des images opaques et avec un alpha forcé. Les sprites transparents avaient besoin de leur propre intégration.
Démonstration finale · En jeu
La guerrière est comparée
dans trois modes de rendu.
Trois captures alignées : même zone, même pose et mêmes couleurs. Seul le mode de rendu du sprite change.
Sprite natif ×1NearestMême scène · même pose
Sprite natif ×1LinearMême scène · même pose
Sprite xBRZ ×2Catmull-Rom · netteté −0,25Sans contour normalLe résultat recherché
Le sprite final reste fidèle
au personnage d’origine.
Pas de nouveau design, pas de détails inventés : seulement l’animation d’origine, traitée avec plus de soin sur un écran moderne.