Journal Naissance du projet nanim

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
30
17
avr.
2012

Origine

Dans le cadre du développement de Newton Adventure, j'utilisais jusqu'ici le format gif pour les sprites animés. Malheureusement ce format est limité à 256 couleurs par image. J'ai cherché une alternative:

  • mng: ce format, qui aurait du être le successeur du gif est assez compliqué et peu utilisé.
  • apng: un peu plus simple et un peu plus répandu, il se veut une alternative au précédent.
  • fli, flc et autres: il existe beaucoup de vieux formats d'animation, mais ils sont souvent peu connus, pas très simples, pas toujours bien spécifiés.
  • Utiliser un format spécifique: la plupart des jeux regroupe leurs animations dans une grande image et stockent les informations relatives à l'animation dans un fichier à part, souvent en XML.

Aucune de ces solutions ne m'a enthousiasmé, j'ai donc décidé de créer mon propre format tout en créant un projet à part pour ne pas en faire un nieme format utilisable par un seul jeu.

Le projet

J'ai donc créé nanim, un format:

  • simple: non compressé, il stocke juste une liste d'animations, de frames et de nimages RGBA ou RGB.
  • facile à lire et à écrire: nanim est spécifié via protobuf, il est donc très facile de générer des décodeurs et des encodeurs dans un grand nombre de langages.
  • fait pour les jeux: au lieu de stocker une nimage par frame, chaque frame possède juste des coordonnées dans une des images. Cela permettra à l'avenir de générer un fichier nanim optimisé pour les cartes graphiques.

Outre les spécifications en protobuf, j'ai écris trois utilitaires, nanimenc, nanimdec et nanimviewer, afin de créer des fichiers nanim à partir de png, d'en extraire les images et de les visualiser.

Le futur

Avant de sortir cette première version, j'aurais voulu ajouter un utilitaire nommé nanimopt destiné à produire un nanim optimisé depuis un nanim source selon les critères suivants:

  • regrouper les nimages sources dans un ensemble de nimages dont les dimensions sont des puissances de 2.
  • minimiser la taille mémoire totale de ces nouvelles nimages optimisées.
  • si possible mettre les nimages sources d'une même animation dans une même nimage optimisé.

Malheureusement, je me suis rendu compte qu'il s'agissait d'un problème NP complet bien connu sous les noms charmants de rectangle bin packing ou texture atlas generation. Devant la difficulté de la tâche, j'ai décidé de repousser son implémentation à plus tard.

Téléchargement

Les sources sous license BSD de mon travail se trouve sur mon site:

http://bci.im/devnewton/fossils/nanim

La spécification

package im.bci.nanim;

option java_outer_classname = "NanimParser";

message Frame {
    required string imageName = 1;
    required int32 duration = 2;
    required float u1 = 3;
    required float v1 = 4;
    required float u2 = 5;
    required float v2 = 6;
    extensions 1000 to max;
}

message Animation {
    required string name = 1;
    repeated Frame frames = 2;
    extensions 1000 to max;
}

enum PixelFormat {
    RGB_888 = 1;
    RGBA_8888 = 2;
}

message Image {
    required string name = 1;
    required int32 width = 2;
    required int32 height = 3;
    required PixelFormat format = 4;
    required bytes pixels = 5;
    extensions 1000 to max;
}

message Nanim {
    repeated Image images = 1;
    repeated Animation animations = 2;
    optional string author = 3;
    optional string license = 4;
    extensions 1000 to max;
};

The end

