Journal Un planet francophone pour Blender

Posté par (page perso) . Licence CC by-sa
22
14
déc.
2012

Sommaire

Depuis que Warmux est mort, depuis que je n'écris plus d'articles (ou très peu) sur des logiciels libres, le fait de ne plus être impliqué dans un projet libre commençait à me titiller. Mais que faire ? Dans quel projet s'investir ? Créer quelque chose de nouveau ou rejoindre une communauté ? Pas toujours simple de savoir où aller.

Dernièrement, je m'amuse avec un logiciel en particulier : Blender, logiciel de modélisation et d'animation libre qu'il n'est pas vraiment nécessaire de présenter ici.

J'ai pensé que je passais certainement à coté de nombreux articles et tutoriels dispersés sur différents blogs (comme j'ai pu le faire à quelques occasions sur le mien). L'idée est alors venue de mettre en place un planet blender francophone. Pour les blogs agrégés, le planet apporterais une certaine visibilité, pour les visiteurs du planet cela permettrais de trouver en un lieu différentes sources d'information.

J'ai commencé par proposer l'idée sur le forum de BlenderClan car ses membres forment une communauté très intéressante et j'ai eu un accueil particulièrement sympathique pour chacune de mes questions sur le forum. Passer outre une telle communauté m'aurait semblé absurde. L'idée semble potentiellement intéresser quelques personnes. Toutefois, celle d'ajouter une entrée dans sa todo list déjà bien fournie ne semble pas enthousiasmer outre mesure ebrain, l'administrateur du site. Il est alors temps pour moi de mettre les mains dans le cambouis numérique… C'est parti pour la création d'un planet francophone dédié à Blender !

Un nom de site

