GuieA_7 a écrit 689 commentaires

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.

OK merci pour ta réponse ; c'est bien de voir que d'autres architectures sont envisagées, malgré l'omniprésence du x86 sur les ordinateurs de joueurs, là tout de suite.

Le JIT expérimental (JitIL) était effectivement une tentative de rendre le code recompilé plus rapide en passant par une layer intermédiare : au lieu de faire PPC -> X86 directement, on fait PPC -> IL -> X86, avec potentiellement des passes d'optimisation sur l'IL

Passer par un IL permettrait à terme de supporter plus facilement d'autres architecture processeur j'imagine. Après, ça ne fait peut être pas partie des priorités du projet (avec la montée des ARM au niveau du grand public ça le deviendra peut-être).

En tout cas merci pour toutes ces belles informations, c'est toujours un plaisir d'avoir un retour de développeur.

Toutafé, c'était un abus de langage de ma part. Pour aller plus loin, on peut même dire que pour monter une boîte, une bande de parfaits incompétents (en technique comme en gestion) suffit ; la faire vivre et prospérer (honnêtement en tout cas) sera plus difficile.

Après niveau compétences c'est totalement indépendant de la formation, surtout a Epitech !

C'est partout pareil, ça n'a rien de spécifique à Epitech. J'ai moi aussi des anecdotes de gens en fin de 3ème année incapables de faire une struct en C ou copiant sans vergogne (ni finesse) le code d'autres élèves, quand d'autres montent leur boite à la sortie de l'école.

C'est ma définition, elle vaut ce qu'elle vaut, mais pour moi un code propre est un code dépourvu de ce genre d'horreur :

• des noms de variable/fonction/classe incongrus.
• des fonctions de 5000 lignes avec 40 niveaux de profondeurs, des gotos utilisés n'importe comment, des tonnes de variables globales.
• du copié/collé à tout va.
• pas de style de programmation respecté : une mauvaise indentation, des conventions de nommage à géométrie variable, etc…
• et toute une infinité de cochonneries qu'on pourrait inventer.

N'importe codeur rigoureux et consciencieux peut donc faire du code propre. Mais ledit code peut quand même avoir une mauvaise conception, être lourd et inefficace etc…, et donc être mauvais.

"set([])" peut être écrit simplement "set()". En fait, pour aller plus loin :

[...]
  subjects = set([])
  g = Graph()
  g.parse(rdf, format=fmt)
  for subject in g.subjects() :
    subjects.add(subject)

  for subject in sorted(subjects) :
  [...]

pourrait être plus court:

[...]
  g = Graph()
  g.parse(rdf, format=fmt)

  for subject in sorted(set(g.subjects())) :
  [...]

OK, merci pour ta réponse ; je comprends mieux et je suis bien d'accord (vu mon activité ça semble évident).

tu fais passer le message "un éditeur ne peut pas faire de libre"

Désolé si je n'ai pas été clair, mais en me présentant comme un éditeur de logiciel libre, je ne pensais pas que c'est le message qui passerait.

tu as sans doute loupé http://linuxfr.org/news/lisez-en-liberte-avec-teabook-open-reader

En effet, malgré mon assiduité sur LinuxFr je n'avais pas lu cette intéressante dépêche. Mais sauf si j'ai loupé un truc :
- le modèle de TEA est un subtile mélange de mes points 1 & 3 (et c'est bien), ce qui ne remet pas en cause en ma conception du business autour du libre.
- l'expression "à licence" n'était pas très claire ; avec le recul j'imagine que ça s'opposait juste à "logiciel développé pour un client et auquel on cède le copyright". Désolé si tout le monde avait compris ça sauf moi.

Je remets la citation initiale

Mais vraiment éditeur de logiciel, sous licence, acheté par d'autres.

Alors j'ai peut-être mal interprété le "sous licence" (qui ne veut pas dire grand chose au final), mais je l'ai interprété comme "licence payante". Et je n'ai peut être pas saisi ce que tu voulais dire, mais j'ai l'impression que tu dis la même chose que moi. Dans tes exemples, je vois des boites qui gagnent de l'argent grâce :

1. aux services autour de leur produit (services payants, pas la licence).
2. à la vente de versions propriétaires bâties au dessus de leur version libre (d'où ma remarque sur un produit pas entièrement libre, c'est bien le propriétaire qui rapporte de l'argent au final)
3. à leur activité principale, pas lié à ce logiciel, mais qui est libéré gracieusement (ce qui est très bien hein).

Donc CrEv n'a l'air de parler ni de 1 ni de 3, et 2 n'est pas entièrement libre, ce que je disais.

Mais vraiment éditeur de logiciel, sous licence, acheté par d'autres.

Dommage que ton modèle soit incompatible avec la création de logiciels libres (ou du moins entièrement libres, certaines briques pourraient l'être). J'ai cela dit déjà entendu parlé de boites faisant des logiciels libres, mais qu'elles ne distribuaient (et donc leurs sources) qu'à leurs clients ; ce système ne marche qu'avec des logiciel de niche je dirais. En tout cas c'est assez éloigné de ma vision idéale de diffusion de la connaissance ; après ce n'est pas le but de tous les libristes, j'en suis conscient.

En tant qu'éditeur de logiciel libre, je pense arriver à combiner:
- une vison produit 'originale', pas une commande bizarre de la part d'un seul client (même si cette vision est amené a évoluée en fonction des retours des utilisateurs, heureusement).
- du service (développement, formation, déploiement, hébergement, conseil…), rémunérateur.

Je suis même régulièrement amené à sortir du cadre de l'informatique pure, genre préparation d'un stand sur un salon (banderole, goodies …) ; ça ne fait pas de moi un meilleur programmeur mais c'est intéressant aussi (pour aller dans ton sens de l'ouverture d'esprit).

Coté univers et aspect graphique, le coté retro de Nikki me touche et me plaît beaucoup, je me doute que ça ne fonctionne pas pour tout le monde, mais moi j'aime bien le retro/pixelisé/8bit assumé.

J'ai des goûts éclectiques (même si j'ai un faible pour la 3D "cell shadée"), et les graphismes rétro savent toucher le vieux joueur que je suis : SuperMeatBoy, Fez, JamesTown, Megaman 9… J'avais bien aimé Frogatto, dont le moteur est libre (je crois qu'il y a un éditeur aussi).

D'ailleurs je n'ai pas critiqué les graphismes de Nikki. Le sprite du personnage est sympa en effet ; après la direction artistique n'est pas bien profonde non plus.