GuieA_7 a écrit 689 commentaires

Heu c'est normal d'avoir 50 après 15 (alors que les autres constantes vont en décroissant) ?

PS: en tant que développeur python, j'aurai créé un alias du genre "diff = self.f.score - self.old_score", histoire de gagner en lisibilité et en performance.

Ok alors toutes mes excuses ; le C est conservateur, pas le Fortran (les conservateurs ce sont les pappies qui s'accrochent à leur f77 :) )

Un bémol cependant : il me semble que des fonctionnalités obligatoires du C99 vont devenir optionnelles dans la version suivante (genre les nombres complexes). Si c'est le cas, un code C99 (utilisant ces fonctionnalités) ne passera pas forcément sur un compilateur C11.

Ça a déjà été galère quand j'ai mis à jour ma machine de 2.5 vers 2.7 (je ne connais que très très peu python)

Je souhaite bon courage aux pythonistes pour maintenir leur code à chaque évolution de leur langage.

Il n'y a pas à toucher un programme qui tourne en 2.5 pour qu'il tourne en 2.7 : la cassure est avec la branche 3, les versions d'une même version ont bien heureusement la compatibilité ascendante.

Personne n'a envie de réécrire des millions de lignes de code en f77 qui fonctionnent bien et ont été méticuleusement testées sur au moins vingt ans, et tout le monde veut bien les utiliser.

C'est bien ce que je dis, il y au moins une personne qui passe son temps libre, ou bien qui est payée, pour maintenir f77 dans GCC. Si demain ce n'est plus le cas, et que tu es le dernier utilisateur, tu devras aussi te garder sous le coude la dernière distribution gérant f77, et utiliser une machine virtuelle par exemple.

Si ces projets ne sont pas activement maintenus (les étudiants finissent leur thèse puis passent à autre chose), il sera impossible de les exécuter quelques années après l'abandon de python2. Ou alors avec un vieux livecd de 2012, s'ils démarrent encore sur les ordinateurs de demain.

Je ne sais pas quand le support de Python2.7 sera perdu dans la pratique ; si des tas de gens sont prêts à payer pour qu'il soit maintenu (plutôt que passer les 2h à modifier leur programme) ça peut être dans longtemps (de base le projet Python a tablé sur 5 ans, mais dans les distributions comme Debian ça devrait être là plus longtemps). Mais effectivement, si en 2025 tu es vraiment intéressé pour faire tourner le code de tes thésards de 2010, tu devras peut être te garder une Debian de 2024 + Machine Virtuelle, c'est bien triste pour toi. Quelque chose me dit que si personne n'est motivé pour passer quelques heures sur ces programmes d'ici 15 ans, c'est qu'ils ne doivent pas être si utiles que ça... Je peux comprendre cependant que tu sois déçu.

Mes scripts perl qui ont 10 ans sans maintenance dans /usr/local/bin

Pareil que f77 (quelqu'un fait la maintenance).

Tout cela est une histoire d'offre et de demande en quelque sorte. Une communauté peut se former pour faire Python2.8, Python2.9 etc.. qui ne cassent pas la compatibilité. Si ça ne se fait pas, c'est que les "conservateurs" ne sont pas prêts à payer, simplement.

Je ne dis pas que l'approche de Python ("progressiste") est mieux que l'approche Fortran ("conservatrice"); les 2 ont leurs avantages et leurs inconvénients. L'approche des langages n'est que le reflet de leur communauté ; il faut croire que la communauté Python préfère corriger les petites erreurs (je le répète, elles sont petites), plutôt que de pénaliser les futures implémentations. Je préfère l'approche Python, sans nier qu'elle a aussi des inconvénients ; tous les choix techniques sont des compromis, je l'ai déjà dit.

En ce qui me concerne faire évoluer mes programmes n'est pas une contrainte mais une véritable philosophie (et même un grand plaisir).

Cette notion que casser des programmes qui marchent, c'est toujours "les améliorer" me fatigue. Un programme qui a été développé, qui marche bien, qui est en prod depuis plusieurs années, pourquoi devrait-il être modifié ?

Je ne force personne à changer son code (enfin sauf mes collègues ! :) ). Ceci dit, je pense que dans l'ensemble, en informatique, on souffre beaucoup plus du pattern "ah oui ce truc a été écrit par Jean-Louis y a 15 ans, personne ne sait ce que ça fait exactement alors on y touche pas" que gens qui aiment réécrire leur code en mieux.

Ça ne veut pas dire qu'ils faillent tout refaire depuis zéro tous les 3 mois ; mais dans le cas présent passer 2 jours en 10 ans, ça me paraît acceptable. Tous les choix techniques sont des compromis, et en tant que Pythoniste je suis content que cela soit cette voie qui soit prise (plutôt que l'immobilisme de Java par exemple).

