Le livre "Programming Linux Games" disponible en pdf

Posté par  . Modéré par Fabien Penso.
Étiquettes :
1
25
oct.
2002
Livre
Plus d'excuse possible pour ne pas programmer de jeux sous Linux ! John R. Hall met à disposition (sur son site au format pdf et LaTeX) le livre "Programming Linux Games" qui couvre notament l'utilisation de SDL mais aussi
la gestion du son, du réseau, et l'utilisation d'outil de développement sous Linux. Un bon point de départ pour tout ceux qui veulent créer des jeux.

Aller plus loin

  • # Re: Le livre

    Posté par  . Évalué à 1.

    Moi je l'ai ce livre

    Il est pas mal, recouvre un peu tous les outils de dvlt de Linux, les methodes de Debuggages (comme quoi on avait pas besoin d'attendre IBM)

    Ce serait un hommage a M. Hall d'acheter son livre plutot que de le pomper sur le Net.

    C vrai quoi, des livres comme celui là il n'en existe pas tant !

    Seul regret toutefois : Tout est en C, les fans de C++ seront deçus.
    • [^] # Re: Le livre

      Posté par  . Évalué à 1.

      Moi je suis fan d'Ocaml, j'ai aussi le droit d'ètre déçu ?
      • [^] # Re: Le livre

        Posté par  . Évalué à 1.

        et pis, il a beau traiter du réseau, comme c'est pas du perl ça avancera pas le schmillblick quant au mode réseau de frozen-bobble...

        --
        mais ou est passée ma signature !!
    • [^] # Re: Le livre

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

      Les programmeurs C++ commencent à être habitués à fait des objets autour d'API en C...
      • [^] # Re: Le livre

        Posté par  . Évalué à 1.

        Huh ? Où as-tu vu que le bouquin parlait de programmation objet ?
        Pour atténuer ton troll, deux remarques:
        - ClanLib est en C++ (mais le bouquin n'en parle quasi pas)
        - Tu peux mettre des morceaux de SDL dans du code C++

        Les programmeurs C++ n'ont jamais été obligé par quiconque de faire de l'objet en C.. et s'ils "commencent à y etre habitués", j'en déduirais donc que Gtk est meilleur (oui, on a tous vu que ton troll visait Gtk vs Qt) !
        • [^] # Re: Le livre

          Posté par  . Évalué à 1.

          AMHA ce n'était pas un troll. Pas mal de bibliothèques sont en C, et ceux qui font du C++ sont habitués à faire des parties orientées C ou utilisant des bibliothèques en C.

          « Tu peux mettre des morceaux de SDL dans du code C++ »

          Ce sera, dans ces passages là, un style de programmation plus proche du C que du C++. Mais il n'a pas dit que c'était mal. Ceux qui le veulent peuvent intégrer ça dans des objets, et n'utiliser plus que des objets dans le noyau de leur application.

          « Les programmeurs C++ n'ont jamais été obligé par quiconque de faire de l'objet en C.. »

          Mais il n'a dit ça nulle part ! Faire des objets autour d'API en C c'est se faire une petite bibliothèque orientée objet utilisant une API en C (mais l'API de la bibliothèque, elle, sera bien en C++), afin que dans le reste de son programme on n'ait pas à faire du C, mais du C++ en n'utilisant que des objets.
    • [^] # Faire des jeux en C....

      Posté par  . Évalué à 1.

      C'est vrai qu'il est toujours possible d'encapsuler du C pour en faire du C++. Mais c'est dommage qu'un bouquin qui parle des jeux ne soit pas en C++, langage devenu véritablement standard dans l'industrie du jeu vidéo.

      Je dis ça comme ça, mais dans le monde des jeux commerciaux, un programmeur qui ne travaille pas en C++, je lui souhaite bon courage pour se faire embaucher ou que ce soit. (Surtout en ce moment.)
      • [^] # Re: Faire des jeux en C....

        Posté par  . Évalué à 1.

        je ne crois pas qu'ils fassent de C++ sur game boy advance. Par contre si tu tates en C, c'est bon. Et puis de toute façon on peut faire de l'objet en C (ça craint un peu, mais bon...).
        • [^] # Re: Faire des jeux en C....

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

          > de toute façon on peut faire de l'objet en C
          Je suis meme tombe un jour sur un prof qui nous a fait faire de l'objet en Prolog. C'est de la perversion 8-)
          • [^] # Re: Faire des jeux en C....

            Posté par  . Évalué à 1.

            kes ke des objets peuvent bien avoir à foutre dans un langage logique comme prolog ??????
            • [^] # Re: Faire des jeux en C....

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

              > kes ke des objets peuvent bien avoir à foutre dans un langage logique comme prolog ??????
              Absolument rien AMHA. Ceci dit c'est vrai que "techniquement" tu peux arriver a recreer les concepts d'instance et de classe a l'aide de predicats. Il semble me rappeler qu'on avait meme fait un peu d'heritage. En toute bonne foi, c'est un des trucs les plus louches que j'ai jamais vu en info, c'etait limite incomprehensible, je n'en ai jamais vu aucune application utile, et en toute sincerite vu la complexite du bidule je pense que ce genre de manip est reserve a une certaines categorie de chercheurs illumines -<8-P
          • [^] # Re: Faire des jeux en C....

            Posté par  . Évalué à 1.

            j'ai bien fait de l'objet en scheme...
      • [^] # Re: Faire des jeux en C....

        Posté par  . Évalué à 1.

        « C'est vrai qu'il est toujours possible d'encapsuler du C pour en faire du C++. Mais c'est dommage qu'un bouquin qui parle des jeux ne soit pas en C++, langage devenu véritablement standard dans l'industrie du jeu vidéo. »

        Quel est le problème ?... avoir des exemples en C alors qu'un programme sera plutot en C++ ? Mais ce dont il est question c'est souvent assez bas niveau, le C convient très bien. Le C++ sera surement mieux si tu parles de design. Beaucoup de bibliothèques utiles pour les jeux sont en C, ça n'empeche pas de les utiliser en C++. Ce qui compte c'est le contenu, pas le langage, surtout quand il ne s'agit que d'exemples et que la plupart des API utiles aux jeux sont en C.
  • # Le C c'est mal

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

    C'est mal de tout programmer en C. Il faut programmer dans des langages de plus haut niveau pour accélerer le cycle de développement, avoir des programmes plus sûrs et plus maintenables (car plus courts). Et bien sûr les parties critiques du code peuvent être encore écrites en C (voire en assembleur, soyons fous).

    Franchement, par exemple pour SDL, quand tu sais que tu as le choix entre une quinzaine de bindings différents, avec entre autre C++, Perl, Python, Ruby, ou OCaml c'est vraiment dommage d'utiliser du C pur.

    Hint : choisir OCaml parmi les langages sus-cités (hail language troll).
    • [^] # Re: Le C c'est mal

      Posté par  (Mastodon) . Évalué à 1.

      À propos, j'aime beaucoup Ruby, et je me suis toujours demandé dans quelle mesure un script ruby était plus lent qu'un programme compilé. Dans le cas d'un jeu, ça doit commencer à se sentir (vu que pas mal de jeux codés en C/C++ rament sur ma machine). Bon je sais bien qu'il est facile d'incorporer du code C compilé dans un script ruby, mais ça perd un peu de son intérêt.
    • [^] # Re: Le C c'est mal

      Posté par  . Évalué à 1.

      C'est mal de tout programmer en C.

      oui mais si tu fais pas du C t es pas un pur et dur t es une tapaite , pour preuve , pour beaucoup kde sux parce que c est du c++
      • [^] # Commentaire supprimé

        Posté par  . Évalué à 1.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Le C c'est mal

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

          Ça te fait du bien de taper sur un logiciel toute la journée ?
          C'est pour compenser le fait que tu n'as pas pu rencontrer les gens à qui tu voulais casser la gueule ?
          • [^] # Commentaire supprimé

            Posté par  . Évalué à 1.

            Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Le C c'est mal

          Posté par  . Évalué à 1.

          Tiens c'est curieux moi c'est exactement l'inverse.. Je me fous aussi que ce soit du C ou du C++, (ie. du Gtk ou du Qt), tant pis pour le programmeur.. par contre, je vois bien quand l'un des deux me permets de détacher les menus, de changer mes raccourcis à la volée, ou de ne pas me faire chier avec des dockables windoze (faites moi penser à flinguer le mec qui a inventé ca)

          A part ca, tu sais faire des critiques plus constructives et moins débile que de dire "ca sux", ou tu profites juste du fait que les XP ne sont plus là ? Parce que bon, j'aurai aimé pouvoir te dire que je suis *ravi* d'apprendre que tu trouves que Gnome sux.. mais non, je m'en contrefous
          • [^] # Commentaire supprimé

            Posté par  . Évalué à 1.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Le C c'est mal

              Posté par  (Mastodon) . Évalué à 1.

              Euh, tu as l'air ironique, mais pouvoir détacher les menus et changer les raccourcis clavier à la volée, c'est aussi un de mes critères de choix pour un environnement. Et ce sont aussi des arguments bien plus concrets de dire que Gnome sux et KDE rulez sarace.

              Yusei, qui utilise Window Maker avec des applications Gnome, KDE, ou autre, mais qui préfère vraiment les interfaces à base de Gtk.
              • [^] # Re: Le C c'est mal

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

                Yusei, qui utilise Window Maker avec des applications Gnome, KDE, ou autre, mais qui préfère vraiment les interfaces à base de Gtk.

                Ne dis pas ça, tu vas te faire démolir.
                GTK+ ça suXe, la preuve ils l'ont dit sur Internet, ça ne peut donc pas être faux.
                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 1.

                  Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Re: Le C c'est mal

                    Posté par  . Évalué à 1.

                    Moi, comme je suis fatigué, je suis plutot au rang de jebi
              • [^] # Commentaire supprimé

                Posté par  . Évalué à 1.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: Le C c'est mal

                  Posté par  (Mastodon) . Évalué à 1.

                  Ahlala, l'art de prendre ses interlocuteurs pour des crétins décérébrés.

                  T'es gentil, on parlera de nuances quand ton argumentaire comportera autre chose que des "rox", "sux" et "c'est de la merde". Et quand tu auras appris à lire car je ne prenais pas position sur Gnome ni sur Gtk-en-tant-que-programmeur, je ne faisais que réagir à ton mépris envers quelque qui utilise des arguments.

                  (J'veux avoir le droit de mettre -1 quand je répond à un troll !)
            • [^] # Re: Le C c'est mal

              Posté par  . Évalué à 1.

              Juste pour info, l'utilisateur lambda est *tres* concerné par l'interface de son PC.. c'est aussi pour ca que Linux a du mal à s'imposer (beaucoup d'entre eux croient que Linux ne fonctionne qu'en ligne de commande). Et un bon point de KDE: par défaut, cliquer sur un icone lance l'appli (pas comme Gnome ou faut le faire deux fois, c'est idiot et contre-intuitif - a peu pres aussi contre-intutif que de faire Alt-F4 pour "close")
              Si on me dit "ce bureau ci est plus fatiguant que celui là" (parce que, par exemple, 30% des clicks ne sont pas réellement nécessaires, ainsi que 20 mètres de souris à parcourir(1)), et bien ca fait clairement pencher mon choix..

              Et pour alimenter le débat Gnome/KDE-pour-les-lambdas-user, je trouve, non pardon, j'ai constaté que pour les newbies, Nautilus est beaucoup plus accessible que Konqueror.. ses "emblemes" et les "notes", que nous trouvons stupides, se sont révélés etre une tres bonne idée pour les newbies (j'ai meme vu des windozeurs demander à faire une telle chose dans MSExplorer (sans savoir que Nautilus le faisait)). Ce serait une bonne idée de rajouter ca dans Konqueror

              (1): Au fait, je me suis toujours demandé l'interet de placer le panel en bas, alors que la plupart du temps, la souris passe son temps vers le haut des fenetres (là où sont les barres de titre)
              • [^] # Commentaire supprimé

                Posté par  . Évalué à 1.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: Le C c'est mal

                  Posté par  . Évalué à 1.

                  Sauf que convertir un CD en .ogg, ca n'est pas du tout le boulot du gestionnaire de fichier, mais plutot d'un truc comme Grip. Avoir changé de gestionnaire de fichier pour quelque chose qui est particulièrement accessoire, c'est à peine crédible - Si encore, le CD pouvait se trouver dans des endroits très différents de l'arboressence, ou si encore on pouvait ripper autre chose que des CD, je comprendrais que ca figure dans le gestionnaire de fichier, mais là, que ce soit integré à Konqueror, ou que ce soit une appli externe, c'est strictement identique !
                  Peut-etre que (et vu tes délires anti-gnome, c'est particulièrement possible) que tu t'es bien gardé de lui montrer Grip, c'est ca ?
                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à 1.

                    Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Le C c'est BIEN

          Posté par  . Évalué à 1.

          A tu deja compare en terme de vitesse GNOME et KDE ?
          Tu as vite choisi :)
          Meme sur une machine puissante KDE n'est d'une rapidite quasi instanne a la GNOME ou GnuStep+WindowMaker.
          Et puis vouloir absolument que ca ressemble a windows, c'est plus pitoyable qu'autre chose.
          Et pour finir, les applet dans le panel GNOME, c'est vraiment terrible. Il n'y a pas ca dans kde il me semble, mais je peux me tromper .....
          • [^] # Re: Le C c'est BIEN

            Posté par  . Évalué à 1.

            Et puis vouloir absolument que ca ressemble a windows, c'est plus pitoyable qu'autre chose.

            C'est aussi ce que je pensais, au début.. mais finalement, je trouve que c'est une bonne chose qu'on ait au moins un desktop cloné sur MSWin jusque dans ses raccourcis claviers.. Ca permet aux windozeurs de faire une transition plus facile, et d'attirer les lusers type slashdotteurs "c'est pas comme MSWin == c'est nul". L'important, c'est qu'on n'est pas obligé de l'utiliser, ou qu'on peut le configurer pour qu'il soit plus efficace et (ie. par exemple, changer le mode de focus) et plus beau (KDE 3.1 est horrible par défaut, on dirait du Playschool)...
          • [^] # Re: Le C c'est BIEN

            Posté par  . Évalué à 1.

            mouuaarrrf A tu deja compare en terme de vitesse GNOME et KDE ?
            et Il n'y a pas ca dans kde il me semble, mais je peux me tromper .....

            il y a des applets dans kde , il est meme compatbile avec les dockapp windowmaker , bref qd on met ces 2 phrases l une a coté de l autre , on se demande si t as reelment testé kde...
            • [^] # Re: Le C c'est BIEN

              Posté par  . Évalué à 1.

              >il y a des applets dans kde
              Dans GNOME aussi. Et surement meme plus complexe.

              >bref qd on met ces 2 phrases l une a coté de l autre , on se demande si t as reelment >testé kde...
              Sisi, je l'ai tester et ca ne m'a vraiment pas convaincu. C'est d'une lenteur affligente.
              • [^] # Re: Le C c'est BIEN

                Posté par  . Évalué à 1.

                C' est marrant qd meme , precedement tu disais que y avait pas d applet dans kde et maintenant tu dis que dans gnome elles sont plus complexes...

                Enfin bon juger un desktop sur ces applets c est un peu n importequoi n dans ce cas windowmaker est forcement ce qu il y a de mieux.
                • [^] # Re: Le C c'est BIEN

                  Posté par  (Mastodon) . Évalué à 1.

                  «dans ce cas windowmaker est forcement ce qu il y a de mieux.»

                  Ben... oui, à croire que c'est pas un si mauvais critère ;-)
                • [^] # Re: Le C c'est BIEN

                  Posté par  . Évalué à 1.

                  > C' est marrant qd meme , precedement tu disais que y avait pas d applet dans kde et >maintenant tu dis que dans gnome elles sont plus complexes...

                  J'ai dis que je n'etait *pas sur de leur presence*, nuance (d'ou le "je peux me tromper" :) et qu'an tous cas ceux de GNOME etait terrible ! Tu as la facheuse habitude de tranforme ce que les gend dise .....

                  >Enfin bon juger un desktop sur ces applets c est un peu n importequoi n dans ce cas >windowmaker est forcement ce qu il y a de mieux.

                  Les applets c'est une chose parmis d'autre mais ca a son importance. Ceci dit je serais d'accord pour dire qu'il n'y a pas que ca.
            • [^] # Re: Le C c'est BIEN

              Posté par  . Évalué à 1.

              >il y a des applets dans kde
              Dans GNOME aussi. Et surement meme plus complexe.

              >bref qd on met ces 2 phrases l une a coté de l autre , on se demande si t as reelment >testé kde...
              Sisi, je l'ai tester et ca ne m'a vraiment pas convaincu. C'est d'une lenteur affligente.
    • [^] # Re: Le C c'est mal

      Posté par  . Évalué à 1.

      Tout à fait.

      Vivement que Linux soit programmé en Lisp ou en OCaml, que les utilisateurs aient enfin le système sûr qu'ils méritent. Les jeux qui seront alors programmés dans les mêmes langages auront une qualité incomparable avec ceux disponibles actuellement, programmés dans des langages aussi archaïques que le C ou le C++. De plus, grâce a l'instantanéité du développement en Lisp et en OCaml on aura la version 2 du hit du moment le lendemain, et la version 3 le surlendemain.
      Je me réjouis qu'en ces sombres heures conservatrices, des gens audacieux osent enfin dire la vérité et s'élever contre la barbarie C et la dictature Kernighan et Ritchie. Ces deux sombres imbéciles, qui ont fait perdre 30 ans à l'informatique, meriteront tout le mal qu'on dira d'eux lorsque l'ensemble des programmeurs aura reconnu la supériorité d'OCaml.
      • [^] # Re: Le C c'est mal

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

        Mais ca sera sans compter l'offensive des sorciers du clan PERL, qui se feront une joie sans limite de semer le chaos dans ton joli univers en technicolor !

        Les plus beaux poemes sont ecrits en PERL, argument indiscutable pour programmer jeu comme Frozen Bobble !
    • [^] # Re: Le C c'est mal

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

      > langages de plus haut niveau pour accélerer le cycle de développement,
      Mouaif, bof. Developper en Python/Perl/Ruby je veux bien que ce soit plus rapide qu'en C standard. Mais concernant le C++, je suis pas sur.

      J'ai personnellement developpe 2 projets de complexite equivalente, l'un en C, l'autre en C++. Celui en C est paradoxalement plus facile a maintenir; paradoxalement car il est vrai que tout le monde (ou presque) semble s'accorder pour dire que le C++ est plus maintenable.

      Le probleme du C++, c'est que:
      - il est moins standardise. Concretement, tu peux avoir des problemes de format de binaire (gcc 2.x vs gcc 3.x). Certains toolkits super utiles comme STL marchent bizarrement sur certaines plates-formes (Visual C++ pour ne pas le citer...), et d'une maniere generale il est plus facile de trouver un plus petit denominateur commun en C qu'en C++.
      - les temps de compilation en C++ sont redhibitoires. Avec mon projet C++, je suis monte a 45 minutes de compilation sur un P200. Maintenant sur un Athlon 1.4GHz ca va un peu mieux, mais par rapport a du C c'est je jour et la nuit. Donc concretement, je passe la moitie du temps a compiler quand je programme en C++, alors qu'en C c'est quasi instantane.
      - le C++ a tendance a pousser les gens vers la perfection. Et c'est pas toujours un bien. On se dit "Ah oui je pourrais peut-etre faire un truc conceptuellement plus beau en faisant ceci ou en faisant cela...". Et du coup on passe son temps a remodeler des trucs qui marchaient deja. En C je trouve que les criteres d'appreciation du code sont plus simples: ca fait ce qu'on veut, ca plante pas -> OK c'est bon.
      - le C++ est AMHA beaucoup moins lisible/facile a comprendre que le C. En effet, le language aide le programmeur donc le programmeur n'hesite pas a mettre en place des mecanismes assez complexes. Pour prendre l'exemple de ClanLib, le code est assez dur a comprendre. Tu as des classes qui font Provider de ceci ou de cela, des trucs qui heritent de partout, du masquage de donnees, des concepts a tout va, des connecteurs en veux-tu en voila. Au final, c'est tres joli, mais beaucoup plus dur a comprendre qu'un code qui ferait la meme chose en C. Enfin c'est mon avis.
      - en parlant de maintenabilite du C++, je rappelle que ClanLib, qui est en C++, a une API extremement instable qui bouge tout le temps, et est bien loin derriere SDL et Allegro ( http://www.talula.demon.co.uk/allegro/(...) ) en terme de stabilite (je parle ici de la stabilite au sens "ne pas faire de core dump"). Typiquement, les developpeurs de ClanLib ne cessent de faire du "redesign" de l'API parce que "ca sera plus beau comme ca", et la bibliotheque est pas mal victime de bugs lies au C++ (destructeurs appeles 2 fois, fuites memoire...). Prenons un exemple, la gestion des fichiers "a la .wad" a savoir stocker des donnees dans un seul fichier, et y acceder par mot-cle. Les developpeurs d'Allegro ont fait un truc super basique. Tu peux grosso-modo stocker les types "de base" de la lib (font, bitmap, sample...) et pour tes donnees "a toi" on t'offre la possibilite de manipuler le type de donnees "raw data" et tu recupere un pointeur "void *" sur tes donnees. Ca permet de tout faire. Mais c'est pas beau. Avec ClanLib en C++, c'est boOOOO! Par contre l'API a deja change au moins une fois en 2 ans (5 ans sans aucun changement pour Allegro). Tu dispose de supers classes de la mort pour enregistrer toi-meme ton propre type de donnees etc. Genial, mais en quoi cela fait-il gagner du temps? Moi je ne vois pas. Avec le bon vieux "void *" on en faisait autant... De plus, le C++ ne permet absolument pas de s'affranchir des problemes de faute memoire. Par contre, c'est vrai, c'est plus joli. Maintenant faut savoir si on veut faire du code joli ou du code qui marche.
      Pour finir avec cette reflexion, je tiens a preciser que les developpeurs de ClanLib font un *excellent* boulot, sont tres competents, et mon propos n'est absolument pas de dire que leur projet est mediocre. Au contraire. Mais je ne vois pas en quoi C++ leur fait gagner du temps...

      Sur ce, bonne fin de week-end.
  • # Re: Le livre

    Posté par  . Évalué à 1.

    En regardant de plus près,
    le contenu des pdf ne semblent n'avoir aucun rapport avec le contenu des tex

    Avec quel outil lit-on les .tex SVP ?

    bon week
    • [^] # Re: Le livre

      Posté par  . Évalué à 1.

      avec latex (j'ai pas regardé, mais a priori, les .tex sont surement des fichiers Latex), qui les compile et génère un dvi, que tu peux lire avec xdvi, ou transformer en postscript avec dvips
      • [^] # Re: Le livre

        Posté par  . Évalué à 1.

        Je pense qu'il suffit de tapez make dans la console étant donné qu'il y a un Makefile....

        Aprés il faut avoir Latex et les bon outils pour que la "compilation" du pdf se déroule bien.
        • [^] # Re: Le livre

          Posté par  . Évalué à 1.

          J'oubliai, après lecture du Makefile :
          Il y a 2 options :
          make pdf , pour obtenir le fichier pdf.
          make clean , pour effacer les fichiers temporaires.

          J'ai pas testé mais le Makefile semble correcte.
    • [^] # Re: Le livre

      Posté par  . Évalué à 1.

      « le contenu des pdf ne semblent n'avoir aucun rapport avec le contenu des tex

      Avec quel outil lit-on les .tex SVP ? »


      Si tu ne connais pas LaTeX, ça n'a sans doute aucun intérêt pour toi de lire ces fichiers .tex. On les lit avec un éditeur de texte, rien d'autre, ce que tu y trouves ce sont des commandes en langage LaTeX, et une fois compilé ça donne le pdf. Les différentes étapes apparaissent dans le Makefile, si tu veux le détail des outils utilisés. Le .tex n'est vraiment utile ici que pour modifier. Ce qui n'est pas encore autorisé, l'auteur espère le passer en libre prochainement, mais ce n'est pas encore le cas, il est simplement gratuit et disponible en ligne.

Suivre le flux des commentaires

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