mlres - Release

mlres est dans les bacs! La seule différence depuis mon post précédent est que maintenant il est possible d'inclure toutes les variables dans un namespace (ce qui restreint évidemment le code au C++ lorsque cette option est utilisée).

Le paquet est disponible sur la page AdH de SourceForge.

Voilà les Release Notes:


PRESENTATION

mlres est un aggrégateur de ressources C/C++ écrit en ocaml. Il aggrège des ressources binaires et en génère un fichier source dans lequel les ressources sont encodées comme des tableaux de caractères. Le source peut être ensuide directement compilé avec votre programme, ce qui vous permet de distribuer vos ressources (images, sons...) au sein de l'executable, sans avoir à les fournir en des fichiers séparés.

Bien sûr, la taille de ces ressources doit rester modeste (quelques mégaoctets?).

USAGE

./mlres.run -help donne la liste des options. Un exemple d'utilisation serait:

./mlres.run -output Resources -namespace resources image.png sound.wav

qui va générer un fichier Resources.cpp et un fichier Resources.h, qui définissent deux variables "image" et "sound", dans le namespace "resources".

COMPILATION

La distribution inclut le programme compilé en bytecode, testé avec ocaml 3.10.2. Si vous desirez compiler vous-même le bytecode ou le code natif, vous aurez besoin de OMake (http://omake.metaprl.org/index.html). Pour compiler, tapez:

omake

LICENSE

mlres est distribué sous la GPL v3 ou ultérieure. Il n'y a aucune restriction sur les fichiers qui en sont générés.

PLUS D'INFORMATIONS

Plus d'informations à http://www.sf.net/projects/adh ou à http://aubedesheros.blogspot.com

mlres - Un aggrégateur de ressources C/C++

N'est-ce pas particulièrement ennuyeux d'avoir à fournir avec son programme quantité de petits fichiers image et son? D'abord parce que l'installation en est rendue plus complexe et le nombre de bugs potentiels dus à une mauvaise version / absence du fichier est augmentée d'autant, et ensuite parce que l'utilisateur peut aller tripatouiller de ses doigts sales (l'utilisateur a les doigts sales par définition) dans les entrailles multimédia de votre chef-d'œuvre.

Windows l'avait fait via les fichiers de ressources.

Mais wxWidgets l'avait également fait avec un petit programme répondant au doux nom de wxrc, qui empaquette les ressources dans un fichier source, que l'on peut compiler avec son programme.

C'est à une version simplifiée, et surtout indépendante du framework, que je me suis attaqué ces derniers jours. Une version très beta a vu le jour, dont vous pourrez trouver le code source sur sourceforge (le paquet verra le jour quand je serai plus confiant en la stabilité du bazar).

mlres est donc un petit programme ocaml (mon langage préféré pour écrire de petits utilitaires en ligne de commande) qui lit les fichiers passés en argument, et créé un fichier source avec les données binaires.

Démonstration.

./mlres.opt -help
mlres [options] [files list]
  -output  Output file base name (out)
  -hext  Header extension (h)
  -sext  Source extension (cpp)
  -help  Display this list of options
  --help  Display this list of options

Allons-y donc gaiement, et essayons d'empaqueter quelques images.

./mlres.run -output resources book16.png  book24.png  book36.png coin32.png

Et voyons ce qu'il y a dans resources.h

extern unsigned char coin32[1992];
extern unsigned char book36[1170];
extern unsigned char book24[812];
extern unsigned char book16[516];

et resources.cpp

#include "resources.h"

unsigned char coin32[1992] = {137,80,78,71,13,10,26,10,0,0,0,13,7,[...]};
unsigned char book36[1170] = {137,80,78,71,13,10,26,10,0,0,0,13,7,[...]};
...

Le fichier compile sans soucis, et l'on peut ensuite directement charger ses ressources à partir de leur emplacement mémoire!

Bien sûr, ce genre de manœuvre est réservée à des programmes petits, qui n'ont tout au plus que quelques mégaoctets de données. Pour quoi que ce soit de plus gros, il faudra penser soit à vivre avec un répertoire contenant les données, soit à écrire son propre format de fichiers de ressources et à charger le bon bout à la volée (voir ce très bon tutoriel).

Bonne année!

Quand je disais qu'une tablette graphique, ça change la vie?

Bonne année à tous!

Tablette graphique

Je suis maintenant l'heureux propriétaire d'une tablette graphique Wacom (modèle Bamboo Fun)! Après avoir passé pas mal de temps à la configurer sous mon OS favori, me voilà me réjouissant du dessin à main levée et des niveaux de pression.

Sous Gimp, aucun doute, la tablette change la vie. Pouvoir enfin dessiner comme sur du papier se ressent immédiatement comme un avantage considérable, et permet des trais impossibles à la souris.

Sous Inkscape, je n'ai pas encore trouvé comment utiliser les niveaux de pression, ni la gomme. Cependant, le placement des formes est grandement amélioré, et je pense que l'outil s'avèrera particulièrement utile pour encrer des dessins à la courbe de Bézier (sans s - le correcteur orthographique connait apparemment la ville, mais pas l'ingénieur ENSAM/Supelec...).

Sous Blender, c'est nettement plus bof. Ceci dit, je fais très peu de main levée dans Blender. Peut-être certains modes de type sculpture en feraient une meilleure utilisation?

Techniquement, c'est bon...

Vive le Blender Book! En quelques minutes, j'avais compris comment ajouter une texture, en l'occurence un bandeau rouge au travers de mon wagon.



Ayant exporté le wagon au format Obj, osgviewer se fit un plaisir de me l'afficher.



Bien sûr, maintenant, la vraie difficulté est de dessiner une texture qui aille un peu plus loin que le "programmer's art"...

Un train avec Blender

Un wagon rapidement modélisé avec Blender. La prochaine étape, c'est d'y ajouter de jolies textures!

Je n'aime pas les "bindings"

C'est bête, et pourtant, Je sens comme une gêne confuse à utiliser une bibliothèque qui a été développé dans un autre langage que celui que j'utilise. D'un côté, je suis bien évidemment ravi de trouver la bibliothèque qui fait ce dont j'ai besoin. Mais de l'autre, si j'utilise un langage, c'est que j'en admire ses qualités. Pourquoi donc ne pourrait-on pas implémenter cette bibliothèque si utile en natif?

D'accord, dans certains cas, plus particulièrement lorsque l'on est près du matériel, c'est stupide. Qui va s'amuser à ré-implémenter OpenGL en Perl natif? Mais quand il n'y a rien qui semble particulièrement bloquant, pourquoi s'embêter avec les usages ésotériques, la difficulté à débugger, sans parler du coup de boule dans le paradigme. Ah, et j'oubliais les bindings qui ne sont pas maintenus à jour pendant que la bibliothèque sous-jacente propose de nouvelles fonctionnalités.

Si l'on peut trouver une bonne raison de réinventer la roue, que ce soit celle là.