De toutes les façons, il ne faut pas rêver, un système informatique nécessite de la maintenance, l'immortalité n'est pas de ce monde. Si il veut recompiler son programme Fortran77 avec le dernier GCC et bénéficier des dernières optimisations, il faut que des gens aient porté Fortran77 avec la dernière infrastructure de GCC. S'il veut juste tourner sur le dernier Linux sans recompiler son programme, il faut que les développeurs Linux fassent attention à ne pas casser l'ABI. Si il ne veut rien changer du tout au soft, et compte faire tourner la bécane telle quelle pendant 30 ans, il lui faudra quand même prévoir des pièces de rechange, car le hardware ça vieillit.

Mais si un jour plus personne n'est prêt à payer (en temps ou en argent peu importe) pour que Fortran77 soit maintenu dans GCC, et bien le support sera jeté, c'est comme ça. Mais croire que ne rien toucher suffira pour que ça continue à marcher comme avant, alors que le coeur de GCC aurait été réécrit pour bénéficier des dernières avancées en terme de compilation, c'est se mettre le doigt dans l'oeil. On ne peut pas avoir le beurre et l'argent du beurre.

Pour l'instant la communauté Fortran77 est sûrement assez active, peut-être même que des tas de gens sont prêts à payer pour ne pas avoir à changer leur vieux code. Mais au final il y a forcément des gens qui payent cette maintenance. Et comme c'est du libre, on peut en profiter sans avoir soi-même payer quoi que soit ; mais rien de magique la dedans.

En fait nous sommes d'accord je pense, je voulais juste tempérer tes propos. Parce que la phrase "le compilateur n'a qu'a optimiser", je l'ai souvent entendu prononcée par des mauvais codeurs, qui pondent 100 lignes de code toutes pourries, là où 10 lignes simples suffisaient (mais fallait utiliser sa tête).

D'ailleurs, quand on réécrit du code en 4 fois de lignes, en ayant la volonté première d'avoir un code plus simple, lisible et maintenable, mais qu'en bonus le code devient plus rapide, est-ce de l'optimisation ?

ça sous-entend déjà qu'ils pourraient décider d'arrêter et ça rassure pas du tout pour la pérennité de l'éventuel code que je pourrais écrire si je m'y mettais.

Ce n'est pas un sous entendu : le destin de la branche 2 est de mourir, remplacée par la branche 3 (encore une fois les différences sont minimes et valent le coup à mon avis). Donc effectivement, si ta façon de bosser est d'écrire du code, et de ne plus y toucher pendant 30 ans, alors non le Python n'est pas pour toi. Mon post n'avait pas pour but de faire la promotion de Python, il a déjà une active communauté (que d'autre bons langages n'ont pas).

Il faut bien voir qu'une nouvelle version de Python sort en moyenne tous les 2 ans, avec à chaque fois des fonctionnalités bien vues, qui vont permettre d'améliorer lentement mais sûrement les applications. Passer de Fortran77 a Fortran90, ça serait comme passer de Python1.0 à Python3.0, ce que personne ne fait, ne serait-ce que parce que personne n'utilise plus la branche 1, et les premières versions de la branche 2 ne doivent plus l'être non plus. Si il y avait eu Fortran79, Fortran81, etc... avec à chaque fois tous les compilateurs mis à jour en même temps, des fonctionnalités alléchantes mais qui permettent une évolution progressive, peut-être que ton code Fortran77 aurait été amené en douceur vers Fortran90, pour un code plus simple et maintenable (peut être même plus efficace, je ne connais pas Fortran).

