Re: [Camelot-discuss] pak file ou autres...

[Sven Luther]

On Wed, Feb 05, 2003 at 10:51:33AM +0100, Jérôme Marant wrote:
> En réponse à Luc Mazardo <address@hidden>:
> 
> > Je pense que l'on pourrait s'inspirer de la meme chose.
> > Faut il faire un truc tres compliqué ?? Je ne sais pas trop si ca vaut
> > le coup de faire quelque chose de plus elaboré.
> > Il manque peut etre des checksums sur les fichiers.

Peut tu nous decrire un peu le format utilise par les .paks ?

> > Connaissez vous d'autres formats ?

ben j'ai commencer un petit parseur des fichiers utiliser par l'infinity
engine, mais bon, a nouveau, c'est pas joli joli :

http://www.ugcs.caltech.edu/~jedwin/baldur.html

> Personnellement, je pense que ce problème de format et
> d'organisation des données est la moindre des priorités
> dans le projet, et je pense que vous serez d'accord avec
> moi.

Oui, avant de penser au format, il faut deja savoir quelles donnees on
va traiter.

> Pour l'instant, nous prenons les fichiers de données tels
> quels, et je ne pense pas que ça pose de problème.

Oui, ...

> Pour en revenir au problème de SVG, il est vrai que c'est embêtant
> d'avoir toutes ces dépendances sur des libs gtk, dont nous
> n'avons pas besoin.
> Ne serait-il pas possible de modifier la librsvg pour quelle
> attaque directement une surface SDL? Sven avait l'air de
> dire qu'il n'y avait pas une quantité énorme de fonctions.

Oui, mais bon, pour un debut, cela devrait faire l'affaire, apres on
peut modifier librsvg (il y a aussi xrsvg, qui est une modif de rsvg
pour X directement). Cependant, un rapide coup d'oeil me dit que cette
modification serait relativement extensive, car le format GdkPixbuf est
utiliser comme structure de donnée pour decoder les SVG, et certe il n'y
a pas une grande quantite de fonctions externes, mais pas mal de choses
privees. donc ...

Remarque, corriger moi si je me trompe, mais le code natif se lie
dynamiquement avec les librairies C utilises, et il en est de meme avec
les librairies dll.so utiliser par le bytecode non custom. Donc, il
s'agit juste d'avoir ces librairies installe sur le systeme, ce qui
n'est pas un gros probleme. Meme sur un desktop KDE, glib devrait etre
present.

Ceci dis, rsvg ne permet que d'agrandir/rapetisser des images, pas
d'effectuer des rotations ou autres. Cependant, comme le format SVG est
un format XML et donc texte, il devrait etre possible d'appliquer a la
vollee des rotation de chemin ou autre, simplement en ajoutant un bout
de chaine de caractere. Et comme on fournit a librsvg un pointeur sur la
chaine de caractere, rien de plus facile.

Une autre idée c'est d'ecrire, plus tard, notre propre decodeur de SVG,
a priori, il y a pas de raison, ocaml devrait permettre de decoder du
SVG (du XML en fait) au moins aussi bien que du C, non ? Cela
permettrait du coup de l'etendre avec des possibilites de rotations et
autre.

Bon, moi je suis partant pour realiser des bindings librsvg ce WE, cela
ne devrait pas prendre plus d'une heure ou deux, et je devrait alors
pouvoir realiser un petit programme qui affiche des tuiles et les fait
descendre. Ce serait un debut de tetris, qu'il faudrait bien sur
completer par la logique du jeu et des graphismes, etc.

Amicalement,

Sven Luther