Si pour l'instant, le but est uniquement de créer un planet, il n'y a pas vraiment de raison de se limiter à cela à long terme, on évitera donc de déposer un nom y faisant référence. Sait-on jamais, si le projet fonctionne bien et qu'une communauté se créée autour, peut-être que d'autres fonctionnalités s'y rattacheront. Les sites communautaires francophones par excellence sont, à mes yeux, Framasoft et LinuxFr.org (évidemment !). Même si la pieuvre que devient, pour mon plus grand plaisir, le premier (Framalab, Framatrucs,…), j'ai toujours eu un petit faible pour le second (je ne dis pas ça parce que j'écris ce journal). Je décide alors de prendre le nom linuxfr.org comme référence, ce sera blenderfr.org, ça tombe bien le domaine est libre. Argh, petit imprévu, il existe déjà #blender-fr. Un petit tour sur le canal freenode en question pour savoir si le fait que mon projet utilise un nom proche dérange me permettra d'avoir la conscience tranquille et surtout de rencontrer une communauté fort sympathique. D'une pierre, deux coups.

Un hébergeur

Plusieurs solutions s'offraient à moi : du gratuit, du payant, du libre,… J'aurais pu faire héberger le site chez free comme ce blog, mais je ne voulais pas du free.fr dans l'adresse. J'aurais pu proposer le projet chez TuxFamily mais il y a longtemps j'ai eu quelques contacts mail effroyablement irrespectueux et désagréables de son président. J'ai fini par me laisser tenter par OVH parce que leurs offres étaient claires, pas trop onéreuses, parce que j'avais déjà utilisé leurs services pour Warmux…

Un CMS

En fait, cette question ne s'est pas vraiment posée. Il existe de nombreuses solutions pour mettre en place des planets mais l'une d'elle me semblait plus évidente : Bilboplanet. C'est le CMS avec lequel Planet-libre est mis en place, il est libre et gratuit, développé par un francophone (ce qui permet des échanges potentiels plus simples), il est en train d'évoluer et au moment où l'idée du planet m'est venue, l'annonce d'une nouvelle version en cours de développement apparaissait dans mon agrégateur.

En une vingtaine de jours, j'ai envoyé une vingtaine de courriels à Grégoire de Hemptinne, développeur de BilboPlanet (sans parler des discussions par messagerie instantanée). Je crois qu'arrivé à ce stade on peut parler de harcèlement. Pourtant mon interlocuteur reste particulièrement patient, à l'écoute de mes remarques, rapports de bugs, requêtes, questions… Comment voulez-vous que je ne sois pas conforté dans mon choix lorsque les développeurs du projet ont un tel comportement ?

Un logo

J'avais dans mes marques-pages, un tutoriel expliquant comment dessiner une planète réaliste, j'avais vu la vidéo il y a quelques temps et me souvenait qu'elle était intéressante. Comme pour appuyer l'idée que c'est bien à partir de ce tutoriel que je devais faire mon logo, Blender4d publie un billet sur le sujet au moment même où je cherche l'inspiration. J'applique le tutoriel sur une Suzanne (pour faire simple disons qu'il s'agit de la mascotte de Blender) et obtient un logo convenable.

logo.png

Un CSS

Le style CSS par défaut de la version de développement de Bilboplanet ne me convient pas vraiment. J'ai commencé à le modifier mais j'ai encore énormément de travail à fournir pour obtenir un résultat qui me convienne parfaitement. Mais si j'attends que tout soit parfait pour ouvrir officiellement le projet, je vais attendre indéfiniment. Considérant que le site est correct, ne fait pas saigner des yeux, je décide d'ouvrir les hostilités et j'améliorerai le site au fur et à mesure.

Bon, pour l'instant, c'est sûr, c'est plutôt ridicule puisque le planet n'agrège que cinq billets francophones en rapport avec Blender, les miens (et un pour annoncer la création du planet qui plus est…). Pour l'instant, la charte et l'inscription ne sont pas assez mises en avant (dans le menu en haut à droite) mais cela sera résolu sous peu.

Une charte

Je souhaite que tout ceux qui apprécie Blender puissent participer au projet, la charte est donc simple. Pour inscrire son flux sur Planet Blenderfr.org :
- Appréciez Blender
- Amusez-vous avec Blender
- Écrivez vos articles dans un français correct
- Pas d'insultes, d'incivilités,…

La charte évoluera peut-être en fonction des problèmes éventuellement rencontrés. J'espère que vous serez intéressés par le projet et que tout ceux qui ont des flux francophones en rapport avec Blender n'hésiteront pas à s'inscrire.

  • # le logo

    Posté par . Évalué à  2 .

    Je n'utilise pas Blender et ne m'y intéresse pas vraiment, du moins actuellement.
    Donc ce qui suit est une simple constatation sur le logo que tu as créé, avec pour seul objectif de pointer une contradiction qui m'a sauté aux yeux :

    le logo de blenderfr.org est donc Suzanne sur laquelle tu mappes une image du globe terrestre. Le fait que seul le continent américain soit visible au final ne te gêne pas ? À part Québec, je ne vois pas trop comment cela représente la francophonie.

    Pour le reste bon courage et longue vie à ton nouveau projet.

    • [^] # Re: le logo

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

      c'est plus le continent africain qui est visible principalement (dessus de la tête) mais la suzanne déforme tellement la carte que les continents ne sont plus reconnaissables aisément, par conséquent ça ne me choque pas spécialement de ne pas mettre en avant l'Amérique.

      Image utilisée : http://www.blenderguru.com/wp-content/uploads/2011/06/Color%20Map.jpg

      • [^] # Re: le logo

        Posté par . Évalué à  4 .

        Pfiouf … maintenant que tu le dis, avec les couleurs je vois bien que c'est le continent africain sur la tête, mais dans la forme, et sans avoir l'image originale sous le nez, je voyais le continent américain avec la péninsule californienne à coté de l'oreille.
        Même avec l'image originale, je n'arrive pas à reconnaître les différents continents sur Suzanne.

        bon ben je sors alors …

    • [^] # Re: le logo

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

      Coté logo, avant lecture je pensais que c’était un effet de pierre, donc en ce qui me concerne, l’aspect mondial me paraît mal rendu. Si le but recherché est de représenter la francophonie, il vaut mieux dériver le logo idoine non, comme le fait le projet bépo par exemple.

      • [^] # Re: le logo

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

        Mon but était juste de faire une planète blender… le coté francophonie ne ressort pas du logo, ce n'est pas un problème

        • [^] # Re: le logo

          Posté par . Évalué à  1 .

          As-tu envisagé une collaboration avec Linuxgraphic.org?
          Je sais ce qu'est une planète ou un cercle mais bon, est-ce que ça vaut la peine de disperser les efforts?

          Tiens en plus, la Une en ce moment sur Linuxgraphic.org traite de Blender. :)

          • [^] # Re: le logo

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

            J'avais envie de m'amuser et de voir les fonctionnalités dont il était question dans le tutoriel, et puis pourquoi aurais-je laissé la partie la plus intéressante à quelqu'un d'autre ?

  • # planet ou "ring" ?

    Posté par . Évalué à  8 .

    Si le but est de réunir les ressources sur blender, ou sur n'importe quel sujet en fait, le plus simple ne serait-il pas de faire quelque chose comme les "ring" (ou cercles en français) pré-web 2.0, à l'époque ou l'on savait faire autrement qu'utiliser un moteur de recherche pour naviguer sur le web…

    Ils consistaient simplement en le partage d'un bout de code commun que les sites web voulant adhérer collaient sur leur site web (souvent en bas de page) et qui contenait, entres autres choses, un logo commun, un lien "précédent", un lien "suivant" et un lien "random" permettant d'accéder à d'autres site du cercle (et parfois de la pub, certes).

    Le principe est tout sauf con, et permet de remplacer assez avantageusement les heures passées sur google votre moteur de recherche préféré à vérifier la pertinence des résultats…
    Malheureusement, ce genre de technique n'est plus trop utilisé de nos jours, remplacées qu'elles sont par la modernité gogole (on est vendredi après tout).

    • [^] # Re: planet ou "ring" ?

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

      L'avantage du planet est de ne s'abonner qu'à un flux RSS et avoir automatiquement tous les articles récents sur le sujet, plutôt que d'explorer l'anneau à la main.

  • # Nom du site

    Posté par . Évalué à  0 .

    Et pourquoi pas un Blender.fr ? Plus intuitif, malheureusement le nom de domaine ne semble pas entièrement libre.
    Je ne sais pas ce que OVH propose pour l'achat d'un nom de domaine, mais si tu le prend à part je te conseille bookmyname.com, les .fr sont 1€ moins cher que les .org d’ailleurs :D

    • [^] # Re: Nom du site

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

      Parce qu'il veut lancer un Planet francophone, et pas français? Ça pourra peut être horripiler quelques âmes bien franchouillardes, mais n'étant pas français, je ne m'identifie aucunement dans un *.fr

      • [^] # Re: Nom du site

        Posté par . Évalué à  3 .

        Parce qu'il veut lancer un Planet francophone

        Bah justement, francophone ça ne commence pas par fr ?

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

        • [^] # Re: Nom du site

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

          francophone ça ne commence pas par fr ?

          Seulement dans Usenet, mon bon…

          * Ils vendront Usenet quand on aura fini de le remplir.

  • # Tuxfamily

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

    Sinon, par rapport au retour d’expérience de Tuxfamily, j’ai une toute autre expérience : équipe chaleureuse et répondant très rapidement aux requêtes. Un grand merci à ses éventuelles membres qui passeraient par là.

    • [^] # Re: Tuxfamily

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

      Ton message me semble tout à fait pertinent. Je tiens du coup à préciser mon propos. Je ne dis pas que TuxFamily est un mauvais projet ou que sa communauté est {insulte de votre choix}. J'ai eu des contacts malheureux avec une personne chez TuxFamily suite à des problèmes dont j'étais en partie responsable mais qui étaient très loin d'exiger d'être désagréable. Mon interlocuteur avait fait le choix d'être particulièrement odieux, cela m'a laisser un mauvais souvenir qui fait que plus de 4 ans après les faits, je ressens toujours personnellement une gène à l'idée de demander quoi que ce soit à l'association.

    • [^] # Re: Tuxfamily

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

      Tout pareil, tuxfamily héberge Slime Volley depuis toutes ces années (c'est mon plus vieux projet libre, mine de rien) et le site (et le svn surtout) est toujours debout :-)

      Concernant ta mésaventure yeKcim, l'intérêt des petites structures comme tuxfamily est de conserver le rapport humain, mais malheureusement être humain inclus aussi être parfois de mauvais poil, ce qui a pu être le cas de ton interlocuteur. C'est un peu dommage de garder des rancunes aussi longtemps pour visiblement un événement isolé. (bon cela dit ça me regarde pas, je tiens pas à lancer un débat sur le sujet :D)

      PS: Ah, et si tu t'ennuies, toi qui a des talents graphiques, je viens de lancer un appel à contribution pour avoir des thèmes pour le prochain Slime Volley, ça se trouve bien sûr à http://slime.tuxfamily.org

      • [^] # Re: Tuxfamily

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

        Du coup j'ai enfin essayé SlimeVolley (que je connaissais de nom depuis longtemps) ; je me suis bien amusé pendant bien 30 minutes contre les IA. Merci.

        J'aurai juste une remarque à propos du jeu en lui-même ; on m'a téléphoné pendant ma partie, j'ai donc fait "Echap", et là c'est le drame :), je m'attendais à ce que ça fasse pause (ce qui était possible, j'étais en local contre une IA) mais ça a arrêté ma partie.

        je viens de lancer un appel à contribution pour avoir des thèmes pour le prochain Slime Volley, ça se trouve bien sûr à http://slime.tuxfamily.org

        Plusieurs remarques sur les graphismes. Plusieurs thèmes ça pourrait être bien évidemment, mais il faudrait commencer par un tableau vraiment bien (plutôt que plusieurs moyens). Je trouve la définition des thèmes un peu limitée ; comme j'ai fait des thèmes pour HedgeWars, je vais piocher des idées concrètes chez eux:

        • les nuages sont des sprites qui se déplacent. Dans certains thèmes il n'y en a pas, dans d'autres ce ne sont pas des nuages (par exemple des vagues dans le thème sous marin).
        • il y a des petites particules qui se baladent dans le fond : des pétales de cerisiers dans le thème japonais, des gouttes de pluie etc…
        • il y a plusieurs plans, pour faire du scrolling différentiel. Vu qu'il n'y a pas de scrolling dans SlimeVolley (et que ca perturberait peut être la jouabilité d'en mettre) ça na pas forcément d’intérêt.
        • Il y a une charte graphique pour que les thèmes soient cohérents (outline épaisse, pas de dégradé…).

        Il manque à mon avis des choses dans leur moteur de thèmes, comme des sprites animés (qui ne soient pas des particules), mettre plusieurs systèmes de particules, ou des effets supplémentaires (lens flare, effet de chaleur dans le volcan…).

        Pour en revenir à ton jeu, je proposerai de pousser le coté "petits slime mignons". Premièrement en les retravaillant un peu. J'imagine qu'il faut garder l'aspect demi-sphère pour les collisions ; mais il y a certainement moyen de faire quelque chose, en travaillant l'aspect gluant et translucide par exemple. Ensuite, je verrai bien des sprites animés de slimes spectateurs dans le fond.

        Si ça te dit d'améliorer le moteur (comme des sprites en fond pour les nuages ou les spectateurs) et que mes idées te plaisent, je te propose de te faire un thème.

        • [^] # Re: Tuxfamily

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

          Hé hé, la pause est mappée sur espace, c'est une feature qui a été ajoutée après coup. J'ajoute dans le TODO de transformer le échap et pause de d'avoir ensuite le choix entre revenir au jeu et quitter (faut encore que je trouve comment agencer ça).

          Concernant toutes tes suggestions sur les graphismes, ça représente pas mal de dev alors que comme tu as sans doute pu le voir d'autres parties plus importantes ont besoin de dev : les collisions parfois buggées, les IAs qui gèrent mal le multi-balles, …
          Un truc pas trop difficile à faire est un avant-plan affiché par dessus le jeu, ça avait été réclamé par certains contributeurs de thème dans le temps (je me souviens plus de qui), j'implémenterai peut-être ça si j'ai le temps et que la demande est réitérée par d'autres mais je ne pense pas m'atteler à plus complexe avec décor mouvant et compagnie (du moins pour l'instant)
          Quelque chose que j'aurai adoré ajouter à Slime Volley était des mini animations stupides à la manière de ce qu'on trouvait dans les jeux worms. Mais j'ai d'une part jamais trop su quel format/technologie serait adapté et ensuite jamais trouvé de logiciel libre d'animation que je parvienne à utiliser. (et à la rigueur même si ça avait pas été intégré au jeu avoir les animations à coté pour la «promo» m'aurait amusé)

          • [^] # Re: Tuxfamily

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

            comme tu as sans doute pu le voir d'autres parties plus importantes ont besoin de dev

            Lors de ma première session de jeu je n'avais pas vu de bugs ; mais en rejouant pour montrer à ma copine j'ai en effet eu 2 fois ma balle qui traverse le filet.

            toutes tes suggestions sur les graphismes, ça représente pas mal de dev

            Je pense qu'en codant en dur quelques animations pour les nuages par exemple (et donc éviter de faire un moteur configurable, avec fichier de description et cie) au moins dans un premier temps, ça serait assez rapide (N sprites qui se déplacent de 1 pixel à chaque frame c'est pas la mort).

            Quelque chose que j'aurai adoré ajouter à Slime Volley était des mini animations stupides à la manière de ce qu'on trouvait dans les jeux worms. Mais j'ai d'une part jamais trop su quel format/technologie serait adapté et ensuite jamais trouvé de logiciel libre d'animation que je parvienne à utiliser.

            Pour les animations stupides je n'en ai pas parlé dans mes remarques pour ne pas avoir l'air de trop demander ! :)
            Pour le format, j'ai déjà eu une discussion sur ce site avec devnewton (qui a part la suite fait son format nanim) ; je disais que même si ce n'était pas parfait, pas mal de projets (comme Hegdewars) 'concatènent' les frames dans un seul fichier png, faute de mieux.

            Je viens de passer 30 minutes à faire un essai de sprite de slime qui me semble pas mal. Si tu me file ton adresse mail je t'envoie ça.

            • [^] # Re: Tuxfamily

              Posté par . Évalué à  2 .

              Pour les formats de dessins animés, ce genre de techniques ont plusieurs écoles:
              _ gif animés. Je sais pas comment ça marche pour la suite, mais j'imagine qu'il doit exister des lib toutes faites…
              _ un seul fichier image qui contient la liste des images. Lourd, selon moi, parce que du coup il faut que le code gère le découpage du fichier en plusieurs images
              _ une série de fichiers aux noms presque identiques "slime001", "slime002"… Bordélique si tout est laissé en plan dans le dossier des ressources, mais en créant un dossier par animation, ça passe déjà mieux. En plus, dans le cas d'un dossier, une p'tite boucle "for(File image in dossier) animation[dossier.name].add(image);" permet de faire le chargement de façon très souple. Il y a même la possibilité de faire des animations à une seule frame \o/ (ouai je sais, inutile… et donc indispensable pour pourrir l'occupation du proco :P)

              Après, je sais pas quel langage tu utilises… perso, la solution 3 en C++ je pense que c'est l'affaire d'une petite centaine de lignes, intégration de l'animation dans le jeu comprise (sachant qu'il est probable qu'une bonne partie des lignes soit déjà présentes dans ton code)

              PS: je n'ai jamais testé ce jeu, c'est juste un commentaire pour donner des idées de dev génériques et donc inapplicables en l'état à un "collègue" ;)

              • [^] # Re: Tuxfamily

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

                un seul fichier image qui contient la liste des images. Lourd, selon moi, parce que du coup il faut que le code gère le découpage du fichier en plusieurs images

                Je ne pense pas que dire que ton image en 128x512 est en fait 4 frames de 128x128 soit vraiment plus compliqué que ta solution 3. En plus dans les faits :
                - ton 'gros' fichier PNG sera surement plus petit que les 4 'petits' fichiers (factorisation des entêtes et du dictionnaire de compression).
                - tu n'auras peut être même pas besoin de découper : tes frames sont empilées verticalement, il suffira de jouer sur les pointeurs (ta 1ère frame c'est les 128x128 premiers pixels, la 2ème les 128x128 suivants etc…). Et avec un moteur 2D moderne (utilisant en fait des quad OpenGL et des textures) une simple translation des coordonnées de textures suffit à changer de frame.

                • [^] # Re: Tuxfamily

                  Posté par . Évalué à  1 .

                  • ton 'gros' fichier PNG sera surement plus petit que les 4 'petits' fichiers (factorisation des entêtes et du dictionnaire de compression).

                  Sans compter le bête fait que la place occupée sera plus grosse parce que 4 blocs non utilisés complètement seront utilisés au lien d'un seul, en effet :)
                  Le terme de "gros" fichier n'avait pas pour but d'indiquer un gain de place, mais bien un problème d'organisation des ressources.
                  Ne serait-ce que pour la création d'une frame, il me semble plus simple de créer la 1ère, copier le fichier pour en créer un nouveau, le modifier en fonction de ce que l'on veut, et ce, autant de fois que nécessaire, plutôt que de modifier un seul fichier, au risque de déborder sur l'image d'a côté.
                  Sans parler d'ajouter une frame à une animation que l'on trouve trop grossière, sait-on jamais.

                  • tu n'auras peut être même pas besoin de découper : tes frames sont empilées verticalement

                  Arf mais quel boulet je fais… pourquoi je pensais à les concaténer à l'horizontale…

                  , il suffira de jouer sur les pointeurs (ta 1ère frame c'est les 128x128 premiers pixels, la 2ème les 128x128 suivants etc…).

                  Là, j'ai envie de dire que ça dépends de la technique utilisée pour lire l'image.
                  Je viens de regarder, le code est en C, ce que j'ignorais (ça va raccourcir mon post du coup).
                  Effectivement, les pointeurs sont une solution.
                  Mais j'ai aussi vu qu'il utilise la SDL, et, de ce que je me souviens de la SDL 1.2, la logique utilisée est très proche de l'orienté objet: une sructure de données, et un jeu de fonctions pour manipuler cette structure.
                  Impossible d'utiliser les pointeurs, donc, pour n'afficher que telle ou telle zone d'une image, il faudrait donc utiliser des instances de SDL_Rect: composées de 4 entiers, c'est très lourd et nécessiteras des calculs à chaque fois que l'on voudra changer de zone de dessin. Si les calculs ne sont pas fait dans le code du jeu, ils le seront par la lib de toute façon…

                  Utiliser des fichiers séparés permet de faire un simple

                  int nbFiles;
                  char *files[nbFiles];// impossible in C, IIRC
                  SDL_Surface animation[nbFiles];// but easy to implement
                  // code to fill files with the list of file names for that animation
                  
                  for(int i=0;i!=nbFiles;++i)
                    animation[i]=SDL_LoadImage(fichier);
                  
                  

                  NB: je ne me rappelle plus les noms et paramètres précis de la SDL, pas utilisée depuis au moins 2 ans…

                  Et avec un moteur 2D moderne (utilisant en fait des quad OpenGL et des textures) une simple translation des coordonnées de textures suffit à changer de frame.

                  L'openGL, c'est un truc qu'il faut que j'apprenne à utiliser et à l'intégrer dans wxWidgets, c'est justement sur ma todo list pour autorealm…
                  Faut que je prenne le temps de chercher des bouts de code à lire et modifier… donc je ne peux pas parler de la simplicité de ce dont tu parles :)
                  D'ailleurs, si trouver des ressources pour openGL 2 et plus récent me prends trop de temps, vais finir par lâcher l'affaire et rester sur l'openGL 1 pour laquelle j'ai de la doc, et qui me poserais pas de souci si j'avais réussi a appliquer la tesselation correctement.

                  Ce dont je doute en revanche, c'est que ta simple translation soit plus beaucoup plus simple que l'approche objet à laquelle j'aurai tendance à penser pour un code 2D (qui consisterais à chaque affichage de l'animation à incrémenter un compteur interne avec un p'tit modulo pour éviter l'overflow, pour afficher l'image correspondante précédemment chargée dans un tableau dynamique. Pas plus de 40 lignes de code réel pour la classe entière, et une seule pour l'utiliser.)

                  • [^] # Re: Tuxfamily

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

                    Impossible d'utiliser les pointeurs

                    Ah oui c'est bien possible que la SDL casse les pieds dans son cas. J'évoquais juste la technique, je ne prétendais pas qu'elle était applicable ici (désolé si ce n'était pas clair).

                    Ce dont je doute en revanche, c'est que ta simple translation soit plus beaucoup plus simple que l'approche objet à laquelle j'aurai tendance à penser pour un code 2D

                    Oui on est d'accord ce n'est pas l'approche la plus simple dans l'absolu. Si tu te fais suer à faire un moteur 2D basé sur des quads 3D, c'est pour atteindre des super performances avec des sprites de haute résolution (genre les derniers Rayman) ; donc tu ne vas pas gréver tes performances pour 10 lignes de code :)
                    Je ne pense pas que l'écriture d'un tel moteur soit hyper simple non plus (mais en libre il doit y avoir celui d'Aquaria), mais quand tu auras fait de l'OpenGL, tu verras que ce que je dis est bateau.
                    Pour suivre ton approche objet, je dirais que tu passes la grosse image (128x512 pour continuer mon exemple) au constructeur de ta classe AnimatedSprite, qui va :

                    • créer une texture ; mon openGL est loin, mais ça doit être un appel de fonction pour créer l'identifiant de texture, et un autre pour passer les pixels à OpenGL (qui les mettre si possible dans la carte graphique).
                    • Créer un quad avec comme coordonnées de texture : (0, 0),(0, 0.25),(1, 0.25),(1, 0). Les 0.25 c'est bien sûr 1/4 puisqu'il y a 4 frames. Là encore une poignée de lignes de code.

                    Ta méthode display sera elle aussi assez simple :

                    • calcul de l'index 'i' de la frame en fonction du temps, avec le modulo, tout comme toi.
                    • activer la matrice de texture (un appel), faire la translation selon l'axe V de '0.25 * i' (un appel).
                    • affichage du quad (un ou deux appel j'ai un doute).
                    • la c'est vraiment loin mais il doit falloir réinitialiser la matrice de texture au moins.

                    Ça me semble relativement simple. Bon après il commence à y avoir pas mal de moteur 2D libres qui ont l'air très sympa. En discutant avec un pote hier, j'ai découvert IndieLib et Polycode.

              • [^] # Re: Tuxfamily

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

                Oui mais sauf que non.
                Je ne parlais pas d'animations ingame pour les joueurs ou autre (ce qui me parait plutôt inutile dans mon cas) mais d'animations d'introduction stupide, à la manière de ce qu'on peut trouver en intro de worms : http://youtu.be/wHzXDDwZpSI (celui ci est particulièrement adapté pour être reproduit avec des slimes, même si ça n'a pas grand sens par rapport au jeu)
                Et du coup j'aurai aimé de l'animation vectorielle où le format stock des trajectoires d'objet plutôt que de stocker en image par image, ce qui va prendre beaucoup d'espace pour rien. (en même temps ça ne sert à rien en soit donc de toutes façons…)

                • [^] # Re: Tuxfamily

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

                  Je ne parlais pas d'animations ingame pour les joueurs ou autre (ce qui me parait plutôt inutile dans mon cas)

                  Je ne vois pas en quoi des sprites animés seraient spécialement inutiles dans ton cas. Évidemment c'est de l'ordre du superficiel, mais bon on parle de jeu vidéo en même temps ! Les slimes seraient bien plus attachants avec des animations (autre que la pupille qui suit la balle). En tout cas le rapport 'temps de travail/intérêt' me parait bien supérieur à celui de faire des animations d'introduction (qui sont vues une fois et basta).

                  Et du coup j'aurai aimé de l'animation vectorielle

                  En effet il manque un tel outil en libre (et qui pourrait concurrencer les éditeur pour Flash). Si je devais le faire, ça serait peut être avec Blender et quelques scripts maison.

                  • [^] # Re: Tuxfamily

                    Posté par . Évalué à  1 .

                    (qui sont vues une fois et basta).
                    Je suis p'tet crétin, mais je dois avouer que même 10 ans après, celle de worms me fait toujours autant rire :)
                    D'ailleurs, je l'avais oublié, merci de me la rappeler :)

                    • [^] # Re: Tuxfamily

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

                      Moi ça m'a fait l'effet inverse, en la revoyant j'ai trouvé ça nul alors que j'en avais un super souvenir…

  • # Hébergeur libre: Toile Libre

    Posté par . Évalué à  4 .

    Il existe également Toile Libre pour l'hébergement libre. Je l'ai découvert il y a très peu de temps.
    Pourrions-nous avoir des retours d'expérience sur cet hébergeur ?
    Merci à vous tous.

  • # Fini Fini Wormux

    Posté par . Évalué à  2 .

    La dernière fois que j'avais suivi l'actualité de Wormux. Il était en train d'essayer un nouveau moteur physique et il y a avait un portage pour android …

    Et là, c'est le drame !

Suivre le flux des commentaires

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