Je pratique (ou ai pratiqué) le C++ et le Python à titre personnel comme à titre professionnel, et ce sont 2 langages que j'affectionne beaucoup.

Je vais répondre à la pique sur Python. Tu penses que la cassure Python2/Python3 est une erreur, et tu as raison dans la mesure où, si cette politique était appliquée au C++, cela provoquerait une catastrophe. Mais les situations de Python et de C++ sont très différentes, et donc ce qui est bon pour l'un ne l'est pas forcément pour l'autre. Je m'explique.
Le Python a une implémentation de référence (CPython), qui est utilisée par 99% des gens. On peut trouver ça dommage. Mais bon cette implémentation est libre, gratuite, multiplateforme, plutôt performante, ce qui fait que globalement on n'a pas trop à se plaindre.

• Du coup quand une nouvelle version sort, on peut si on le veut utiliser les nouvelles fonctionnalités tout de suite, pas la peine de se demander quand est-ce que la majorité des implémentation auront un support suffisant (par exemple la gestion catastrophique des templates par VC++6), ou bien de faire plusieurs version du même code suivant le compilateur (avec de la compilation conditionnelle). Pas non plus de fonctionnalité dans le standard mais implémentée par personne ('import' du C++).
• La branche 2 sera maintenue par l'équipe Python pendant des années ; en plus les dernières versions de cette branche (2.6, 2.7) se sont beaucoup rapprochées de la branche 3. Au final l'effort à fournir est minime (et il existe un outil officiel qui fait la conversion) et on a des années pour faire ce petit effort. À côté de ça, dans la pratique, malgré la non cassure du monde C++, si tu trouves un vieux projet C++ qui a traîné des années sans avoir bougé, pas sûr qu'il compilera sans problème, pour peu qu'il s'appui sur d'autres bibliothèques qui elles auront évolué. De toutes les manières un code non maintenu finit par mourir.
• Il y a évidemment bien moins de logiciel en Python qu'en C++, et leur code est sûrement bien plus petit (c'est bête mais pragmatique).

Je vis en faisant du Python (c'est donc un peu plus qu'un simple amusement sans conséquence), et le passage à Python3 ne m'effraie du tout, j'ai même hâte de le faire.
Les langage C++ et Python évoluent de manière différente, mais à mon avis les 2 le font assez bien (même si je suis assez déçu de la dernière version de C++).

