uwo -- un format bitmap comme les autres
Posté le 15/04/2022 17:50
J'avais besoin d'un format d'image (très) simple, me permettant de l'utiliser dans mes projets divers sans me soucier de la complexité liée à la plupart des librairies. Voyez vous, j'ai tendance à réinventer la roue même quand il ne faut (vraiment) pas.
Mon cas d'usage est la création d'un jeu tel qu'un visual novel sur calculatrice, avec énormèment d'image plein écran qui ne tiendraient juste pas dans un add-in et serait incroyablement long à transférer entre chaque itération. Je voulais aussi pouvoir l'utiliser dans mes projets SDL2, pour pouvoir avoir une toolchain commune à mes deux cibles principales.
Je me suis intéressé au format d'image
Farbfeld, mais son usage de prédilection n'est pas les jeux vidéos. Les images Farbfeld prenne plus d'espace disque que ce que je considère raisonnable.
Étant donné qu'aucune alternative connue n'était parfaitement adaptée à mes besoins, j'ai créé mon propre format d'image et deux utilitaires essentiels en une nuit sans sommeil.
Je vous présente
uwo, un format d'image spécialisé.
+---------+-----------------------+
| Bytes | Description |
+---------+-----------------------+
| 3 | "uwo" magic |
+---------+-----------------------+
| 2 | 16-bit BE uint width |
+---------+-----------------------+
| 2 | 16-bit BE uint height |
+---------+-----------------------+
| 1 | Colormap size |
+---------+-----------------------+
| [1 1 1] | RGB colormap |
+---------+-----------------------+
| [1 1 1] | RGB data, Row-Major |
| [1] | Colormap index, RM |
+---------+-----------------------+
Comme vous pouvez le voir, le format est extrêmement simpliste. C'est un format bitmap avec un header minuscule, et croyez le ou non mais je n'en ai pas trouvé de similaire en mainstream. Il fait exactement ce dont j'ai besoin, ni plus ni moins.
La taille des fichiers est très correcte pour les images en pixel art. Une image plein écran sur 90+E (396x224) pèse dans les alentours de 90 Ko, ce qui se transcrit en une bonne centaine d'images trop larges (ie. tout les produits de Masséna) dans moins de 10 Mo. Bien plus que nécessaire pour la plupart des projets.
Les utilitaires
https://git.sr.ht/~kikoodx/uwo/
Le dépôt ci-dessus contient les deux programmes nécessaires pour utiliser UWO. Ils ont été programmés en C, car je considère que les éléments critiques d'une toolchain doivent être rapides.
Le premier,
convuwo, prend une image en argument et écrit l'image convertie en UWO sur la sortie standard.
Exemple :
convuwo image.png > image.uwo
Le second,
uwov, prend un fichier UWO en argument et l'affiche dans une fenêtre SDL2.
Exemple :
uwov image.uwo
Exemple d'utilisation
Il est très facile d'ajouter une règle dans un Makefile dans le but de convertir tous les assets .png en .uwo, permettant de se débarasser de la dépendance à SDL_image à la sortie par exemple.
UWO := $(patsubst %.png,%.uwo,$(wildcard *.png))
all: $(UWO)
%.uwo: %.png
convuwo $< > $@
clean:
rm -f $(UWO)
Et... c'est tout. Vous pouvez sûrement programmer une fonction qui charge les .uwo dans votre projet en une demi-heure
Que reste-t-il à faire ?
J'attend que Lephé finalise gint 2.8, puis j'écrirai une librairie permettant de charger des images UWO embarquées ou non en tant que bopti.
Un de mes objectifs sera aussi de l'intégrer à LZY, pour rendre le développement cross platform encore plus pratique.
Pourquoi cette fausse FAQ ?
Je suis trop fatigué pour rédiger des paragraphes construits.
M'a-t-on bercé trop près du mur ?
Il faut admettre que j'ai la pire hygiène de sommeil du site.
Si vous avez des retours ou commentaires, ils sont bienvenus.
Citer : Posté le 15/04/2022 17:57 | #
Si j'ai bien suivi c'est essentiellement pareil que P8 ? Note que tu peux déjà générer des fichiers comme ça avec fxconv (puis en tirer le binaire avec objcopy) et les charger sur la calto par un simple malloc + fread (Potter360 le fait notamment).
L'expérience est marrante dans tous les cas. Mon cerveau essaie juste de voir la différence fonctionnelle pure pour savoir s'il y a un truc qui manque cruellement à nos outils actuels ou c'est surtout une alternative similaire à ce qui se fait.
Aussi, j'avais pensé à un truc similaire récemment où on pourrait encoder des images en P4 par morceaux. Je suis à peu près sûr que ça diviserait par presque 2 le poids total.
Citer : Posté le 15/04/2022 18:07 | #
Exactement, c'est comme P8. J'avais besoin de quelque chose d'un poil différent, avec des outils C qui fonctionnent dans mon workflow calto/ordi
L'alternative est similaire à ce qui se fait. Le projet vient plus de ma frustration fasse à tous les autres formats (j'ai fait des recherches), et une décision radicale de faire simple.
Aussi, j'avais pensé à un truc similaire récemment où on pourrait encoder des images en P4 par morceaux. Je suis à peu près sûr que ça diviserait par presque 2 le poids total.
Oh ouais, ça me semble une très bonne idée. C'est un peu ce qu'il se faisait sur les vieilles consoles à palette en pratique, avec grand succès.
Citer : Posté le 15/04/2022 18:07 | #
Yo KikooDX
Chapeau pour le développement, mais effectivement tu t'es cassé la tête pour rien, car ton format existe déjà, il s'agit du format Portable Pixmap dont plusieurs sous formats existent qui qui sont gérés par pas mal de logiciels (Gimp, SDL_image, ...)
Dans ton cas c'est le sous format PPM (couleurs RGB) : https://fr.wikipedia.org/wiki/Portable_pixmap
Pour le format UWO, je te conseillerai tout de meme de faire à minima une compression RLE, surtout pour des grosses images, tu gagneras pas mal d'espace sans cramer trop de ressources à la décompression.
Sly
Citer : Posté le 15/04/2022 18:11 | #
Salut Slyvtt, j'avais fait mes recherches sur les formats PPM (en l'occurence PBM ici) et écrit des programmes avec, je n'étais pas satisfait dans l'absolu. C'était une des meilleures options, mais ça ne collait pas parfaitement à mon utilisation et il y a trop de détails qui font bruit dans cette spécification.
La compression RLE n'est pas nécessaire du tout, le gain d'espace est négligeable quand on parle de dizaines de Ko et complexifie largement le format. Si quelqu'un a besoin de RLE, je pense qu'ils peuvent passer direct à QOI ou PNG.
Merci pour ton retour constructif
Citer : Posté le 15/04/2022 18:11 | #
T'as bien raison, je trouve que c'est aussi une faiblesse du fxSDK : pas mal de trucs sont trop orientés calto. Ultimement j'aimerais bien casser ce problème pour pouvoir faire des programmes plus portables...
Si QOI ne s'avère pas assez petit (j'ai toujours un doute parce qu'il compresse depuis le full-color), on pourrait au moins passer un peu de temps là-dessus. J'ai bien envie d'arranger ça perso, gint prend déjà pas mal de poids en code, et les add-ins au-delà de 400 kio c'est juste vraiment chiant à transférer !
Edit : RLE c'est pas négligeable surtout quand t'as peu de couleurs ! Plus complexe oui, mais définitivement utile IMHO.
Citer : Posté le 15/04/2022 18:18 | #
Même réponse qu'à Slyvtt, le RLE n'est pas négligeable dans certains cas mais pour les images en pixel art le gain est généralement très mineur et ne vaut pas la complexité (dans ma situation). Si j'avais besoin de gagner de la place sur une image vraiment gigantesque, j'aurais tendance à utiliser un algorithme de compression/décompression existant sur l'image brute.
Citer : Posté le 15/04/2022 20:59 | #
Note que tu peux déjà générer des fichiers comme ça avec fxconv (puis en tirer le binaire avec objcopy) et les charger sur la calto par un simple malloc + fread (Potter360 le fait notamment).
Mmm, alors ça ne me dit rien, tu dois te tromper de personne
Très stylé Kdx, bravo.
Citer : Posté le 15/04/2022 21:01 | #
Pardon c'est Farhi ! Merci pour la correction.
Citer : Posté le 15/04/2022 21:06 | #
Oui c'est lui je crois ! Pas de souci.