Pour finir une nanimation (en gif malheureusement, en attendant de soumettre nanim au W3C): nanimation

  • # Nan mais franchement..

    Posté par  . Évalué à -8.

    Pour finir une nanimation (en gif malheureusement, en attendant de soumettre nanim au W3C): nanimation

    Dommage, sans ces conneries machistes ton journal aurait été parfait. Là, c'est juste CHIANT de lire toujours les mêmes CONNERIES de MACHOS qui se touchent la nouille entre linuxiens à faire des blagues MACHISTES.

    Et après on va pleurer "oh ben y'a pas de femmes dans le logiciel libre, ah que comment que ça se fait que vous croyez que faut remplacer la bière par du thé?"

    On n'est pas sur DabranletteFrenchPage, tes désirs hétérosexuels masculins tu les gardes pour les soirées entre potes, c'est indécent de nous mettre une potiche (quand bien même elle consentit à poticher) en tant que "nanimation" afin d'agrémenter un journal.

    • [^] # Re: Nan mais franchement..

      Posté par  (site web personnel) . Évalué à 9.

      Tu préfères ça ? http://morignot.iiens.net/vrac/jb.gif

      Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

      • [^] # Re: Nan mais franchement..

        Posté par  . Évalué à 10.

        heureusement ils n'ont pas pensé à rajouter le support audio dans les gif…

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: Nan mais franchement..

      Posté par  . Évalué à 8.

      Quand on veut faire du second degré, faut quand même être un peu plus explicite que ça ; là, tu vas juste te manger un -10 ;)

      • [^] # Re: Nan mais franchement..

        Posté par  (site web personnel) . Évalué à 2.

        C'est clair : en lisant le message je me suis dit : mais quel est ce con.
        Puis j'ai vu que c'était Mr nimage linuxfr, et donc compris le 2nd degré.

        S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

      • [^] # Re: Nan mais franchement..

        Posté par  . Évalué à 10.

        Surtout pas! Faire une bonne grosse parodie bien grasse et constater que toutes les moules tombent dans le panneau sont un petit plaisir particulièrement savoureux.

    • [^] # Re: Nan mais franchement..

      Posté par  (site web personnel) . Évalué à 10.

      Je ne suis pas machiste, la preuve ma femme est une femme.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Nan mais franchement..

      Posté par  . Évalué à -10. Dernière modification le 17 avril 2012 à 22:46.

      GG pour cet exemple de féminisme enragé. Tu sers ta cause…

    • [^] # Re: Nan mais franchement..

      Posté par  . Évalué à 5.

      On n'est pas sur DabranletteFrenchPage, tes désirs hétérosexuels masculins tu les gardes pour les soirées entre potes

      Euh … le terme "branlette" désigne aussi bien masturbation masculine que féminine. Et tout le monde sait que toutes les femmes sont prudes, frigides, avec une avertion profonde pour tout allusion qui touche de près ou de loin le sexe. Et puis c'est quoi cette histoire de thé? Depuis quand les geekettes ne prennent plus de bière?

      PS: Te rens tu compte que, bien que prétendant le dénoncer, ton commentaire est on ne peut plus sexiste?

      • [^] # Re: Nan mais franchement..

        Posté par  . Évalué à 10.

        Depuis quand les geekettes ne prennent plus de bière?

        Depuis quand les geek n'ont plus le droit de boire du thé ?

    • [^] # Re: Nan mais franchement..

      Posté par  . Évalué à 10.

      Il y a vraiment des gens émoustillés par une fille (floue) qui fait un clin d'œuil en ouvrant la bouche tel une bécassine ?

      Il en faut peu.

    • [^] # Re: Nan mais franchement..

      Posté par  (site web personnel) . Évalué à 2.

      Et après on va pleurer

      qui pleure ?

    • [^] # Re: Nan mais franchement..

      Posté par  . Évalué à 6.

      I see what you did there.

      https://linuxfr.org/users/euroxers/journaux/wikip%C3%A9dia-italiano-is-dying#comment-1276153

      La longue discussion là-bas est, bizarrement, plus intelligente qu'ici. À croire que y'a une régression des mentalités sur LinuxFR :/

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # Obligatory

    Posté par  . Évalué à 10.

    https://xkcd.com/927/

    Sinon, dans ta lste des formats inutilisés t'as oublié Motion JPEG 2000

    • [^] # Re: Obligatory

      Posté par  (site web personnel) . Évalué à 3.

      Je ne conçois pas nanim comme "competing" avec des formats comme mng, apng ou motion jpeg 2000 et autres. C'est un format pour les jeux vidéos, pas pour le stockage ou d'autres usages.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Obligatory

        Posté par  . Évalué à 5.

        Tu as aussi les formats netpbm (Portable pixmap). Super simples : tu peux écrire un parser en quelques dizaines de lignes si tu n'as besoin que d'un seul format en lecture seule. Le toolkit pour convertir ces images depuis et vers tous les formats usuels est disponible dans toutes les distros *nix.

        Les pages de man sont pas super claires, mais la variante raw permet de stocker plusieurs trames. Le format est permissif, donc si c'est pour un usage uniquement dans ton projet, tu peux définir la variante qui te permet d'accéder le plus facilement à tes données.

      • [^] # Re: Obligatory

        Posté par  (site web personnel) . Évalué à 9.

        Je ne conçois pas nanim comme "competing" avec des formats comme mng, apng ou motion jpeg 2000 et autres.

        Mouais… C'est le même discours fait par tout le monde "pas en compétition, mais me manque un petit truc", du coup on a HDMI vs DisplayPort, FireWire vs USB vs eSATA vs Thunderbolt vs etc, pour parler matériel, mais en format d'images c'est pareil.
        Mais au final, les formats font tous 99% des choses pareil, 1% différemment mais les logiciels doivent supporter tous les formats.

        Bof comme argument "Aucune de ces solutions ne m'a enthousiasmé".

        Si, c'est un format en compétition avec toute une série de formats, image et video en fait, car ils font tous la même chose (=une série d'images). C'est surtout un truc "j'ai envie de faire ma version".

        Ceci dit, ça m'arrange : plus il y a de formats "vidéo" répandus, plus je gagne de fric (ben oui, on me paye par format supporté), bien que je parie que ça n'ira pas bien loin (les jeux vidéos utilisant de plus en plus des formats "génériques" genre conteneur MP4 avec lequel on peut faire beaucoup de choses)

        • [^] # Re: Obligatory

          Posté par  (site web personnel) . Évalué à 3.

          Le "petit truc qui manque", c'est la possibilité de faire du texture packing.

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: Obligatory

            Posté par  (site web personnel) . Évalué à 8.

            Ton petit truc qui manque, ça peut être un petit metadata en plus dans un format déjà existant (beaucoup de formats image ou vidéo sont extensibles y compris avec des données "privées" = non standard tant que le comité adéquat n'a pas validé…)
            En fait, comme beaucoup de monde fait déjà.

            Petit truc qui manque == petite évolution d'un standard existant.
            Petit truc qui manque != tout refaire de zéro "pour le plaisir", ne pas discuter avec les mainteneur des specs déjà existantes (ça, c'est pour quand on est "disruptif" et qu'on une idée complètement géniale complètement incompatible avec l'existant)

            Après, tu fais ce que tu veux, juste que comme le dit xkcd, c'est juste un n-ième format en plus qui ne résoudra aucun problème (surtout pas le problème "peu utilisé") et dont les gens râleront parce que pas foule en éditeurs le supportera.

            Tu n'es pas le premier, tu ne seras pas le dernier (perso, je rencontre tous les mois de nouveaux formats "parce que ce qui existe ne convient pas", et bizarrement souvent il n'y a aucune originalité)

            • [^] # Re: Obligatory

              Posté par  (site web personnel) . Évalué à 3.

              ça peut être un petit metadata en plus dans un format déjà existant

              C'est tellement facile à faire que la quasi totalité des jeux utilisent une autre solution: des images fixes avec les métadonnées d'animation dans un format spécifique à part.

              C'est ces solutions propriétaires que nanim veut remplacer, pas le stockage d'animation pour le web (où le gif reste indétrônable à cause de la guéguerre apng/mng).

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

              • [^] # Re: Obligatory

                Posté par  (site web personnel) . Évalué à 5.

                C'est tellement facile à faire que la quasi totalité des jeux utilisent une autre solution:

                Ha, et pourquoi utilisent-ils cette autre solution plutôt qu'une solution du type de celle tu as envisagé ?
                (vrai question)

                • [^] # Re: Obligatory

                  Posté par  (site web personnel) . Évalué à 7.

                  Je ne sais pas, peut être parce que ça prends moins de temps de faire un petit bout de code à l'arrache que d'essayer de proposer un format réutilisable, de livrer ses outils au public et de communiquer dessus?

                  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Obligatory

          Posté par  . Évalué à 2.

          Si, c'est un format en compétition avec toute une série de formats, image et video en fait, car ils font tous la même chose (=une série d'images). C'est surtout un truc "j'ai envie de faire ma version".

          C'est surtout pas le même travail du tout. Aller voir des gros commité et leur dire que toi tu veux tel ou tel chose ça prend un temps infini et c'est bien plus complexe.

          Une voie sympa c'est de prendre un format existant de le modifier pour coller à tes besoins et d'aller voir les concepteurs pour leur dire « regardez ce que j'ai fais, c'est vachement cool pour faire ça, vous en pensez quoi ? » et de voir comment ça réagis. Ça permet de pouvoir sortir rapidement quelque chose et à terme de recoller à un format existant (l'avantage étant de pouvoir ensuite avoir une base d'outils compatibles bien plus importante). Mais ce n'est pas forcément simple.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Obligatory

        Posté par  . Évalué à 2.

        C'est un format pour les jeux vidéos, pas pour le stockage

        C'est un peu idiot. Tes images pour jeux vidéos, elles sont bien stockées quelque part, non ?

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Obligatory

          Posté par  . Évalué à 4.

          Non, ce n’est pas idiot. Pour le stockage, tu veux qu’une nanim puisse pouvoir être lue dans 10 ans. Pour le jeu vidéo, logiciel et données forment un tout, tu t’en fiches que le décodeur fournit avec monjeu 1.0.3 soit incompatibles avec les données de la 1.0.2. Dans un cas tu dois te casser la tête « je dois prévoir un mécanisme d’extensions au cas où… je dois prévoir plusieurs modèles colorimétriques au cas où… », pas dans l’autre.

    • [^] # Re: Obligatory

      Posté par  . Évalué à 6.

      Il semble pourtant que ISO 26428-1:2008, qui décrit la diffusion du cinéma numérique, cause « un poil » de Motion JPEG 2000 .^

    • [^] # Re: Obligatory

      Posté par  (site web personnel) . Évalué à 2.

      Tiens, personne n'a cité Webp?

      • [^] # Re: Obligatory

        Posté par  . Évalué à 2.

        On cause d'images animées, donc autant parler de codec vidéos.

        Après tout, H.264 et Xvid proposent des optimisations d'encodage pour de l'animation type dessins animés.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Obligatory

          Posté par  . Évalué à -3.

          Il faut voir comment ils sont fait certains formats vidéos ne peuvent pas être décodés sans avoir décodé au moins une partie de ce qui se passait avant. Ici il faut utiliser un format que tu puisse décoder unitairement frame par frame.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Obligatory

            Posté par  (site web personnel) . Évalué à 5.

            Qui peut le plus peut le moins. Même dans H264/AVC, il n'y a aucune obligation d'avoir des images "P" (lien unidirectionnel) ou "B" (lien bidirectionnel).

            Il y a plein de caméras professionnelles qui ont pour "codec" un truc qu'on appelle AVC-Intra (Intra = sans aucune référence, toutes indépendantes) car ils veulent découper la vidéo à l'image près.

            Si, si, ça existe déjà… C'est rigolo qu'une "critique" sur un format soit la possibilité de faire plus que la base. Le fait de pouvoir faire plus ne signifie pas qu'il ne peut pas faire la base!

            Bref, rien de neuf.

            • [^] # Re: Obligatory

              Posté par  . Évalué à -1.

              Je n'ai jamais dis que ça n'existait pas, juste qu'il fallait prendre en compte cette fonctionnalité pour choisir un format vidéo pour cet usage.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Obligatory

                Posté par  (site web personnel) . Évalué à 4.

                Quitte à me répéter : c'est de base!
                AUCUN format video ne peut se passer d'avoir des images seules, vu que c'est la base.
                Donc pas la peine de "vérifier" : c'est toujours le cas (c'est toujours possible)

                • [^] # Re: Obligatory

                  Posté par  . Évalué à 2.

                  Quitte à me répéter : c'est de base!

                  Ok excuse moi je n'avais pas compris cette phrase ainsi :

                  C'est rigolo qu'une "critique" sur un format soit la possibilité de faire plus que la base.

                  Donc il suffit de générer ces fichiers avec par exemple mencoder (j'avais vu qu'il avait de quoi faire simplement une vidéo à partir d'un ensemble de fichiers d'images) en n'appliquant pas les optimisations pour le décodage « directionnel » et c'est bon ?

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Obligatory

                    Posté par  (site web personnel) . Évalué à 2.

                    Pour les paramétrage des encodeur, je ne peux aider, je suis spécialisé dans l'analyse de leur résultat uniquement. Il faut "juste" dire à l'encodeur un truc du style que le GOP max est de 1, ou qu'il n'a pas le droit de faire ni P ni B frames (dire "pas de B frames" n'est pas suffisant), ou qu'il a droit de faire que des I frames.
                    avec mediainfo, le résultat doit être une ligne "Format settings, GOP: N=1".

                    Plus d'infos :
                    http://en.wikipedia.org/wiki/Group_of_pictures
                    http://en.wikipedia.org/wiki/Video_compression_picture_types

                    Bref, encore une fois, les images indépendantes sont la base (il en faut mini une dans n'importe quel fichier, donc le format doit supporter la chose), auxquelles se rajoutent les images directionnelles (dépendantes).

                    Par contre, le défaut est simple : la taille des flux (ça monte facile à 100 Mbps pour une qualité HD à la place de 20 Mbps avec les P/B frames). Pour des "petits sprites", utiliser des images indépendantes va encore, mais faut pas trop pousser en qualité au prix d'une taille immense. A ma connaissance, dans les jeux vidéos c'est à base d'images compressées compatibles DirectX (à la base de chez S3) http://en.wikipedia.org/wiki/S3TC que le jeux envoie direct à la carte graphique, compressé. Des sprites non compressés, ça me juste rire sur les années de retard.

                    • [^] # Re: Obligatory

                      Posté par  (site web personnel) . Évalué à 1.

                      A ma connaissance, dans les jeux vidéos c'est à base d'images compressées compatibles DirectX (à la base de chez S3) http://en.wikipedia.org/wiki/S3TC que le jeux envoie direct à la carte graphique, compressé. Des sprites non compressés, ça me juste rire sur les années de retard.

                      DirectX, je m'en fout, je fais du jeu libre portable.

                      Et pour info, S3TC n'est qu'un format parmi d'autres, pas géré par tous les GPU/drivers, donc c'est une mauvaise idée de l'utiliser comme format par défaut.

                      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                      • [^] # Re: Obligatory

                        Posté par  . Évalué à 2.

                        De plus, S3TC est couvert par des brevets (d'où les problèmes pour son inclusion dans Mesa).

                  • [^] # Re: Obligatory

                    Posté par  . Évalué à 2.

                    Généralement, il existe déjà ce qu'on appelle des profils standardisé et prédéfinis.
                    Souvent appelés "intra-xxx"… s'il n'y en a pas, tu forces la génération d'IFrames (Intra-Frame) toutes les images.

    • [^] # Re: Obligatory

      Posté par  . Évalué à 6.

      Ce n'est pas parce que tu l'utilises pas que cela n'est pas utilisé.
      Le JPEG2000 est -juste- la référence pour la projection cinéma numérique.
      References: http://dcimovies.com/DCIDigitalCinemaSystemSpecv1_2.pdf

      • [^] # Re: Obligatory

        Posté par  (site web personnel) . Évalué à 2.

        Le JPEG2000 est -juste- la référence pour la projection cinéma numérique.

        https://fr.wiktionary.org/wiki/juste

        • [^] # Re: Obligatory

          Posté par  . Évalué à 2.

          C'est Juste ton prénom ?

      • [^] # Re: Obligatory

        Posté par  . Évalué à 2. Dernière modification le 18 avril 2012 à 12:04.

        Ce n'est pas parce que tu l'utilises pas que cela n'est pas utilisé.

        Justement je l'utilise, et je me sens seul.

        Je ne parlais pas de cinéma mais d'utilisation personnelle. Les distributions n'installent pas par défaut le support de jpeg2000, il faut chercher des plugins ou recompiler les logiciels. Les navigateurs ne le supportent pas non plus. Résultat, bien que ce soit pour moi un meilleur format pour archiver mes photos, je dois passer par des étapes de conversion pour pouvoir partager ces photos avec mes proches, résultant en une perte de qualité (parce que je limite la taille des fichiers que j'envoie par mail à mes proches).

        • [^] # Re: Obligatory

          Posté par  . Évalué à 1.

          parce que je limite la taille des fichiers que j'envoie par mail à mes proches

          Peut-être que le protocole de transfert n'est pas bien choisi, dans ce cas :|

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

          • [^] # Re: Obligatory

            Posté par  . Évalué à 2.

            Les protocoles acceptés par mes proches sont : e-mail, courrier papier et facebook (exclu d'office). « Demain, je passe à l'auto-hébergement », que je me dis tous les jours.

            • [^] # Re: Obligatory

              Posté par  . Évalué à 1.

              Je suppose que tes proches sont également d'accord avec l'usage des protocoles gérés par leur navigateur Web, t'as donc en plus : HTTP(S), et FTP.

              Sinon, y'en a pas un certain nombre qui utilisent un protocole de P2P ? Pour diffuser des gros documents à plusieurs personnes, je trouve très pratique de filer un .torrent. Les gens cliquent et ça réagit exactement comme s'ils avaient cliqué sur leursitedetorrentpréféré.tld, avec le téléchargement qui se lance dans le client Torrent.

              THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: Obligatory

          Posté par  . Évalué à 2.

          Justement je l'utilise, et je me sens seul.

          Bah on est deux alors :)
          En fait, ca commence à venir, pas mal de logiciel ont déjà implémentés le support JPEG2000 que ce soit sous Windows et MacOS.
          Je sais qu'en médecine c'est un peu utilisé mais c'est relativement rare (dû au temps de remise à niveau du matériel + maj formation personnels)

  • # .

    Posté par  (site web personnel) . Évalué à 8.

    Hum, à voir les critiques des formats existant, il ressort surtout l'argument peu répandu / utilisé.
    En quoi ton nième format d'animation pourrait en faire un format plus répandu utilisé ?

    Et sinon j'ai deux questions existentielles :

    • tu ne commente jamais tes codes ?
    • comment tu fais pour bosser avec une indentation de 8 caractères o_O

    • [^] # Re: .

      Posté par  . Évalué à -2.

      comment tu fais pour bosser avec une indentation de 8 caractères

      Car une tabulation est de 8 espaces, et que c'est donc la valeur la plus raisonnable. Voir le style de code de Linux.

      • [^] # Re: .

        Posté par  . Évalué à 10. Dernière modification le 17 avril 2012 à 23:18.

        une tabulation est de 8 espaces,

        Une tabulation est une tabulation (caractère \t), pas un ensemble d'espaces, et son affichage dépend des réglages de ton terminal. man tabs (paquet ncurses). C'est aussi l'intérêt d'indenter aux tabulations par rapport à indenter aux espaces, parce que chaque utilisateur peut choisir la largeur affichée de la tabulation. Après si Linus aime bien indeter à 8 espaces tant mieux pour lui, mais son excuse est vaseuse.

        • [^] # Re: .

          Posté par  . Évalué à 1.

          « C'est aussi l'intérêt d'indenter aux tabulations par rapport à indenter aux espaces, parce que chaque utilisateur peut choisir la largeur affichée de la tabulation »

          T'as visiblement jamais ouvert un fichier source avec la mauvaise tabulation…

          Sinon c'est la première fois que j'entends parler de tabs, et effectivement, après avoir réussi à le dégoter, ça marche plutôt bien. Mais bon ça n'empêche en rien que la longueur standard d'une tabulation est de 8 caractères.

      • [^] # Re: .

        Posté par  . Évalué à -1.

        Car une tabulation est de 8 espaces…

        Eh oui, on trouve aussi en magasin, des tabulation sud, des tabulation nord, et je vous laisse deviner la suite :)

    • [^] # Re: .

      Posté par  (site web personnel) . Évalué à 2.

      En quoi ton nième format d'animation pourrait en faire un format plus répandu utilisé ?

      Il est plus simple, plus facile à parser et permets une optimisation pour les jeux.

      J'ai beaucoup hésité avant de créer mon propre format et ce qui m'a décidé, c'est quand je me suis demandé: quitte à coder, pourquoi le faire pour l'un de ces formats compliqués, pas très adaptés et peu utilisés?.

      tu ne commente jamais tes codes ?

      Le vrai programmeur ne commente pas, le code est évident!

      Plus sérieusement, si quelqu'un a besoin d'aide sur mon code, je commenterais les parties non triviales.

      comment tu fais pour bosser avec une indentation de 8 caractères o_O

      Je n'indente rien moi même,je laisse cette tâche ingrate à mon IDE/éditeur. Un peu comme le parsing de fichier, je préfère laisser protobuf bosser pour moi!

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: .

        Posté par  . Évalué à 10.

        Le vrai programmeur ne commente pas, le code est évident!

        [Six mois plus tard…]

        -- Tu fais quoi ?
        -- Je reprends mon code de l'époque
        -- Ça avance ?
        -- La ferme.
        -- \o/

        [Un objet traverse la pièce]

      • [^] # Re: .

        Posté par  (site web personnel) . Évalué à 4.

        Le vrai programmeur ne commente pas, le code est évident!

        J'espère que c'est de l'humour. Mais en tout cas, un tel code, même évident, ne donne pas envie d'y contribuer malheureusement.

        Plus sérieusement

        ouf

        si quelqu'un a besoin d'aide sur mon code, je commenterais les parties non triviales

        hum…

        Plus sérieusement, avoir des commentaires bien fait ça permet aussi de générer une doc développeur (par exemple une javadoc) qui pourrait laisser un espoir à celui qui souhaite utiliser ton travail.

        Je n'indente rien moi même,je laisse cette tâche ingrate à mon IDE/éditeur

        Oui, moi aussi. Mais surtout je le configure pour que ça ressemble à quelque chose
        Ici c'est quand même pas génial…

        public class NanimDec 
{
    private CommandLine commandLine;
    private Nanim nanim;
    private int nbImageDecoded = 0;

    public NanimDec(CommandLine line) {
        this.commandLine = line;
    }

    public static void main( String[] args ) throws ParseException, IOException
    {
        Options options = new Options();
        options.addOption("i", true, "input nanim file");
        options.addOption("o", true, "output directory");

        if(args.length == 0) {
            HelpFormatter formatter = new HelpFormatter();
            formatter.printHelp( "nanimenc [args]", options );
            return;
        }

        GnuParser parser = new GnuParser();
        CommandLine line = parser.parse(options, args);

        NanimDec nanimDec = new NanimDec(line);
        nanimDec.decode();
        nanimDec.save();
    }
[...]
    public static boolean isFilenameValid(String pathname) {
          try {
            new File(pathname).getCanonicalPath();
            return true;
          } catch (IOException e) {
            return false;
          }
        }

        Raaaa ! oui le code est propre icitte mais c'est parce que les tabulations sont remplacées par 4 espaces… 'achement malin ! http://bci.im/devnewton/fossils/nanim/artifact/7bac83ad82b5bbee417fc3b7456f604e98e31cf7

        Histoire d'expliciter un peu plus :

        • devant { au début du static main, c'est des espaces et non des tabulation. Ton code dépendant donc de la valeur des tabulations (je suppose 4 pour toi)
        • au niveau de isFilenameValid tu as un sacré mélange d'erreur d'indentation, tabulations et espaces

        Tout ça, c'est pas pour casser du sucre sur le code (d'ailleurs j'ai pas vraiment regardé ce que ça fait) mais juste pour pointer des choses qui font qu'un code donne, de mon point de vue, envie d'être utilisé voir y contribuer, ou non.
        Et là, mauvaise indentation, aucun commentaire, ben ça donne pas trop envie.

        (perso, pour mon style en java j'ai fini par passer aux conventions de Google, je trouve que ça va plutôt bien : http://google-styleguide.googlecode.com/svn/trunk/)

        • [^] # Re: .

          Posté par  . Évalué à 2.

          devant { au début du static main, c'est des espaces et non des tabulation. Ton code dépendant donc de la valeur des tabulations (je suppose 4 pour toi)

          En principe un IDE ou un bon éditeur de texte te corrige ça. Min vim remplace les tabulations qu'il trouve, vire les trailling spaces, etc.

          au niveau de isFilenameValid tu as un sacré mélange d'erreur d'indentation, tabulations et espaces

          Les IDE classiques de Java (netbeans, eclipse et je n'en doute pas intelij) te permettent de balancer un checkstyle à la sauvegarde ce qui te corrige ce genre de choses.

          Même en utilisant autre chose les builders types maven/gradle (et probablement ant) te permettent aussi de le faire. Ça génère généralement un fichier html de rapport (c'est achement cool).

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: .

            Posté par  (site web personnel) . Évalué à 2.

            Vi vi, suis bien d'accord avec ça.
            Le auto format à la sauvegarde est quand même vraiment quelque chose de bien (surtout lorsqu'on travaille à plusieurs).

            Mais j'ai surtout tiqué sur la réponse

            Je n'indente rien moi même,je laisse cette tâche ingrate à mon IDE/éditeur

            Alors qu'on voit bien que c'est pas le cas / mal fait malheureusement

        • [^] # Re: .

          Posté par  (site web personnel) . Évalué à 1.

          Plus sérieusement, avoir des commentaires bien fait ça permet aussi de générer une doc développeur (par exemple une javadoc) qui pourrait laisser un espoir à celui qui souhaite utiliser ton travail.

          Je ne vois pas trop l'intérêt d'une doc développeur pour un programme, mais je note qu'il faudrait commenter un peu, même pour un code aussi trivial :-)

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: .

            Posté par  (site web personnel) . Évalué à 2.

            Ben c'est pas ça, mais imagine que quelqu'un veuille intégrer ton nanimenc ou dec non pas sous forme d'un programme mais d'une classe à l'intérieur de son programme (il peut y avoir plein de raisons pour ça). Dans ce cas il faut bien savoir quoi utiliser, non ?

  • # Container?

    Posté par  . Évalué à 4.

    Avec tous ces problèmes de compatibilité de format d'images animées, pourquoi ne pas plutôt faire un format "container" générique, dédié aux images animées, qui permette de stocker n'importe quel type d'images.

    De la même manière qu'un fichier mkv (Matroska) peut contenir du h264 ou du xvid, on pourrait avoir un format pouvant contenir du jpg ou du png.

    Pourquoi faire compliqué et réinventer un n-ième format, alors qu'un container serait simple et permettrait simplement d'ouvrir les images individuelles en utilisant un décodeur qui existe déjà (jpg, png, …).

    De plus, un container permettrait aux projets d'être plus serein quand à son utilisation, puisqu'il serait possible de changer de format pour un format plus compressé dans le futur si besoin (par exemple du jpeg 2000 ou similaire).

    Il y a quelques points à choisir ; est-ce qu'on autorise d'avoir plusieurs types d'images différents, est-ce qu'on peut stocker des metadata, quelles sont les propriétés de chaque frame (durée, position, …) ?

    Une analyse d'autres formats pourrait être un point de départ : différents formats d'images animées, mais aussi des containers vidéo et des formats de metadata (EXIF, IPTC, ID3, …).

    Une collaboration avec les différents acteurs, et principalement les différents navigateurs libres, permettrait peut-être de populariser le format et qu'il ne tombe pas dans l'oublie.

    • [^] # Re: Container?

      Posté par  (site web personnel) . Évalué à 2.

      nanim est déjà un conteneur générique!

      Grâce au mécanisme d'extension de protobuf, tu peux facilement ajouter ton propre format de pixels, tes métadonnées, tes effets spéciaux…

      extend Image {
  optional boolean useMyCustomFormat = 4242;
}

extend Nanim {
    message ID3 {
      ...
    }
    optional ID3 metadata = 3615;    
}

extend Frame {
   optional float mySpecialRotationEffectAngle = 6969;
}

      Une collaboration avec les différents acteurs, et principalement les différents navigateurs libres, permettrait peut-être de populariser le format et qu'il ne tombe pas dans l'oublie.

      Je vise plutôt le marché du jeu vidéo, mais avant d'aller faire la promotion de mon format hors de linuxfr, il faut que j'écrive nanimopt.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # NP Complet

    Posté par  . Évalué à 2.

    Malheureusement, je me suis rendu compte qu'il s'agissait d'un problème NP complet bien connu sous les noms charmants de rectangle bin packing ou texture atlas generation.

    Bien que le problème de trouver le meilleur "pavage" est NP-Complet, en trouver un à peu près correct est beaucoup moins complexe [:itm]

  • # Incohérent

    Posté par  (site web personnel) . Évalué à 8.

    Dans le cadre du développement de Newton Adventure, j'utilisais jusqu'ici le format gif pour les sprites animés. Malheureusement ce format est limité à 256 couleurs par image. J'ai cherché une alternative:

    Une alternative à un format d'animation compressé donc.

    • mng: ce format, qui aurait du être le successeur du gif est assez compliqué et peu utilisé.

    Compliqué : en quoi le format lui-même te concernerait-il ? Ce que tu utiliserais, c'est libmng, pas MNG lui-même : c'est la libmng qui a une API trop compliqué ?

    Peu utilisé : très mauvais argument, en créant un nouveau format tu peux être sûr d'une chose, c'est qu'il sera encore moins utilisé, à savoir, seulement par toi.

    J'ai donc créé nanim, un format:

    • simple: non compressé, il stocke juste une liste d'animations, de frames et de nimages RGBA ou RGB.

    Non compressé, d'accord d'accord… Mon pronostic à deux centimes : aucune chance de réussir à percer. Même GIF était compressé, et curieusement, les formats actuellement utilisés, même dans les jeux vidéos (son, images…), sont compressés.

    Pour finir une nanimation (en gif malheureusement, en attendant de soumettre nanim au W3C): nanimation

    Alors là, la probabilité que le W3C recommande pour le Web un format d'animation non compressé et optimisé pour le jeu vidéo est vraiment nulle, pour le coup.

    • [^] # Re: Incohérent

      Posté par  . Évalué à 3.

      Compliqué : en quoi le format lui-même te concernerait-il ? Ce que tu utiliserais, c'est libmng, pas MNG lui-même : c'est la libmng qui a une API trop compliqué ?

      Si je comprends bien son journal, je crois surtout que le format est inadapté à son usage : il n'a pas les bonnes métadonnées, et l'ensemble des sprites ne peut pas être chargé facilement sous la forme d'une image de taille de 2n

    • [^] # Re: Incohérent

      Posté par  (site web personnel) . Évalué à 4.

      Les formats existants sont à la fois complexe (ce qui se ressent dans les libs effectivement) et peu adaptés aux jeux vidéos (pas de texture packing).

      Dans ce domaine, le "format standard", c'est une texture et des métadonnées dans un format spécifique au jeu.

      La compression dans le format lui même est inutile, car dans la plupart des jeux, les données sont déjà dans une archive compressée.

      Si tu veux un nanim compressé individuellement, il suffit de faire:

      gzip zoey.nanim

      Alors là, la probabilité que le W3C recommande pour le Web un format d'animation non compressé et optimisé pour le jeu vidéo est vraiment nulle, pour le coup.

      man humour

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Incohérent

        Posté par  . Évalué à 2.

        man humour

        Ça se perd sur linuxfr de nos jours. Moules

      • [^] # Re: Incohérent

        Posté par  (site web personnel) . Évalué à 2.

        Dans ce domaine, le "format standard", c'est une texture et des métadonnées dans un format spécifique au jeu.

        Pourquoi ne pas faire ça justement? Genre un fichier image d'un format qui va bien (et directement géré par la CG si possible) et un fichier de métadonnées dans une archive?

        Si tu veux un nanim compressé individuellement, il suffit de faire:
        gzip zoey.nanim

        Très mauvaise compression

        • [^] # Re: Incohérent

          Posté par  (site web personnel) . Évalué à 2.

          Pourquoi ne pas faire ça justement? Genre un fichier image d'un format qui va bien (et directement géré par la CG si possible) et un fichier de métadonnées dans une archive?

          C'est une option que j'ai envisagé, mais j'ai trouvé ça moins simple que la solution avec protobuf: aujourd'hui pour créer un parser de nanim dans à peu près tous les langages, il suffit de lancer un compilateur protobuf…. et c'est tout!

          Très mauvaise compression

          Tu préfères bzip2?

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: Incohérent

            Posté par  (site web personnel) . Évalué à 2.

            Tu préfères bzip2?

            Soyons modernes : XZ. Plus rapide à décompresser que bzip2, presque aussi rapide que gzip en fait.

          • [^] # Re: Incohérent

            Posté par  . Évalué à 2.

            Très mauvaise compression

            Tu préfères bzip2?

            Ni l'un ni n'autre ne sont adaptés à la compression d'image ou de texture.

Suivre le flux des commentaires

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