(En même temps, c'est un faux argument, ce n'est pas à l'humain de faire les optimisations mais au compilateur.)

C'est un peu plus compliqué que ça malheureusement. Même dans les langages fonctionnels, il est par exemple conseillé de faire des récursions terminales, histoire d'utiliser efficacement la pile. Or la version avec récursion terminale est souvent un peu moins jolie que la version naïve.
Peut être que des compilateurs sont capable de faire cette transformation tout seuls cela dit (je ne suis pas un spécialiste), mais je pense que le programmeur aura toujours une part de responsabilité dans l'optimisation.

Malgré les qualités intrinsèque de FireFox (et plus récemment de Chrome), il est clair qu'il a percé aussi parce que IE6, pourtant installé de base sur 90% des machines de bureau, est une vraie bouse. Je pense qu'en limitant la casse (en laissant une poignée ingénieurs sur le projet) afin de le rendre juste assez médiocre pour que la fuite des utilisateurs soit faible, IE serait encore en quasi monopole. Et du coup Bing serait sûrement bien moins à la traîne.
En somme pour économiser quelques dollars, ils ont craché à la figure de millions d'utilisateurs, et maintenant des milliards leur passent sous le nez. Ahah, bien fait !

peut t'on comparer l'équipe gambas ... a celle d python ... elle est égale a celle de python après ses 10 premières années ...

C'était une boutade hein, je me doute que l'équipe de Gambas est petite et a mieux à faire. Ceci dit le typage statique de Gambas faciliterait peut-être la compilation, comparé à des langages comme JavaScript ou Python (mais ça reste un gros travail).

On est systématiquement mis au défit et comparé aux gros du moment.

Ah ben ça c'est tout à fait normal. Du moment que tu dis aux gens d'utiliser ton logiciel, ils vont forcément se demander pourquoi le tien et pas un autre. C'est d'autant plus vrai pour un langage de programmation : il est assez facile de changer de navigateur Web ou de lecteur multimédia, mais quand on se lie à un langage cela a plus de conséquences. Ce n'est pas pour rien qu'il y a des tas de langages (libres) de qualité avec une faible communauté.

Comme le disait Benoit, l'important c'est la maitrise de l'outil, sa compréhention, son adaptabilité. C'est a ce jeu que gambas est bon.
Ce qui est bon aussi, c'est l'ide, pas forcément révolutionnaire mais de plus en plus complète et j'oserais a ce titre dire unique dans le monde du libre.

Il faudrait peut-être rentrer plus dans les détails sur ces qualités (être "vendeur", ce n'est pas péjoratif).

• En quoi un utilisateur de Gambas maîtrise plus Gambas q'un utilisateur Python maîtrise Python ?
• Qu'entends-tu par "adaptabilité" par exemple ? Tu parles de modifier l'interpréteur lui-même ?
• Pour l'IDE, quelles sont ces qualités par rapport à QtDesigner (pour ne citer que la référence libre) ?

Pour ce qui est de la vitesse d'excution, a l'affichage en gui on attend moins un programme gb qu'un py. Voila un ressenti :-)

Pour avoir fait du python embarqué temps réel, je dirais que la façon de coder importe plus que le langage. Par exemple un langage rapide ne dispense pas de jouer avec l’asynchronisme pour rendre une application vraiment réactive.

... mais on aime ça! :)

Je me suis amusé avec le premier benchmark, dont voici le code original :

#!/usr/bin/python

n = 500000
x = 0.2

def t(x):
    mu = 10.0
    pu = 0.0
    pol = [0] * 100
    r = range(0,100)

    for i in range(0,n):
        for j in r:
            pol[j] = mu = (mu + 2.0) / 2.0
        su = 0.0
        for j in r:
            su = x * su + pol[j]
        pu = pu + su
    return pu

for i in range(0,10):
  print t(x)

J'ai fait de très mineures modifications histoire que ça soit plus pythonique :

#!/usr/bin/python

n = 500000
x = 0.2

def t(x):
    mu = 10.0
    pu = 0.0
    pol = [0] * 100
    r = range(0, 100)

    for i in xrange(0, n): #Ici xrange pour pas allouer une grosse liste pour rien
        for j in r:
            pol[j] = mu = (mu + 2.0) / 2.0

        su = 0.0
        
        for val in pol: #ici j'itère sur la liste histoire de ne pas passer inutilement par un indice
            su = x * su + val

        pu += su # += pour faire bô

    return pu

for i in range(0, 10):
    print t(x)

Je passe sur ma machine de 231.824s à 209.599s, soit presque 10% de gain. Gambas reste donc bien plus rapide, ce qui montre bien que le typage statique permet des optimisations intéressantes, même avec un simple interpréteur.

Puis j'ai rajouté ceci après le shebang:

try:
    import psyco
    psyco.full()
except ImportError:
    print 'No "psyco" module'

Et (après avoir installé Psyco !) le code s'exécute en 84.306s, soit presque 3 fois plus rapidement. Évidemment Psyco c'est que x86 et plus trop maintenu, mais ça donne une idée de ce qu'on va avoir avec PyPy qui est annoncé comme 5 fois plus rapide que CPython.

L'équipe de Gambas relèvera-t-elle le défi en implémentant du JIT (le suspens est à son comble) ?? :)

J'en profite au passage pour féliciter ladite équipe pour son travail.

Comme le dit Zenitram au dessus, tu oppose libre et commercial, mais ce sont 2 concept orthogonaux. La double licence TrollTech, c'était libre vs propriétaire. Du moment que tu fais du libre, tu n'empêche pas les concurrents de faire du commercial ; tu peux juste les empêcher de faire du propriétaire (licences *GPL), mais même pas les obliger à contribuer avec toi.

Encore une fois la protection du code, pour nous qui vendons du service, n'est pas une problématique. Les mauvais payeurs sont un problème par exemple, pas les "voleurs" de code.

Mais admettons que tu n'aies pas fait la confusion propriétaire/commercial ; il est clair que TrollTech était confronté à un problème de business model dans le libre : ils pouvaient difficilement vendre du service autour de Qt. Ils en vendaient (support etc...), mais leurs utilisateurs sont des techniciens et n'en pas souvent besoin. Et c'est encore plus un problème dans le cas de produit pour le grand public ; il est clair qu'on ne peut transposer le modèle propriétaire classique dans le monde du libre, et c'est bien embêtant. Les réponses changent donc en fonction du type de logiciel ; mais encore une fois, pour beaucoup la "non-protection" n'est pas gênante.

Oui la question est intéressante. Une première réponse et après au dodo.

• Faire du libre est déjà pour nous une démarche militante. Ce n'est pas une volonté issue d'une étude de marché pointue qui nous aurait démontré que dans notre cas c'est plus rémunérateur ; évidemment il n'est pas question non plus de partir au casse-pipe. Mais avant nous faisions de l'intégration VTiger (un autre CRM libre), et on a bien vu que sur ce marché très concurrentiel, en travaillant sérieusement nous arrivions à gagner notre vie.

• La concurrence est déjà rude, et les CRM libres s'en sortent plutôt bien ; ça ne ferait qu'un concurrent de plus au final.

• Pour le moment en tout cas, le fait que notre boite soit jeune et petite est le plus gros problème pour lutter face aux gros ; le fait de faire du proprio n'y changerait pas forcément grand chose (c'est discutable toutefois, car on aurait du coup peut-être accepté des financements qu'on refuse justement pour pouvoir garder le contrôle et rester libres). Du coup que des gens utilisent notre soft serait plutôt synonyme de publicité.

• On a écrit la moindre des lignes de Creme, alors quand il faut le customiser nous sommes efficaces forcément. Si nous n'arrivons pas à nous démarquer face à un concurrent faisant du Creme "sauvage" c'est que nous devons nous améliorer (mais oui c'est plus rude que de vivre de rentes comme avec le proprio).

Au final je dirais que ce problème d'auto concurrence est un peu une chimère, mais c'est vrai c'est LA question que nous posent les gens habitués au monde propriétaire. À part nous empêcher un jour d'ériger un monopole (ce qui est une bonne chose, ils ne sont pas souhaitables), ça n'est pas un gros problème.

Le jeu vidéo n'a jamais été notre activité (un jour peut être...), juste une occupation pendant le temps libre (entre 2 contrats par exemple) pour certains d'entre nous. Ça continue donc doucement en tâche de fond.
Mais tu le saurais si tu avais levé le nez de ton clavier à faire du Haskell, parce qu'on faisait du CRM depuis longtemps quand tu étais là.
Ahlala ces jeunes....

Je l'ai évoqué dans mes réponses parce que c'est en effet une leçon à retenir, et que ça explique les dates (création en 2005, mais Creme n'a débuté qu'en 2008-2009). Pour être franc j'ai essayé d'être synthétique pour ne pas pondre des réponses exagérément longues, et éventuellement compléter dans les commentaires si les gens sont vraiment intéressés par la question.

Il y aurait surement des tas d'anecdotes porteuses de leçons à raconter ; par exemple il est amusant de noter que durant ce projet je m'étais mis à Blender, et au Python pour le scripter, et que bien plus tard cette expérience m'a fait briller en entretien, et que j'ai même "contaminé" mes collègues (puisque Creme est en Python).

Quand ils font référence à la grosse quantité de R&D qu'ils ont fait, je suppose qu'ils parlent d'un gros truc de 3D qui était impressionnant à l'époque, mais qu'ils n'ont pas vendu (?).

Qu'on a pas amené à un niveau vendable surtout. Mais je ne suis pas rentré dans les détails pour cette partie parce que ça n'a pas grand intérêt avec le sujet.

N'hésitez pas à me corriger si j'ai réécrit l'histoire

Non c'est tout à fait ça.

Si en 2004 on leur avait dit qu'ils éditeraient un jour un logiciel de Relation Client, je pense qu'ils auraient bien rigolé :)

Sûrement ; mais en ce qui me concerne j'ai pensé assez tôt qu'on trouverait notre voie au détours du chemin sans savoir ce qu'elle serait. En revanche la plupart de nos camarades pensaient qu'on allait crever rapidement et renier nos idéaux, et là c'est nous qui leur donnons tort !

C'est pas très "logiciel libre" de dire que la licence importe peu tant que le logiciel et les services associés sont de qualité [...]

Je pense qu'au fond on est d'accord, et je vais faire de la rhétorique plus qu'autre chose, mais dans un contexte d'entreprise, je dirais: au contraire.
En effet, vu qu'on gagnerai tout autant en faisant du proprio (ou peut être moins ou peut être beaucoup plus, mais c'est difficile à dire sans machine à remonter le temps), faire du libre dans ses conditions témoigne d'une réelle envie militante.

