GuieA_7 a écrit 675 commentaires

En pratique, quand tu écris tes tests en même que ton code (je te conseille de regarder ce qu'est le Test Driven Development) tu es rapidement plus productif qu'en écrivant ton code et en le testant ensuite "à la main". Lorsque tu dois écrire une fonction un peu 'poilue' (avec 2 "if else" consécutifs par exemple tu as déjà 4 cas à vérifier), repasser tous les cas manuellement prend énormément de temps ; ceci dit c'est encore plus long au final lorsque c'est ton client qui tombe sur le bug, met 3 heures à mal te le décrire au téléphone, que tu passes 1h à essayer de le reproduire, puis 3h à corriger ton code d'il y a 6 mois en priant de ne pas faire de régression. Alors que rejouer tes tests sur ladite fonction prend 2 secondes, et tu peux donc les rejouer entre chaque modifications pendant que tu codes ta fonction.

Il y a quelques années, j'ai codé, en TDD, 30K lignes de code en 1 an et demi (+ 45K lignes de tests). Pendant la même période, mon collègue qui travaillait sur le me logiciel, et qui testait à la main avait fait 18K lignes, et 95% des bugs qui remontaient étaient chez lui.

J'aimerai aussi l'avis d'un codeur pratiquant le Contract Driven Development ; ne l'ayant jamais pratiqué moi même je peux me tromper, mais a priori je trouve assez simple d'écrire les tests pour une fonction de tri par exemple ça pourrait donner:

assertEqual([], sort([])
assertEqual([1], sort([1])
assertEqual([1, 2], sort([1, 2])
assertEqual([1, 2, 3, 4], sort([4, 2, 1, 3])

ce qui es quand même très simple. Alors que par contrat, j'imagine qu'il faut tester que ton résultat contient tous tes éléments de départ, et uniquement ceux-là, et vérifier qu'ils sont correctement ordonnés. Ça me semble plus pénible à écrire.

Tu es de mauvaise foi, même Zenitram m'a accordé un point. Je n'ai jamais parlé de s'approprier ton code, juste de mettre des obligations sur ton code, et je te l'ai déjà dit. Depuis le début, tu me fais dire ce que je n'ai pas dit (homme de paille toussa), tu ne lis pas mes commentaires, tu veux juste dire que la GPL c'est tout pourri (https://linuxfr.org/nodes/97788/comments/1440100) et que c'est pire que la pire des licences proprios, même quand ça n'a pas de rapport avec mon propos. Libre à toi de penser ça, mais ne fais pas croire que tu me réponds. J'arrête la conversation ici, on tourne en rond.

Tu as dis que ça ne faisait chier personne, je te démontre le contraire. Que la GPL soit aussi "coupable", je l'ai dit dans mon commentaire. Ça ne change pas le fait que ça fait chier des gens tout comme la GPL ; mais moi je n'ai jamais dit que la GPL ne faisait chier personne (tout est parti d'un de MES commentaires disant que la GPL faisait chier pour une lib…).

Independants veut pas dire GPL.

Où ai-je dit ça ? Je parlais de snippets (sous licence très permissive classiquement), tout aussi proscrites, vu que libres.

Cette clause n'emmerde personne.

Vas dire ça à Atari :

http://sev-notes.blogspot.fr/2009/06/gpl-scummvm-and-violations.html

Tu pourras dire que c'est la faute de la méchante GPL, la licence de big N étant une GPL inversée, je ne vais pas tranchée mais bon…

Et si par exemple des développeurs indépendants veulent ouvrir un forum où ils postent des tips de programmation, bouts de code à l'appui, tant pis pour eux. Après Nintendo commence à peine à comprendre que les indépendants c'est peut être une bonne idée de ne pas leur cracher à la gueule.

On attends toujours une licence proprio qui t'impose de leur donner ton code

Moi je répondais juste à ça :

Je te demande de démontrer (facile, il suffit d'une) qu'il y a la moindre licence proprio qui demande des choses sur le code qui n'est pas à lui.

Donc oui ce SDK m'oblige à ne pas libérer ce qui est problématique si je voulais libérer (inverse de la GPL donc, mais obligation aussi).

Après prouver que les gens qui font font du proprio c'est des méchants je m'en tape ; mais cette clause est bien merdique : essaient-ils de se protéger des concurrents ou des "pirates" ? Dans les 2 cas, je doute que ça fonctionne.

Il y a le SDK de Nintendo qui interdit de libérer le code l'utilisant (donc tu ne pourras pas libérer la couche spécifique à leur console, si tu en fais une).

Tu enfonces des portes ouvertes. Évidemment que l'argent a fait pencher le choix des patrons vers le logiciel libre. Moi je parlais de la libération du code ; des libristes qui seraient contents de propriétariser du code, c'est pas des libristes (je conçois que des libristes soient amenés à le faire hein, je dis que la propriétarisation en elle même ne les rend pas contents).

Encore une fois je n'essaie pas de te convaincre de faire de la GPL ; tu fais du BSD ça me va très bien.

On m'a raconté cette histoire en 2008 ou 2009, et ça fait depuis presque aussi longtemps que j'ai finit ma mission dans cette boîte, donc je ne pourrai pas avoir plus de détails sans gros efforts social de ma part (ce que je ne ferai pas).

Mais dans mon souvenir, les patrons n'ont pas été mis face au fait accompli (ce qui aurait été une erreur je suis entièrement d'accord), mon collègue leur a expliqué le choix avant :

• Développer depuis 0 pendant des mois/années.
• Modifier le soft GPL qui est très proche de leurs besoins, sachant qu'il n y a pas de soft BSD équivalent.

Mon anecdote n'a aucune valeur de preuve, c'est juste une anecdote.

Il ne faut pas oublier que la viralité de la GPL est ce qui a obligé des entreprises à collaborer avec le libre en leur donnant du code "gratuit", et parfois du très bon code pour des milliers d'heures.

J'ai une anecdote (sûrement pas un cas esseulé) qui va dans ce sens ; on présente souvent les entreprises comme ayant une pensée unique, mais au final elles sont composées de gens ayant des opinions variées, voire opposées.

Un collègue me racontait que dans son ancienne boîte qui faisait de l'électronique, il avait modifié un soft GPL pour le faire tourner sur leur hardware. Ses patrons étaient plutôt favorables à ne pas libérer le code dans l'absolu, mais ils ne tenaient pas à violer la licence, ni à tout réécrire depuis zéro ; le code a donc été libéré. Donc si le code avait été sous BSD il ne l'aurait pas été, mais là la GPL a servi de levier dans les mains des libristes.

Cela ne remet pas en cause la pertinence du propos de Zenitram, c'est juste qu'il y a plein de cas et de gens différents.

parts = base.split(".")
name, ext = parts[0], ".".join(parts[1:])

Cette partie de code est très moche. split() peut prendre un deuxième argument pour limiter le nombre de coupes:

>>> 'foobar.tar.gz'.split('.', 1)
['foobar', 'tar.gz']

Sinon y a aussi partition() qui est sympa.

Zenitram a bien résumé ma pensée, après le reste c'est un choix personnel. Il n'y a pas de bonne ou de mauvaise réponse, en revanche il y a sûrement des mauvaises solutions à des problèmes, et aussi des faux problèmes. Je m'explique.

Il n'est pas rare d'inclure plusieurs bibliothèques dans un même logiciel, ça peut donc devenir un casse tête (voire même un problème insoluble) quand lesdites bibliothèques imposent une licence au projet entier. A près la frontière entre logiciel et bibliothèque est poreuse bien évidemment (on peut prendre un bout d'un logiciel 'final' pour l'inclure dans un autre logiciel), mais il est claire qu'une bibliothèque n'a d"intérêt que si elle est est incluse par un logiciel.

À toi de voir si la peur de voir ton code inclus dans un logiciel propriétaire (mais la LGPL garantie que ton code lui reste libre [*]) dépasse ton envie de voir ton code inclus dans des logiciels libres. Après le coup de la méchante entreprise qui vient utiliser ton code génial pour faire un logiciel proprio et gagner des millions de dollarz c'est une phobie répandue, mais c'est plutôt infondé dans la réalité.

À toi de jouer :)

[*] mais comme ça a été débattu récemment ça ne garantie pas plus que la GPL une contribution upstream.

Pour ceux qui sont intéressés par Unicode et Python, j'ai découvert il y a quelques temps (mais le projet date de 2006) pyuca, qui permet de trier des chaînes unicode de manière correcte, c'est à dire avec la lettre 'é' avant la lettre 'f' par exemple. J'y ai aussi contribué afin de beaucoup réduire l'empreinte mémoire (ça pourrait faire l'objet d'un journal si des linuxfriens sont intéressés).

Sinon à propos de DChars, autant je suis assez pro-GPL, autant pour des bibliothèques je trouve la LGPL plus adaptée (mais bon ce n'est que mon avis).

Lire le code des autres est très formateur :

http://stackoverflow.com/questions/3269686/short-rot13-function

Il serait intéressant de pour toi de comparer le temps d'exécution de ta version avec ceux de ces versions. On y trouve des choses intéressantes en terme de concision et de performances (même si je serais incapable de dire laquelle est la plus rapide) :

• utilisation de fonctions dédiées (encode() et translate())
• utilisation de dictionnaires pour faire des recherches rapides, une fois construits (complexité algorithmique en O(1)). La méthode get() est souvent oubliée par les débutants qui vont faire un in (voire pire un has_key()) puis un [key], donc 2 recherches au lieu d'une.
• utilisation de join() plutôt que += pour concaténer les chaînes.

Sinon sur ton code en particulier, à part la boucle for qu'il faut revoir, j'aurais des petites trucs en plus :

• '' est plus rapide que str() (dans le 2ème cas l'interpréteur doit faire une recherche du symbole "str", qui peut être surchargé). La différence est évidemment infime, mais c'est toujours bon à savoir.
• 0 est plus rapide que int() (même raison).
• (je pourrais du coup dire la même chose de list() vs [] ou dict() vs {})
• res, tmp = str(), str() => c'est plus efficace (et plus lisible je trouve) de le faire en 2 lignes, car là l'interpréteur doit construire un tuple temporaire en plus et faire l'unpacking. L'unpacking c'est génial dans bien des cas mais pas là.

Amuses toi bien :)

L'obligation de spontanéité… :)

B fournit une version modifiée du logiciel à C. L'aspect héréditaire de la GPL fait que ce logiciel modifié est lui-même sous GPL (pour peu que B n'enfreigne pas la licence évidemment) : B doit dire à C quelle est la licence (GPL donc), et la GPL impose que B fournisse les sources à C si ce dernier les demande.

En revanche rien n'oblige B à fournir les sources aux auteurs originaux. Si le logiciel est destiné au grand public, ils finiront tôt tard par obtenir ces sources par la force des choses (un des nombreux utilisateurs finira par réclamer les sources), mais ça n'a rien à voir avec une quelconque obligation de la GPL.

Que le langage soit super, soit. Que tu sois très fan, pas de problème, on est sur un site de passionnés après tout.

Mais expliquer le peu d'applications finales par les qualités du langage, ça fait un peu fanboy quand même.

Tu sais, on peut être un gros barbu qui fait de la programmation système en C (sisi, avec des void* et des threads), aimer le libre/Linux/FreeBSD/…, et aimer quand même faire des trucs jolis. Allez je t'aide : les gens qui bossent par exemple sur Nouveau, Enlightenment, Blender…

C'est pas juste les kikoololeurs sous Ubuntu contre les vrais mecs sous LFS.

PS: si tu veux te la jouer élite, apprends à écrire un peu français tu seras plus crédible.

Pourquoi, pourquoi des graphistes ne s'impliquent-ils pas dans des projets libres

Les contributeurs (code ou graphismes, ou bien mods) sont avant tout des utilisateurs convaincus. Les créateurs de Counter Strike ont sûrement joué des heures à Half Life avant de le modder. Mais la plupart des utilisateurs restent de simples utilisateurs.

Alors quand comme Half Life ont a des millions de joueurs, la minorité de personnes qui font du mod représente une force de frappe importante. Mais quand on est un petit jeu (libre ou pas), ce n'est pas le cas. Tu te focalises sur quelques jeux propriétaires qui ont eu un énorme succès, en oubliant les dizaines de jeux proprio sortant chaque mois, qui vont peut-être même faire vivre leurs créateurs, mais sans que personne n'essaie jamais de les modder. Rien d'étonnant que même les meilleurs jeux libres, qui sont au final connus par très peu de personnes, n'attirent pas les contributeurs.

Au final c'est un pareil que les communautés dans le logiciel libre classique : quelques gros projets reçoivent beaucoup de contributions, quand des tas d'autres n'en reçoivent aucune ou presque. Si les créateurs originaux n'arrivent pas, seuls, à développer un logiciel déjà très attractif, ils n'auront pas de contributions significatives (croire qu'il suffit de libérer pour que le logiciel se fasse 'tout seul' est un mythe).

Après c'est plus un débat sur le vocabulaire qu'autre chose, mais si demain tu donnes 30€ à un projet de jeu libre sur KickStarter/Ulule/… afin que le jeu puisse être développé, et que tu reçois en échange des stickers (d'une valeur de 1€), peut-on considérer que tu as acheté le jeu (tu as payé avant d'avoir testé) ? ou on ne peut parler que de l'avoir financé, ou d'avoir fait un don ? (ou bien d'avoir payé très cher des stickers :) )
[c'est une vraie question]

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.

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.

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.

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.

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.

Il existe quand même une question beaucoup plus compliquée, à laquelle je n'ai jamais vu de réponse convainquante : «quel est votre intérêt à améliorer la documentation et à faciliter l'installation et la gestion de l'application étant donné que le business model repose sur le support?»

Je ne sais pas si ma réponse va te convaincre, mais je vais essayer quand même. Je pense (et c'est d'autant plus vrai que la boîte est petite) qu'avoir plein de gens qui installent ton application, même s'ils n'achètent rien au final, ne peut être que bénéfique. Cela va faire une super publicité (si l'application est bonne hein !), donner une vraie crédibilité (quand on est petit c'est difficile d'avoir l'air solide face aux gros), voire ramener des contributions. En fait j'ai envie de faire le parallèle avec ce lien : http://www.pcinpact.com/news/75567-une-etude-pointe-effets-negatifs-fermeture-megaupload.htm
Je résume : il semblerait que les petits films, avec peu de budget publicité, bénéficiaient énormément du bouche à oreille créé par MegaUpload (la fermeture de ce dernier aurait eu un impact négatif sur ces films).

N'est-ce pas une limite à l'amélioration du logiciel?

Dans la pratique, quand on a comme concurrent des grosses boîtes bien installées, que leurs logiciels sont des références que les DSI choisissent pour ne pas prendre de risque, je ne pense vraiment pas que faire une application qui-ne-soit-pas-trop-bien soit vraiment une bonne idée. En plus une application professionnelle sera toujours complexe, et des tas d'améliorations seront toujours possibles, donc aucune chance qu'elle soit finie et parfaite.