Journal nanim 1.6

Posté par (page perso) . Licence CC by-sa
Tags :
20
20
déc.
2013

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.

nanimstudio

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!

Site officiel
nimage de fin officielle

  • # Git

    Posté par . Évalué à 2.

    Je suis passé de fossil à git et ce dernier n'apprécie pas les gros fichiers

    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 (page perso) . Évalué à 4.

      Je crois que tu te trompes…

      • [^] # Re: Git

        Posté par (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 3.

      Dans un jeu, les animations font parti du projet!

      http://devnewton.bci.im

      • [^] # Re: Git

        Posté par (page perso) . É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 . Évalué à 2.

          Dans le format, il n'y a que des informations pour générer des animations…

          • [^] # Re: Git

            Posté par . Évalué à 1.

            Dans le format, il n'y a que des informations pour générer des animations…

            Et juste avec ces informations

            on arrive facilement à des fichiers de plusieurs dizaines de mo…

            ç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 . É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 . É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 (page perso) . Évalué à 4.

          Dans ce cas, comme dit plus haut, versionne les infos permettant de générer les animations, pas les animations elle-mêmes

          Ces infos sont dans les fichiers nanim :-)

          nanim est un format à comparer avec gif ou apng.

          http://devnewton.bci.im

          • [^] # Re: Git

            Posté par . É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 (page perso) . Évalué à 4.

              Ca dépends de la souplesse souhaitée :-)

              Le format json+pngs est là pour ça.

              http://devnewton.bci.im

    • [^] # Re: Git

      Posté par (page perso) . Évalué à 4.

      Si le problème de performance vient du diff binaire de gros fichiers, gitattributes te permet d'éviter cela.

      .gitattributes
      *.nanim binary

      Chaque fichier nanim sera alors vu comme un fichier binaire (git n'essaiera pas de faire un diff ni un show).

    • [^] # Re: Git

      Posté par (page perso) . É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 (page perso) . Évalué à 4.

        Pourquoi avoir lâché fossil, toi qui n'arrêtais pas d'en faire la louange ?

        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!

        Sinon pourquoi ne pas séparer les données du code ?

        La gestion de version est aussi intéressante pour les données et c'est plus simple d'avoir tout au même endroit.

        http://devnewton.bci.im

        • [^] # Re: Git

          Posté par (page perso) . Évalué à 2.

          La gestion de version est aussi intéressante pour les données et c'est plus simple d'avoir tout au même endroit.

          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 (page perso) . Évalué à 2. Dernière modification le 20/12/13 à 17:03.

            télécharger les binaires à chaque clone, c'est un peu relou et pas cool pour le serveur

            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 :-)

            http://devnewton.bci.im

            • [^] # Re: Git

              Posté par . É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 (page perso) . Évalué à 7.

    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.

    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

  • # APNG

    Posté par . Évalué à 2. Dernière modification le 20/12/13 à 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 (page perso) . Évalué à 4. Dernière modification le 20/12/13 à 15:22.

      nanim a quelques particularités:

      • un fichier contient plusieurs animations.
      • les frames sont découplées des images (une frame est une vue vers une sous partie d'une image).
      • le format des images permets de les charger directement via OpenGL.

      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.

      nanim

      http://devnewton.bci.im

      • [^] # Re: APNG

        Posté par (page perso) . É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 (page perso) . Évalué à 4.

          Pourquoi imposer des textures aux dimensions égales à des puissances de 2 ?

          C'est nanimopt qui par défaut génèrent des images de 128x128 à 1024x1024, mais ces tailles sont configurables.

          transférer l'image quelconque sur une partie de la texture avec glTexSubImage2D

          Il faut que j'étudie la question!

          http://devnewton.bci.im

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.