A contrario, lorsqu'une grosse boite faisant habituellement du proprio, se met à faire de l'"Aupenne Source" car elle répond à un appel d'offre l'exigeant, le côté militant est beaucoup moins évident ! Je serai content lorsque tous les clients auront ce genre d'exigences, mais ce n'est pas pour tout de suite, alors il est important que les gens croyant au libre proposent des solutions de qualité dès maintenant.

Même si mes clients se fichent d'être libres, tant pis ils le seront quand même !

Certains clients ont quand même des données "sensibles" (top secret et compagnie), et pour cela s'héberger en interne, en faisant attention aux connexions venant de l'extérieur, a du sens. Mais c'est vrai que même dans les entreprises ayant un service informatique, ce dernier est souvent très occupé et bien content de ne pas gérer un logiciel de plus.

Ne confondrais tu pas un CRM avec un CMS ?

Mail parti.

PS: c'était sympa les messages privés du vieux DLFP ; j'espère qu'ils reviendront un jour.

MrJmad et moi-même (ainsi que 2 autres associés) avons monté une boite à la sortie de l'école, il y a 6 ans. Nous y développons notamment ce logiciel, tout ce qui a de plus libre. On a des utilisateurs et on en vit, mais après on ne peut pas dire qu'on ait une communauté, pour le moment en tout cas. Si ça vous intéresse malgré tout, on répondra avec plaisir.

J'ai pas mal utilisé E16 il y a une dizaine d'années, et j'en garde un très bon souvenir ; je me rappelle aussi d'un Linux Mag qui annonçait la sortie très prochaine de E17. Dix ans plus tard on comprend bien que ce n'est pas encore pour tout de suite malheureusement...

Ton commentaire est riche d'informations, mais certains points me font tiquer.

• Tu comptes sur Intel, mais après Meego, LiMo et compagnie, on attend encore quelque chose de substantielle venant de chez eux. Pendant ce temps, bonne ou mauvaise chose, Android cartonne.
• Tu reproches aux développeurs d'applications leur manque d'audace. Mais bon à force de casser les bases tous les 2 mois depuis 10 ans, il ne faut pas s'étonner que les dev abandonnent bien vite. Je comprends le côté perfectionniste ; je suis pareil mais vu que je vis de mon application, et bien j'ai du faire des concessions sur ce point, et poser des échéances. Au final c'est sympa aussi.
• Les artistes ne risquent pas d'arriver en masse sur un projet aussi underground, il ne faut pas rêver. Étant plus ou moins graphiste, je dirais que faire des graphismes qui ne seront vus que par les 3 geeks qui téléchargeront la version SVN d'une application qui ne marchera plus dans 6 mois n'est pas très motivant. Au contraire, un truc comme MineCraft par exemple, avec ses toutes ses imperfections, mais qui marche là maintenant, s'est construit une jolie communauté, et voit l'apparition de pleins de créateurs en herbe (c'est le 1er exemple qui m'est passé par l'esprit, allez savoir pourquoi...).

