Bonjour Nal,
Je t'écris pour te donner des nouvelles de nanim. Au départ simple format d'animation 2D basé sur protobuf optimisé pour les jeux vidéos, le projet a évolué pour proposer un outil d'édition d'animation générique.
Cette version propose les nouveautés suivantes:
Compression
Je suis passé de fossil à git et ce dernier n'apprécie pas les gros fichiers. Nanim étant un format non compressé, on arrive facilement à des fichiers de plusieurs dizaines de mo…
Les fichiers d'animation peuvent être compressés au format gzip (extension .nanim.gz ou .nanimz).
J'envisage de gérer d'autres types de compression (bzip?) si je trouve des bibliothèques simples.
Packaging
Je fournis un paquet pour debian et un installeur pour Windows. J'essayerais de faire des rpms ou d'autres paquets si j'ai des demandes.
J'aimerais bien faire des paquets pour Mac OS X, mais je ne sais pas si c'est possible sans acheter une machine à Apple.
JSON
J'envisage de faire une version web de Newton Adventure. Malheureusement, il est assez difficile de gérer des fichiers binaires avec cette daube technologie du futur qu'est HTML5.
J'ai fait un essai, mais ça donne un code est moche et des performances pas terribles… De plus la quasi totalité des cadriciels de jeu ne prévoient pas qu'une nimage puisse être autre chose qu'une image au format png/jpg/gif.
Comme j'ai peu de chances de faire accepter nanim par le W3C le whatg la fondation Mozilla, j'ai développé une version web de nanim en json:
{
"animations": [
{
"name": "walk_up",
"frames": [
{
"duration": 100,
"image": "ned_image_0.png",
"u1": 0.0,
"v1": 0.0,
"u2": 1.0,
"v2": 1.0
},
{
"duration": 100,
"image": "ned_image_1.png",
"u1": 0.0,
"v1": 0.0,
"u2": 1.0,
"v2": 1.0
},
{
"duration": 100,
"image": "ned_image_2.png",
"u1": 0.0,
"v1": 0.0,
"u2": 1.0,
"v2": 1.0
},
{
"duration": 100,
"image": "ned_image_3.png",
"u1": 0.0,
"v1": 0.0,
"u2": 1.0,
"v2": 1.0
}
]
},
Code clean
J'ai également fait beaucoup de ménage: les outils peu utiles ont été abandonnés, la génération des paquets est plus simple et réduits la taille des livrables, le code a été nettoyé…
Aujourd'hui linuxfr et demain le Monde!
nanim commence à être utilisé pour d'autres projets que Newton Adventure. Il y a bien sûr Ned et les maki, mais aussi Akagoria et un étonnant moteur de jeu qui reproduit le fonctionnement d'une Super Nintendo.
The end?
A plus dans le bus, Nal!
# Git
Posté par reynum (site web personnel) . Évalué à 2.
Utilise le fichier .gitignore, à priori versionner des animations n'a pas grand intérêt (mais je peux me tromper)
kentoc'h mervel eget bezan saotred
[^] # Re: Git
Posté par liberforce (site web personnel) . Évalué à 4.
Je crois que tu te trompes…
[^] # Re: Git
Posté par ʭ ☯ . Évalué à 3.
Ben non : il vaut mieux versionner les sources des animations que les fichiers nanim…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Git
Posté par liberforce (site web personnel) . Évalué à 2.
Je ne vois pas en quoi tu n'es pas d'accord avec moi: ce que tu dis revient à versionner des animations, et ça c'est utile. Je n'ai pas parlé de versionner des sources ou des fichiers générés.
[^] # Re: Git
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Dans un jeu, les animations font parti du projet!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Git
Posté par liberforce (site web personnel) . Évalué à 2.
Dans ce cas, comme dit plus haut, versionne les infos permettant de générer les animations, pas les animations elle-mêmes. Tu les généreras à la volée au moment de la compilation. Dans tous les cas, tout ce qui peut être généré automatiquement ne devrait jamais être en gestion de configuration, à quelques exceptions près.
[^] # Re: Git
Posté par rewind (Mastodon) . Évalué à 2.
Dans le format, il n'y a que des informations pour générer des animations…
[^] # Re: Git
Posté par reynum (site web personnel) . Évalué à 1.
Et juste avec ces informations
ça me semble étrange m'enfin bon, je dis ça je ferme ma g…. et je ~~~>[]
kentoc'h mervel eget bezan saotred
[^] # Re: Git
Posté par rewind (Mastodon) . Évalué à 3.
Le problème, qui est d'ailleurs évoqué dans cette dépêche, c'est que les images sont stockés en format raw (RGBA) pas compressé et qu'avec beaucoup d'images, ça peut faire beaucoup de place sur le disque. Avec une compression zlib, on va arriver grosso-modo à la même chose que des png.
[^] # Re: Git
Posté par reynum (site web personnel) . Évalué à 3.
Ok c'est bien ce qui me semblais !
Alors je reviens à mon raisonnement initial, quel intérêt a versionner des images et pas juste les infos pour animer celles-ci ?
kentoc'h mervel eget bezan saotred
[^] # Re: Git
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Ces infos sont dans les fichiers nanim :-)
nanim est un format à comparer avec gif ou apng.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Git
Posté par reynum (site web personnel) . Évalué à 1.
du coup ce ne serait pas plus souple de faire un fichier d'info à part des images ?
kentoc'h mervel eget bezan saotred
[^] # Re: Git
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Ca dépends de la souplesse souhaitée :-)
Le format json+pngs est là pour ça.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Git
Posté par Clément David (site web personnel) . Évalué à 4.
Si le problème de performance vient du diff binaire de gros fichiers, gitattributes te permet d'éviter cela.
.gitattributes
*.nanim binaryChaque fichier nanim sera alors vu comme un fichier binaire (git n'essaiera pas de faire un diff ni un show).
[^] # Re: Git
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
J'ai eu deux problèmes avec les gros fichiers et git:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Git
Posté par Julien Jorge (site web personnel) . Évalué à 3.
git compresse aussi le dépôt, mais seulement de temps en temps. Peut-être que ça ne t'es pas encore arrivé ?
Pour le push http, j'ai eu le même problème avec GitHub, mais je n'ai pas trouvé de solution hormis le push en ssh.
[^] # Re: Git
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Pourquoi avoir lâché fossil, toi qui n'arrêtais pas d'en faire la louange ?
Sinon pourquoi ne pas séparer les données du code ? Ça évide d'avoir un dépôt trop lourd tout en les versionnant. C'est ce qu'on fait pour SàT: d'un côté les médias, et de l'autre le code (mais on a évidemment beaucoup moins de fichiers binaires que pour un jeu). Mercurial s'en sort pas trop mal, m'étonne que ça ne soit pas le cas pour git.
[^] # Re: Git
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
J'adore toujours fossil, mais j'ai commencé à travailler avec d'autres personnes et vu que tout le monde fait du git… Monde de merde!
La gestion de version est aussi intéressante pour les données et c'est plus simple d'avoir tout au même endroit.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Git
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Oui j'entends bien, je parlais de séparer dans un autre dépôt. Ça rend le dépôt de code moins lourd (télécharger les binaires à chaque clone, c'est un peu relou et pas cool pour le serveur), et les médias bougent moins souvent a priori (même pour un jeu). Pour SàT le backend est dans sat, les médias sans sat_media: http://repos.goffi.org/
La gestion de version est bien utile pour les binaires aussi, je suis d'accord.
[^] # Re: Git
Posté par devnewton 🍺 (site web personnel) . Évalué à 2. Dernière modification le 20 décembre 2013 à 17:03.
Pour ça je clone depuis github et je push/pull avec le dépôt du jeu. Un peu de cloud dans l'autohébergement, ça ne fait pas de mal :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Git
Posté par Renaud Casenave-Péré . Évalué à 1.
Tu pourrais peut-être essayer git-annex qui est prévu pour les fichiers binaires. L'utilisation est un peu différente de git et le support de windows est pas au top mais c'est très prometteur.
# xz
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
xz ?
Je fais pas de java, mais une brève recherche m'indique apache common compress (licence apache) et xz for java (domaine public).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: xz
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Accordé! http://git.bci.im/nanim/commit/76383f519a44c9144ffb21a632e12d59348286d4
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: xz
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
ah super !
au passage, commentaire hors-sujet, c'est joli gitlist ! :)
ce commentaire est sous licence cc by 4 et précédentes
# APNG
Posté par matteli . Évalué à 2. Dernière modification le 20 décembre 2013 à 15:07.
Les spec de ton format nanim ne sont elles pas couvertes par l'APNG qui lui est lisible sous Firefox ?
[^] # Re: APNG
Posté par devnewton 🍺 (site web personnel) . Évalué à 4. Dernière modification le 20 décembre 2013 à 15:22.
nanim a quelques particularités:
L'idée c'est de pouvoir charger toutes les animations d'un niveau très vite dans le GPU en minimisant le nombre de texture.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: APNG
Posté par Julien Jorge (site web personnel) . Évalué à 2.
Pourquoi imposer des textures aux dimensions égales à des puissances de 2 ? Je sais bien que de nombreuses cartes requièrent des textures en puissance de 2, mais rien n'empêche créer une texture de cette taille et transférer l'image quelconque sur une partie de la texture avec glTexSubImage2D. Est-ce que ça apporte un avantage ?
[^] # Re: APNG
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
C'est nanimopt qui par défaut génèrent des images de 128x128 à 1024x1024, mais ces tailles sont configurables.
Il faut que j'étudie la question!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.