Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.

Forum Casio - Projets de programmation


Index du Forum » Projets de programmation » uwo -- un format bitmap comme les autres
Kikoodx Hors ligne Labélisateur Points: 2979 Défis: 11 Message

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.


Lephenixnoir En ligne Administrateur Points: 22590 Défis: 149 Message

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.
Kikoodx Hors ligne Labélisateur Points: 2979 Défis: 11 Message

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.

Lephé a écrit :
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.
mi lape ala.

J'suis un méga chômeur
Slyvtt Hors ligne Community Manager Points: 832 Défis: 0 Message

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
Kikoodx Hors ligne Labélisateur Points: 2979 Défis: 11 Message

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
mi lape ala.

J'suis un méga chômeur
Lephenixnoir En ligne Administrateur Points: 22590 Défis: 149 Message

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...

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.

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.
Kikoodx Hors ligne Labélisateur Points: 2979 Défis: 11 Message

Citer : Posté le 15/04/2022 18:18 | #


Edit : RLE c'est pas négligeable surtout quand t'as peu de couleurs ! Plus complexe oui, mais définitivement utile IMHO.

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.
mi lape ala.

J'suis un méga chômeur
Potter360 Hors ligne Rédacteur Points: 1116 Défis: 0 Message

Citer : Posté le 15/04/2022 20:59 | #


Lephenixnoir a écrit :
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.
Globalement, coder. Mal, mais coder.
Lephenixnoir En ligne Administrateur Points: 22590 Défis: 149 Message

Citer : Posté le 15/04/2022 21:01 | #


Pardon c'est Farhi ! Merci pour la correction.
Potter360 Hors ligne Rédacteur Points: 1116 Défis: 0 Message

Citer : Posté le 15/04/2022 21:06 | #


Oui c'est lui je crois ! Pas de souci.
Globalement, coder. Mal, mais coder.

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2022 | Il y a 90 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd