GuieA_7 a écrit 675 commentaires

Elle est rapide cette dépêche ; j'ai découvert le jeu ce matin sur le bien connu http://happypenguin.org/ et me suis empressé de le compiler et le tester. Je pensais faire un journal pour dire tout le bien que j'en pense : pour le coup je me suis bien fait griller !!
Le jeu est vraiment bien fait (très pro - mais vu la qualité de Wesnoth on comprend mieux). Ça rappelle vraiment les grands moments de la SuperNes/Megadrive : une véritable ode aux gros pixels qui tâchent ! Le jeu n'est pas hyper original mais il est vraiment efficace.
Je n'ai pas matté le code source, mais le jeu ne prend pas de CPU quand il tourne c'est déjà un certain gage de qualité.
Je ne peux donc que le conseiller à tous ceux qui ne sont pas allergiques aux jeux de plateformes 2D (même ceux qui ont 2 mains gauches comme moi peuvent y prendre du plaisir).

Open source ne se limite certainement au code source dans ma tête. Mais comme je te l'ai dit quand j'ai payé je savais qu'il ne s'agissait que du code, mais que c'était déjà énorme. Le jour où tous les éditeurs de jeu fourniront leur code source, une telle initiative passera inaperçue, mais ça n'est malheureusement pas à l'ordre du jour...
Donc oui l'expression 'XX goes open source' est litigieuse/trompeuse, mais ce n'est pas elle que j'applaudis mais ce que qui est fait (soit la libération du moteur). N'en déduis rien de ma vision du libre.
Allez bonne soirée je m'échappe !

Bon en fait que crois qu'on est d'accord. Un jeu c'est bien moteur + données, et à ce titre Gish n'est pas libre non. Après lorsque la libération a été annoncé, je l'ai lu ici sur LinuxFR ; je ne me rappelle plus les termes exacts mais pour moi il était clair qu'il s'agissait avant tout du code, et j'ai acheté en connaissance de cause.

Après pour l'expression 'XXX goes open source', je ne sais quoi en penser. C'est effectivement assez flou, et même si pour moi source fais référence au code source (et pourtant je suis aussi graphiste et on peut aussi parler de fichiers source genre .xcf ou .blend), je peux comprendre que tu le comprennes autrement.

Ce qui me surprend le plus est la facilité, en tant que pro-libre, avec laquelle vous applaudissez ce genre de sorties : une entreprise souhaite garder le contrôle, à l'opposé de l'idée de l'open-source, et vous applaudissez sans émettre la moindre critique??? Mais que signifie le libre pour vous?

J'ai monté ma propre boite pour pouvoir développer des logiciels libres sans qu'un patron ne me dise quoi faire ; pour ça j'ai fait beaucoup de sacrifices mais j'en suis très content (mais tu es bien placé pour me comprendre). Alors ne me juge pas trop vite : le libre est _très_ important pour moi ça ne fait aucun doute.

Je n'ai pas acheté Word of Goo lors de leur 1ère opération, parce que pour moi le libre est primordial, je me fous de 'ça tourne sous linux x86'. De même, je n'ai acheté le Bundle qu'une fois la libération du code de certains jeux annoncée (et je n'ai encore joué avec aucun des jeux, pas le temps).

Évidemment j'aurai adoré que les données soient sous licence libre ; ça aurait été bien mieux que des données popriétaires. Cependant des données proprio n'ont pas non plus le coté 'malsain' qu'a le code proprio (contrôle de la plateforme, de la durée d'utilisation etc...). J'aime les données libres soit (j'en produis moi même), mais ça ne me choque pas vraiment que je ne puisse pas modifier et revendre les BD que j'achète par exemple.

Donc avoir le code source de jeux encore en vente c'est à 1000 lieux de la production de jeux standard, où c'est plutôt le règne des exclu à une plateforme, DRM et autre chasse aux 'pirates'. Là tu pourra ressortir ton CD de données dans 10 ans et jouer sur ton Hurd pour FreeCPU :)

Donc oui je suis critique et je suis le 1er décu, mais je préfère taper sur le reste de l'industrie du jeu, qui pourrait par exemple libérer les vieux jeux qu'ils ont dans leurs cartons (rahhh FunTracks !!!), et je ne parle même pas de libérér le code de leurs jeux actuels, plutôt que sur ces gens qui vont dans la bonne direction.

Mais finalement, la question qui me trotte le plus dans la tête est : pourquoi avoir mis le moteur du jeu en open-source et pas le jeu entier si le jeu a été rentabilisé par les internautes qui ont payé?

1) Parce que rentabiliser c'est l'objectif minimum pour une entreprise, mais que là ils vont pouvoir continuer à gagner de l'argent en vendant les données. Comme les jeux sont encore d'actualité on peut les comprendre (si c'était des jeux vieux de 15 ans et qui ne rapportent plus rien ça serait encore plus rageant pour nous).

2) Peut être, mais là c'est une hypothèse de ma part, qu'ils veulent garder le contrôle sur l'univers de leur jeu, et qu'ils ne veulent pas que des gens sortent des variantes de leur jeu dénaturant leur univers, que ce soit parce qu'un artiste n'a pas forcément envie qu'un autre change sa vision, ou que d'un point de vue business ils veulent se garder cet univers pour une éventuelle suite par exemple.

Sinon je peux comprendre ta frustration si tu as sincèrement pensé qu'ils libèreraient aussi les données ; mais je pense quand même que la libération du code source va permettre par exemple de porter les jeux sur des architectures/OS exotiques par exemple, et pérenniser l'existence de ces jeux. Alors ne regrettent pas trop d'avoir donné, parce que tu as quand même encouragé une pratique quasi inexistante dans l'industrie du jeu vidéo, même s'il y a encore des progrès à faire.

Il y 2 ans et demi j'ai fait une régie pour un client afin de réaliser une appli de monitoring, plutôt orientée moteur de bateau. La précédente équipe avait codé une application utilisant Kylix je crois, et pour les widgets de monitoring, IOComp. L'équipe s'est lamentablement planté ; ils codaient certes comme des cochons, mais ils semble que les mauvaises performances des bibliothèques que j'ai citées ne soit pas pour rien dans cette échéc (quelle idée d'utiliser des saletés proprio aussi...).
Avec la nouvelle équipe nous sommes partis de zéro, en avons utilisé Qt (non sans avoir testé beaucoup de framework d'IHM). Nous avons notamment utilisé les possibilités de dessin vectoriel de Qt afin de coder des widgets spécifiques: jauges horizontales, verticales, cadrans etc... Le projet a été un succés (mon regret est bien entendu que tout cela reste du proprio), mais un projet tel que GICS aurait été le bienvenu à l'époque.

Tout ça pour dire que je pense que votre projet me semble clairement répondre à un réel besoin. Alors voir tout ça en libre me fait franchement plaisir. Je ne peux donc que vous souhaiter bonne chance pour la suite !!

Je vais quand même envoyer un mail à mon ancienne équipe pour leur indiquer l'existence de votre bibliothèque.

J'aime beaucoup ton commentaire. Mais j'ajouterai quand même qu'une (bonne) école va 'obliger' ses élèves à voir des notions théoriques qu'on irait pas forcément voir tout seul, aussi passionné qu'on puisse être. Par exemple j'ai un pote trés nerd, passionné, libriste et tout qui n'avait jamais entendu parlé de complexité algorithmique malgré son bac+4(pas de bol en plus son école n'était pas bonne et préférait produire des pisseurs de J2E qui ne comprennent pas ce qu'ils font...).

Non, il y a depuis pas mal de temps me semble-t-il un GC dans Python.
D'ailleurs je me demande dans quelle mesure du comptage de référence pour faire le gros du boulot, plus un GC pour les cas problématiques, est une solution meilleure (ou moins bonne) qu'un GC tout seul....

Si ça peut te rassurer, des lecteurs (enfin au moins un) apprécient tes posts quand ils vont à contre courant de l'avis de la majorité....

/me qui espère que Lisaac sera le langage/environnement qui dépote et venant de l'INRIA (parce que déçu par SmartEiffel et OCamL).

A mon avis, une des meilleures choses est la disparition des old-style class ; la cohabitation des 2 styles de classes est vraiment un reliquat inélégant.
Et je suis d'accord, on ne peut que se réjouir de la tendance à mettre des itérateurs là où il y a des copies de liste actuellement.

Ne serait-ce pas Incubation ? (si oui, j'avais bien accroché aussi)

J'avoue avoir été méchant. Je ne l'ai félicité qu'une seule fois ; et j'ai osé émettre un avis sur ce qui me semble être une légère erreur.

Je ne le referai plus, c'est promis ; je n'émettrai à l'avenir plus que des commentaires dithyrambiques. C'est comme ça que les logiciels s'améliorent, en émettant _que_ des encouragements.

<mode sincèrement gentil>
Continue David, c'est du bon boulot.
</mode sincèrement gentil>

[et si David s'est senti agressé, j'en suis vraiment désolé, c'était vraiment pas mon intention. Il faut croire qu'écrire des commentaires quand on a passé une journée de merde c'est pas mon fort]

C'est bien possible, c'est pas moi qui m'en occupons (et pour l'instant on ne compte pas trop sur le web pour attirer les clients - et pourtant ça marche).

Mais MERCI de ta critique.

Je n'ai jamais prétendu être une brute du C++ ; je faisais référence à des gens comme ceux de boost par exemple. Tu sais, ces gros guignols qui s'y connaissent un tout petit peu en templates et méta programmation ; et bien eux non plus ne foutent pas tout dans un seul fichier (pourtant on pourrait certainement trouver des points perfectibles dans leur code, malgré leur maîtrise - parce que c'est de ça dont il s'agit). Alors que toi tu sembles être sûr de toi, parce que ta lib existe depuis 7 ans, donc tu ne peux pas avoir commis une seule erreur (j'entends par là que ce n'est pas un argument technique ça).

[ argument technique oublié dans la précipitation : sinon découper en plusieurs fichiers, ça pourrait aussi apporter en temps de compilation (mais si tu codes en C++ comme un bourrin, tu dois le savoir) ]

Sans rancune.

Merci de ta longue réponse.

Alors non je n'ai pas ton expérience en C++ c'est bien certain. Mais l'argument 'ça existe depuis des années' désolé mais bof bof. Le VB aussi ça existe depuis des années....

Ensuite oui je connais la STL et le principe des templates ; et bien elle n'est pas constituée d'un seul fichier tu m'excuseras. Donc non je n'ai pas la prétention de connaître la meilleure façon de faire , sinon je ne me remettrais pas en question tous les 3 jours. Et si je suis peut-être prétentieux (on est mauvais juge de soi-même), permets moi de te retourner le compliment.

Alors tu fais ce que tu veux, je n'ai droit de regard sur ton travail (je précise que toutes les remarques que j'ai faites je les ai faites sur des souvenirs de précédents journaux ; c'est parce l'air de rien je me suis intéressé à ton travail). Mes critiques se voulaient constructives c'est tout, mais ta 1ère liberté, c'est de ne pas les écouter.

Je ne peux que souhaiter qu'une bonne âme face le plug-in gimp. Voilà.

Je ne veux pas passer pour le donneur de leçons, mais il semble quand même que ton gros fichier .h de plusieurs milliers de lignes, avec en vrac des trucs pour le fenêtrage/affichage, des fonts en dur etc.... embête plus qu'autre chose. Tu avais l'air de penser que c'est le plus simple, et pourtant regarde :
- personne au monde ne fait comme ça (parmi les personnes qui codent bien en tout cas...) ; c'est quand même un indice.
- si le packager pour le plug-in gimp l'a dit, que les dev krita préfèrent partir du code du plug-in Gimp, c'est peut-être un autre indice.
- les dev ne sont pas des imbéciles ; s'ils n'arrivent pas à gérer 3 .cpp qui se courent après, ils peuvent arrêter de coder....

Si ton code était bien séparé entre .h et .cpp, qu'on puisse obtenir une vraie bibliothèque, ça changerait surement des choses (et si comble du bonheur, il y avait en plus une interface en pur C, ça ouvrirait encore d'autres horizons -- même si SWIG gère aussi le C++) : un vrai paquet dans les distribs, des bindings vers d'autres langages (python etc...), un développement pour des plug-in facilité...

Enfin bon, je m'emporte, et je ne t'ai même pas félicité pour ton algo excellent ; mais je trouve dommage qu'il soit si mal mis en valeur.

Je précise que je n'ai rien contre OCaml ni contre les logiciels 'non-industriels' (pour le libriste que je suis ça serait vraiment cracher dans la soupe). Pour en avoir fait un petit peu, c'était effectivement vraiment pas mal. A écouter certains, c'est le meilleur langage du monde et on peut jeter le reste (mais bon je ne suis pas le dernier à précher pour mes outils favoris, je sais ce que c'est), mais j'aimerais quand même la réponse de personnes qui s'y connaissent bien en OCaml à mes quelques questions :
- Si j'en crois la doc, les threads sont lightweight et n'utilisent donc pas les multi-processeurs. Est-ce exact ?
- Toujours en mattant la doc, le chargement dynamique de bibliothèques ne marche qu'en mode bytecode, et pas en mode natif. Là encore, est-ce que je me trompe ?

Parce que si je ne me trompe pas, ça fait quand même 2 trucs assez indispensables qui manquent. Alors, je suis le 1er à m'extasier sur des conceptions super haut niveau ou des algos élégants et performants, mais pour un langage que certains voudraient voir remplacer le C, je trouve ça très handicapant.

Voilà mon objectif n'est absolument pas de dégouter les gens de OCaml (il y a des tas de langage très nuls mais super utilisés, alors un bon langage sous utilisé je vais pas taper dessus en priorité), mais juste de signaler que faire un langage avec des abstractions super bien foutues c'est bien, mais pour pouvoir remplacer les autres langages, il va quand même falloir pouvoir faire au moins autant que ces derniers.

Les API de Vista ne sont dispo que pour Vista ; donc non c'est pas la panacée d'utiliser les fonctions de 'chrooting' différentes de tous les OS pour avoir quelque chose de portable. Mais ça changera peut être dans le futur (remarque que je n'ai pas dit que ce n'était pas possible).

Sinon as tu des infos supplémentaires ?? Peut-on dans Vista 'chrooter' une simple classe par exemple, et pas un thread en entier (il me semble avoir lu que sous win on a des droits avec une granularité au thread près) ??

Un truc que j'adore avec linuxfr c'est qu'on y rencontre des gens vraiment pointus !
Je vais mater ton langage avec attention.

Sinon tu as fini par dire que sans vm le langage devait être sandbox-ready (dans la pratique), donc ce n'est pas l'OS qui assure tout seul le sandboxing (auquel cas le langage n'importerait pas).

(merci encore pour cette discussion fort intéressante)

Merci, je ne connaissais pas les slim binaries ; c'est très intéressant je m'en rappelerais.

Pourtant, tu te contredis légèrement, puisque tu dis 'ca sert à rien' puis 'sauf dans qq cas'. Je pense qu'on va aller dans un monde avec plein de machines très différentes interconnectées (station, pda, téléphone) donc ces quelques cas font que si ça ne marche pas partout, c'est génant (c'est comme dire que si ça marche pour win ça marche presque partout...). Mais bon dans l'ensemble on est assez d'accord au final : on peut se passer de VM la plupart du temps (beaucoup de programmes ne perdraient pas de feature, et gagneraient en perf, à être réécrits dans un langage sans VM par exemple).

Pareil pour le sandboxing : le faire de manière identique sur tous les OS, pour une portion de code (et pas un processus en entier) et à l'heure actuelle, sans java/.NET(/autre?), et bien c'est pas possible. Et que dans l'absolu, ça soit possible, ça ne change au final pas grand chose. Donc je maintiens que si on a besoin de sandboxing (c'est à dire pas souvent, je te l'accorde), pour l'instant la VM est le seul salut.

Quant au remoting, oui j'ai précisé que cétait juste un confort pour le programmeur (la comparaison avec Corba est bonne).

Je précise tout d'abord que je ne suis pas un java/C# zealot, et que je suis bien content que la plupart des applis que j'utilise soient codées en C/C++. Pourtant je pense que tu te trompes ; pas complètement, mais tu te trompes quand même. Je m'explique.

La portabilité (binaire avec bytecode - ou directement avec le source) + le sandboxing, ça peut être très utile, même en utilisant que des Logiciel Libre, même sur un desktop. Par exemple, dans ton browser, y a éventuellement du Java, du javascript, et tu es bien content que ça soit portable et sanbboxé(tu comprend bien que "chrooter" ton browser, c'est pas la panacée). Non je milite pas pour plus de java/javascript sur le web, c'est un exemple. Mais on pourrait en trouver d'autres. Par exemple un genre de BOINC, qui téléchargerait des calculs à faire, mais sans avoir besoin de devoir faire confiance à un binaire qu'on ne télécharge pas grâce à sa distribution. Ou un serveur de jeu, qui enverrait des règles spécifiques à une map. etc...

Donc même dans un environnement libre, avoir du code mobile peut avoir du sens (il suffit de savoir qu'on peut le faire, et les idées viennent !!). Et utiliser l'os pour chrooter toutes ces applis n'est pas une solution viable. Mais bon je t'accorde que toutes les applis n'en ont pas besoin. Et que si besoin est, le coeur de l'appli peut être codé en C par exemple, mais charger à côté une VM pour exécuter uniquement le code mobile.

(ah oui et le remoting c'est pour faire de l'appel de fonctions/méthodes à distance ; ça peut être confortable pour le programmeur ; mais pour l'utilisateur là ça ne change rien).

Quelques remarques:

- Oui Ogre a servi à faire un jeu pro (Ankh) ; je te l'accorde c'est pas le fleuron de la 3D internationale, mais c'est quand même plutôt mignon ; comme quoi de bons artistes, c'est ça qui importe le plus pour les graphismes (mais je suis bien certain de ne pas te l'apprendre, vu que tu as l'air d'un joueur expérimenté).

- Je pense ne pas trop mal connaitre l'industrie du jeu, j'ai même fait un stage dans une boite de jeu il y a quelques années, et je peux te dire que c'est pas tous des dieux du code (surtout en ce qui concerne la propreté :). Et à part quelques exceptions, le code est rarement super optimisé, ou alors c'est tellemet pas scalable qu'il vaut mieux que le libre ne s'en inspire pas !! Donc oui Ogre par exemple, pour le connaitre un peu, pourrait être bien amélioré, mais c'est bien le principe du LL non ? Perso, je trouve ça plus sain de faire un moteur d'assez haut niveau, quitte à optimiser plus tard ; en effet les boites de jeu, elles sortent un titre, le vende, puis elle l'oublie et passent à la suite etc... je ne crois pas que ça corresponde trop au concept du libre, qui s'inscrit plutôt dans la durée[*].

- Dans la même veine que ce que je dis au dessus, courrir derrière le photoréalisme n'est pas une bonne idée je pense ; en effet c'est très statique dans le temps comme concept (ressors tes vieux mags de jeux qui parlent de photoréalisme ; c'est tellement laid que ça fait rire). A mon avis les jeux qui vieillissent le mieux sont ceux qui ont plutôt un style très marqué pas photoréaliste. Pour un éditeur pro c'est pas grave : il sort son jeu qu'il doit vendre pendant 6 mois, et qui doit donc être beau pendant 6 mois. Mais pour un logiciel libre, c'est une erreur. Par exemple Planeshift qui n'était pas super beau déjà il y a quelques années, et bien ça va pas s'amèliorer ; alors que Frozen Bobble, son graphisme on le trouvera toujours mignon dans quelques années.

- A mon avis le principal problème des jeux libres, c'est qu'il doit y avoir à la base un noyau dur de bons codeurs et de bons artistes, parce que sinon ils n'arriveront pas a attirer d'autres personnes sur leur projet. Un artiste ne se joindra pas à un truc moche ; un codeur voudra refaire son propre moteur de jeu (comme on en trouve des dizaines sur freshmeat....). C'est pour ça que je suis d'autant décu de la non libération de Ryzom : son potentiel de base aurait certainement attiré plein de gens de talent (tandis que les MMORPG libre from scratch n'attirent pas vraiment les foules).

[*] je parle de libre au sens : des bénévoles passionnés qui font ça sur leur temps libre. Si c'était une boite qui faisait un jeu au code source libre, ça serait une autre histoire....

"Tant mieux, ce jeu mérite mieux que tomber aux oubliettes"
http://forums.jeuxonline.info/showpost.php?p=13229285&po(...)
(je te l'accorde, il y a un smiley qui laisse planer le doute sur de l'éventuel second degré)

"Pour ryzom.org, ça me semblait plus un projet concernant le logiciel libre que le jeu Ryzom, donc "l'échec de Free Ryzom" m'est complètement indifférent."
http://forums.jeuxonline.info/showpost.php?p=13229087&po(...)
(oui, bravo, la communauté se mobilise pour la libération, dont oui ça concerne une libération....)

C'est clair, il y en a qui mérite des baffes ("cool, c'est pas devenu libre, ça va pas tomber aux oubliettes"....ce qui faut pas lire....). Mais j'ai la flemme de me créer un compte sur ce site de kikoolol pour les moucher, c'est peine perdue je pense.

C'est vraiment bête, encore un jeu proprio (malgré les bases libres) dont on n'entendra peut être plus parler....

Il suffit que ta bibliothèque C++ (compilée avec g++ donc), dispose d'une interface purement C. C'est à dire un ensemble de fonctions qui prennent/retournent des types C, déclarées dans un .h. Pour bien faire les choses, mets ' extern "C" ' devant chacune de ces fonctions (déclarations et définitions).

Plus qu'à compiler ton application C avec gcc, en te linkant avec cette bibliothèque.