Je ne sais pas pour la 3D, mais en 2D, si tu regardes bien, beaucoup de jeux libres reprennent des images issues d'OpenGameArt.

Y a-t-il dans le lots des jeux "aboutis" ? J'entends par là des jeux auxquels par exemple des gens se foutant du libre et qui s'y connaissent un minimum en jeux joueraient (pour peu qu'on leur montre). Ce n'est pas tant que l'avis des non libristes m'intéresse spécialement, mais ça permet d'avoir un avis purement technique ; tous ceux qui utilisent Firefox ne sont pas des libristes, et c'est parce que Firefox est tout simplement bon. Je dis ça sans méchanceté aucune ; j'ai moi même commencé un jeuavec un pote depuis des années, et je sais bien que personne ne s'y amusera avant longtemps (mis à a part nous à le faire !), parce que c'est long et difficile de garder la motivation. Je pense à des jeux de la qualité de Wesnoth ou Hedgewars par exemple.

On est loin de l'animation de sprite là :-) Mais sinon il ya SVG pour ça

Si tu as regardé mon lien tu as pu voir que j'adore le SVG (il n'y a pas beaucoup de tarés qui font leurs textures en SVG !); je travaille souvent en vectoriel même si le travail final doit être du bitmap (je dois être le seul à fournir ses sources SVG pour ses contributions à Hedgewars malheureusement). Je ne suis pas sûr qu'on puisse faire tout un jeu (un "vrai") rien qu'avec du SVG ; mais dans la pratique si je pouvais avoir les animations dans Inkscape ça serait déjà bien, parce que je les attends depuis longtemps !

Il existe aussi des outils de création de jeux complets comme Game Editor.

Je ne connaissais pas ça a l'air sympa merci.

Ok avec l'explication je comprends un mieux ta frustration. Ton commentaire m’inspire plusieurs réflexions :

• Je n'ai évidemment jamais dit que "ma" technique était la panacée. Ce n'est qu'un hack, mais parfois je pense qu'il faut être pragmatique et accepter de faire un hack en 3 minutes mais qui marche plutôt bien, même si le perfectionniste qui est en nous en prend un coup !

• Le format MNG me semblait pas trop mal (je ne le connais pas bien cependant), mais on ne peut pas dire qu'il soit très connu ou populaire.

• Avoir un outil d'animation commun serait évidemment très bien. Après, la création d'un jeu restera beaucoup de boulot et ce n'est que la partie émergée de l'iceberg. Un outil de création entièrement intégré (comme pour Flash) serait encore bien mieux ; et même la il y aurait toujours de quoi faire mieux etc... Tout ça pour dire que que n'est qu'un minuscule problème à mon avis (ce qui ne veut pas dire que ça ne vaut pas la peine de se pencher dessus hein).

• Malgré tout le respect que je peux avoir pour OpenGameArt, je crois malheureusement que pour les graphismes ce genre d'initiative n'est pas très efficace (mais j'espère me tromper) . Pour les sons ça marche bien, car primo depuis qu'on sait faire du son qualité CD on n'a plus vraiment de gros progrès technique à faire, deuxio même si avoir un set sonore spécifique est préférable, avec un set "réaliste" et un set "cartoon" génériques doit sûrement couvrir beaucoup de besoins. Mais pour les graphismes, la réutilisabilité est vraiment faible au final : si je cherche des modèles 3D très détaillés pour de l'heroic fantasy, des modèles 3D lowpoly de SF ou des sprites en 3D isométriques d'heroic fantasy ne me sont pas utiles du tout. Je ne connais pas de jeu libre vraiment abouti utilisant OpenGameArt.

• Une idée à la con : quelqu'un qui poste une image animée sur OpenGameArt, et qui a donc conscience du manque d'information de timing, pourrait toujours l'indiquer dans le nom du fichier, genre hero__100ms.png (il faut que le timing soit toujours le même entre les frames, mais c'est bien souvent le cas).

Désolé si je t'ennuie, je peux être loquace sur des sujets qui me passionnent. Bonne journée :)