GuieA_7 a écrit 695 commentaires

Il y a déjà un beau moteur graphique

Ce n'est pas un moteur graphique, mais un moteur de jeu spécialisé dans les RTS.

Et oui Spring fait parti des moteurs libres les plus aboutis ; mais pour appuyer mon 1er commentaire, au final la moitié des jeux l'utilisant (http://springrts.com/wiki/Games) ne sont pas libres (contraintes NC et/ou ND).

Il ne permet donc pas de faire n'importe quel type de jeu, mais j'imagine qu'on doit pouvoir écrire son propre RTS sans toucher au code (ce qui est bien).

C'est dommage qu'on ne parle jamais de ce projet sur linuxfr.

Tu en sais sûrement plus que la plupart des linuxfriens sur ce projet, c'est donc peut-être à toi de faire le premier pas et d'écrire un journal ou une dépêche dessus ! :)

Et ce qui manque le plus dans les jeux libres, ce sont ces formats standardisés

J'aurai tendance à dire que non, c'est un problème très secondaire. Le jour où il y aura des tas de jeux libres de qualitay, et qu'on aura à gérer des tas de moteurs maisons avec leurs formats propres, et leurs différentes sous-versions etc…, alors le problème des standards se posera (d'ailleurs l'industrie du jeu y est confrontée — j'avais vu un article sur Gamasutra à propos de Collada y a quelques années par exemple).

Je ne peux pas ouvrir mes fichiers .blend (de Blender donc) dans un autre modeleur 3D ; c'est dommage mais en pratique, je m'en tape parce qu'aucun autre modeleur libre ne lui arrive à la cheville. Je préfère avoir un seul logiciel libre/gratuit/multi-plateforme qui assure, plutôt que plusieurs interopérables mais qui font le tiers de ce que je veux.

À côté de ça, ça plus de 10 ans qu'on peut facilement exporter les modèles 3D de Blender vers Ogre3D. Pourtant tous les jeux utilisant Ogre un tant soit peu aboutis sont propriétaires [*]. Pas parce que les libristes sont mauvais, mais parce que faire un bon jeu ça demande beaucoup de temps, qu'il y a peu de libristes graphistes, etc… De manière générale les créateurs de jeux libristes sont très peu nombreux, la comparaison avec les jeux propriétaires est donc forcément décevante.

Ton jeu utilise 3 formats : et bien tant pis c'est pas grave ! Quand tu auras des milliers de joueurs tu pourras proposer à tes étudiants un projet consistant à régler ce problème (ils seront ravis de toucher à un programme utilisé par des tas de gens).

Les formats standardisés ne vont pas t'apporter de graphiste libriste. A l'inverse un outil de création de jeu accessible à des non codeurs serait un vrai plus ; ces dernières années un certains nombre de très bons jeux indépendants utilisent des logiciels comme GameMaker. Mais :

• qui va écrire un tel soft en libre (c'est sûrement beaucoup de travail aussi) ?
• paradoxalement, un tel soft, gratuit et de qualité, serait sûrement utilisé avant tout pour faire des jeux proprios ! :)

J'espère ne pas avoir l'air trop négatif, je pense juste que le problème est complexe, et la solution pas forcément technique ; l'organisation de Jam et le prosélytisme de la part de tes étudiants est peut-être plus efficace au final !

Ah oui, félicitation pour ta série d'articles !

[*] Je dis ça sans méchanceté aucune, j'ai moi-même pas mal d'embryons de jeux libres dans mes cartons, dont un utilisant Ogre.

Je n'aime pas trop cette construction, ce n'est ni intuitif, ni très connu.

Je n'ai pas l'occasion de m'en servir tous les jours (comme des tas d'autres fonctionnalités au final), mais moi j'aime beaucoup cette construction. C'est à la fois lisible, et plus court et plus performant que par exemple avoir un booléen qu'on testerait en sortie de boucle. En fait j'ai même toujours pensé que ça irait bien d'autres langages genre le C.

Dans ce même registre, j'aurai aimé connaître ton avis sur Rust (en faisant abstraction du fait que la v1.0 ne soit pas sortie) ; il me semble qu'en ayant une bonne part de la puissance (concision/sûreté etc…) de langage comme Haskell/OCaml/Erlang tout en étant un vrai langage système (plus son concept de référence protégeant statiquement des data races par exemple), j'ai l'impression qu'une bonne part des analyses statiques sont déjà parties intégrante du langage (sans rebuter gens qui cherchent les performances brutes).

Quand les gens faisant du Rust s'appuient naturellement sur les forces du langages, dans le but d'obtenir des programmes élégants et performants, on y gagne en sécurité "gratuitement". Les programmes ne deviennent évidemment pas sécurisés par magie (la sécurité ça n'est pas que supprimer les buffer-overflows et cie), et pour le coup Capsicum ne perd aucun intérêt

Mais évidemment cela nécessite la ré-écriture des programmes, peut-être que c'est pour ça que tu évoques d'autres solutions.

Ceci est absolument faux. Tu confonds pas mal de choses.

Non. Parce que comme dit au dessus tu pointes le droit d'auteur "normal" (celui pour les livres, photos etc…) mais qu'il y a des exceptions spécifiques à l'écriture de code en entreprise.

Maintenant une entreprise peut-elle supprimer le nom d'un de ses salariés (ou sous-traitant) en tant qu'auteur ? Je n'en sais rien je l'avoue. Je n'ai peut-être pas été très clair, mais je parlais plus du fait de rajouter les informations manquantes fournies par la société 'C' en vue de libérer ; auquel cas il faut qu'il y ait au minimum la mention de 'A' en tant que détenteur des droits. Les salariés de 'C' ne seront que les auteurs ; je n'ai pas parlé de supprimer leurs noms, mais plutôt de les rajouter s'il ne l'ont pas fait eux-mêmes (en leur demandant leur avis). Je ne sait pas si 'A' aurait le droit de supprimer leurs noms comme je l'ai dit, mais en même tant ça serait un peu une attitude de merde de toute les façons, et j'étais plus dans l'optique de rendre à César ce qui lui appartient (à savoir un peu de reconnaissance).

J'imagine que les salariés de 'C' ont le droit de refuser, c'est pour ça que je dis de leur demander leur avis. Et le code ayant déjà été livré, je ne vois pas où 'A' s'oppose à ce qu'ils mettent leurs noms dans le code ; éventuellement ça serait la faute de 'C', je propose justement de rétablir la situation.

Mais encore une fois, si je n'ai pas été assez clair : je parlais uniquement d'ajouts.

Attention il faut faire la différence entre auteur et détenteur du doit d'auteur. Lorsque le salarié 'a' de la société 'A' écrit du code dans le cadre de son travail, il est l'auteur du code mais c'est 'A' qui détient les droits d'auteurs (j'admets que 'a' ne travaille pas en régie dans une société 'C'). Si ici 'B' a bien cédé ses droits à 'A' (cela dépend du contrat entre les 2 sociétés), alors c'est bien 'A' le détenteur des droits, quand bien même les auteurs sont des salariés de 'B'.

Seul le détenteur des droits doit figurer dans les sources, mais il est classique et sympa de citer les auteurs, ainsi qu'éventuellement leur rôle dans le code et une adresse e-mail, généralement dans un fichier AUTHORS. Cela ne leur donne aucun droit sur ledit code, mais à moins que le code ne soit honteux, ça fait plaisir un peu de reconnaissance ! Je serai donc d'avis de demander aux auteur chez 'B' s'ils souhaitent y figurer.

Pour la permissivité, attention cela veut dire que le code sous licence permissive peut tout à fait être intégré dans un code sous une autre licence (libre ou proprio) ; en revanche cela ne veut pas dire que la licence originelle du code peut être modifiée. Elle reste la même, tandis que le reste du code a une autre licence, mais ça ne pose pas de problème.

Auriez vous des suggestions de licences pour un mode permissif ou un mode contaminant ?

Restes sur des licences classiques et éprouvées :

• GPL/LGPL/AGPL pour du héréditaire/contaminant.
• BSD/MIT/Apache pour du permissif.

C'est déjà assez compliqué comme ça les licences libres pour ne pas aller en chercher une exotique que personne ne connaît.
Et si celles-ci ne te satisfont, que tu veux des clauses supplémentaires (genre obligation de remonter les modifications à l'upstream, ou avoir la photo de la sœur des contributeurs), tu vas te rendre compte que tu ne cherches pas à faire du libre.

Pourquoi? Du point de vue de l'acheteur non codeur, pwivateur sans DRM ou libre, c'est la même chose.

Oui, mais du point de vue du développeur/éditeur (celui qui prend des risques donc), ce n'est pas pareil. Dès que le jeu va être un peu connu, des parasites peuvent apparaître et vendre le jeu rebrandé. C'est vrai pour le jeu proprio sans DRM ou pour le jeu libre, mais dans le 1er cas il y a des recours, dans le second c'est explicitement autorisé. Or comme tu l'as dit toi-même, les joueurs s'en fichent, en tout cas aujourd'hui, que le jeu soit libre.

Bilan, le fait de faire un jeu libre apportent des soucis supplémentaires (moins de protections contre les parasites, même si on ne peut pas s'en débarrasser dans tous les cas), mais pas de ventes supplémentaires. D'un point de vue strictement économique c'est malheureusement compréhensible.

Personnellement je pense être un libriste plus que convaincu (j'ai fait beaucoup d'effort pour aujourd'hui vivre de mon logiciel libre, travailler pour une boîte classique qui fait du proprio aurait été bien plus facile et rémunérateur), pourtant même moi je ne prendrai pas le risque de faire un jeu entièrement libre si c'était pour en vivre. En revanche j'opterai pour des assets proprios:

• soit pendant la période de commercialisation (j'entends par là quelques années tout au plus).
• soit pourquoi pas une campagne de financement participatif dont l'objectif serait la libération des assets (à la manière de l'OpenBundle, histoire de voir ce que les libristes sont vraiment prêt à donner pour avoir des assets libres.

Le 4ème lien fait mention de "CreamCRM" => CremeCRM.

Très bonne question.

Si ça ne tenait qu'à moi, on serait déjà passé à Python 3. Mais :

• on tient à ce que Creme soit installable facilement sur une Debian stable ; parce que c'est ce qu'on a sur nos infrastructures, mais aussi que ça représente assez objectivement l'inverse du bleeding-edge, donc ça sera installable à peu près partout.
• je souhaite passer à Python 3.3 au minimum, parce qu'en dessous ça semble plus pénible de migrer depuis Python 2 ; or la Debian 7 vient avec Python 3.2.

Donc on ne passera à Python 3 qu'avec la prochaine Debian stable ; et encore pas immédiatement, vu que par exemple Creme 1.4 tourne sur Python 2.6 car on a encore des Debian 6 sur certains serveurs, et on ne demandera Python 2.7 qu'avec Creme 1.5 (j'ai déjà pas mal de patches en préparation). Ça n'est donc pas pour tout de suite, mais ça va arriver, et ce n'est pas l'envie qui manque !

Je pense qu'on sautera le pas directement, on ne gérera pas à la fois Python 2 & 3, car pour un logiciel "final" (pas une bibliothèque) ça n'a pas beaucoup d’intérêt (en plus de nécessiter plus de travail). Je verrai bien ce passage à l'occasion de Creme 2.0, mais rien n'est décidé à ce niveau.

Sinon dans nos dépendances en effet rien n'est bloquant techniquement à part pygraphviz, mais c'est une dépendance très dispensable, qui pose déjà des problèmes (pas installable sous Windows), et dont je me débarrasserai quand j'aurai le temps.

Merci pour les liens.
J'avoue n'avoir rien compris au PDF sur LRA, il m'a l'air destiné au gens connaissant bien le fonctionnement interne et les nomenclatures de GCC. Tant pis.

En revanche le lien sur REE était sympa. Voici un résumé pour les lecteurs pressés :
Dans certaines situations le compilateur génère des instructions inutiles (car le boulot a en fait déjà été fait), ou bien 2 instructions qui peuvent être fusionnées en une seule. C'est notamment le cas sur x86-64 lorsqu'une valeur 32bits est chargée dans un registre 64bits, et que le processeur étend implicitement cette valeur avec des 0 dans les 32 autres bits (d'où le nom "extension instructions"). Cette passe va donc éliminer les instructions inutiles ou bien fusionner 2 instructions. Le gain de performance est apparemment assez faible sur les processeurs avec ré-ordonnancement dynamique, mais peuvent aller jusqu'à 10% sur Atom par exemple.

dans sans avoir à suivre les autres directives

Le backend AArch64 profite également de l'activation de la passe d'optimisation

Outre les nombreux changements liéS

Sinon très bonne dépêche ; j'aurai bien aimé une petite explication pour REE (Redundant extension elimination) et LRA (local register allocator), ça m'avait l'air intéressant.

Pour la peine, est-ce qu'ils n'auraient pas gagné en perf en faisant une distinction entre int et Integer comme en Java ?

Ça marche en Java (et C#) grâce au typage statique ; le langage sait s'il faut convertir un int en Integer (ou l'inverse) car il connaît le type des variables et celui des paramètres des méthodes. Mais comment faire en Python ? Ta fonction "def foo(a): […]" comment peut elle savoir si elle reçoit de la part de l'appelant un int ou un *PyObject (au sens C) ? Tout repose sur le fait que les variables sont toutes des *PyObjects, et qu'ensuite on applique le duck typing.

A noter quand même :

• Dans CPython, y a pas mal d'endroits où la VM prend des raccourcis quand elle rencontre des types de base. Par exemple avec "if a:", la méthode __nonzero__/__bool__ de "a" n'est pas appelée en cherchant dans la virtual table lorsque Python s'aperçoit que "a" est un *PyInteger ou une *PyList par exemple, car en pratique on appelle rarement "if" sur des instances classes utilisateur. Python reste évidemment lent, mais il le serait beaucoup plus s'il était codé naïvement.
• PyPy est capable de générer du code machine travaillant avec des simples int lorsqu'il s'aperçoit que c'est possible et pertinent ; par exemple il va utiliser une version spécialisée de liste si elle ne contient que des *PyInteger.

Non ça ne marche pas (mais c'était drôle quand même). Il se trouve que dans CPython (mais a priori c'est une question d'implémentation, ce n'est pas portable), les entiers jusqu'à 256 sont des singletons (ils sont pré-alloués en plus me semble-t-il). Chez moi (Python 2.7.6):

> a = 256
> b = 256
> a is b
True

Mais

> a = 257
> b = 257
> a is b
False

Donc on n'a pas "==" et "is" qui sont équivalents de manière général (et donc pas avec "0xdeadbeef" en particulier).

Il y a un problème avec ton 2ème exemple. On rentre dans le bloc else d'un for (ou d'un while) à la fin de l'itération, sauf si on est sorti avec un break justement. Ton bloc else ne peux donc pas être le traitement d'erreur tel que présenté.

Sans parler des cas très pointus où le GC va permettre, en défragmentant le tas, d'améliorer la localité des données et ainsi améliorer les performances (parce qu'il faut quand même que cet avantage surpasse l'inconvénient qu'est l'arrêt de la tâche), un GC pallie le problème des cycles de références, qui vont engendrer des fuites mémoires même avec des pointeurs intelligents. C'est pour ça par exemple qu'avec CPython ou en PHP, il y a un GC qui s'occupe des cas problématiques (les cycles donc), même si le refcounting fait la majorité du boulot.

Sinon sinma a bien répondu juste au dessus je pense, à savoir que le GC est par tâche, et ne s'occupe que des références qui le concernent, ce qui fait qu'on est loin d'un langage entièrement sous GC.

Je rajouterai que:

• le runtime est entièrement remplaçable/supprimable : zero.rs est utilisé par les gens qui font des noyaux et enlève le runtime classique et la possibilité d'un GC.
• la bibliothèque standard n'utilise pas le GC (ni de refcounting je crois).

Du coup la logique du "tu payes pour ce que tu utilises" est vraiment poussée loin.

En même temps il s'agit dans tous ces cas d'exprimer f(n+1) grâce à f(n), c'est conceptuellement très proche. Après quelle est la manière la plus efficace de l'enseigner; je ne sais pas. Mon prof en prépa qui nous a enseigné la récursivité, a immédiatement fait le rapprochement avec la récurrence et ça marchait bien, mais il y sûrement d'autres approches possibles. Tant que c'est bien enseigné ça me va.

Pourtant on voit ça pour le bac, il me semble. Faire des dérivées de logarithmes et d'exponentielles, j'en ai fait en Bac STL Chimie, il doit bien y en avoir des restes dans toutes les filières à vocation scientifique, non ?

Les gens qui atterrissent en BTS info ont, j'ai l'impression, souvent du mal avec la théorie, sinon ils seraient allés en IUT/prépa/Fac. Je ne serais pas étonné qu'ils sachent trouver le bouton 'log' sur leur calculatrice pour appliquer une formule, mais trouver une complexité algorithmique nécessitera sûrement un rappel.

Malgré un passage par Math Sup, je n'ai pas le souvenir du concept de récurrence (mais c'était il y a 15 ans). Mais ça ne m'a pas empêché de comprendre immédiatement le concept des fonctions (programmatiques) récursives. D'ailleurs, peut-être que la factorielle est une fonction (mathématique) récurrente ?

Tu n'a jamais fait de démonstration par récurrence ? J'ai fait une prépa de 1999 à 2001 et c'était au programme ; en fait je suis même à peu prêt sûr de l'avoir vu aussi au lycée en S. Peut-être que ça t'a aidé à comprendre au début la récursivité (que tu utilises encore régulièrement j'imagine) même si tu l'as oublié depuis.

Je suis bien d'accord qu'il faut des bases, c'est pourquoi je suis un fervent opposant à la mode d'enseigner la programmation par le Basic à la mode (en ce moment c'est Python).

Je suis partagé à ce sujet. Pas mal de hackers de talent, ou moi, ont commencé par le Basic, qui leur a fait découvrir la joie de faire un programme qui vit sous ses yeux ; au final le goût de la rigueur, de la théorie, vient avec le temps (tout comme j'estime n'avoir fait des Maths qu'en prépa, avant c'était du bricolage avec des nombres). Les gens qui ne s'orienteront pas vers l'info auront vite tout oublié de toutes les façons (mais peut-être que l’informatique leur paraîtra moins mystérieuse, ce qui est déjà bien), et dans les filières info d'autres langages seront enseignés. Mais on s'écarte du débat :)

ce sont les carences en orthographes et grammaires qui sont les plus graves.

Je suis d'accord, mais le problème c'est que ces carences auraient du être éradiquées bien avant, genre au collège. Que ce soit au BTS de corriger ça indique un vrai problème, et ce n'est pas au BTS de le faire ; le français est indispensable dans toutes les filières, et ce bien avant le lycée.

néceçaires

tu parlais d'ortaugraf c'est ça ? :)

je ne vois pas plus utile

Savoir ce qu'est un logarithme ou un polynôme pour comprendre la notion de complexité algorithmique me semble indispensable (et je sais d'expérience que les gens sortant de BTS ne savent pas ça en général). Et même avant ça, comprendre la notion de récurrence aide à saisir comment raisonner avec la récursivité ; ça me semble assez basique et pourtant c'est une carence répandue. Si on veut faire des programmes un tant soit peu correct, il faut faire un minimum de théorie. Des tas de non informaticiens pondent le logiciel interne (boiteux) de leur entreprise en Windev, mais sans aucune approche scientifique ça va être difficile aux gens sortant de BTS de se démarquer des premiers.

Si ma mémoire ne me fait pas défaut, on peut lancer Blender en lui donnant en paramètre un script Python à exécuter immédiatement, ce qui permet de faire basiquement ce que tu demandes.

Après je ne sais pas si l'API Python actuelle (2.50+) permettrait d'attendre des commandes (activement ou passivement), venant d'un pipe/fichier/socket, afin de piloter plus finement, et interactivement, Blender depuis une console classique. Je suis à peu près sûr en revanche que cela n'était pas possible avec la vielle API (2.49 et avant).

Dans mon Gimp (2.6), dans Filtres/Flou tu as un effet 'Pixéliser', qui semble faire ce que tu veux.

Python, ruby, C, C++ : erreurs dans les calculs simplissimes ex 0.1 + 0.7 = 0.79999999

Dans ces langages, les nombres à virgule flottante sont mappées sur ceux gérés par le processeur (avec les erreurs inhérentes à ce type de données), et on les utilise pour des questions de performances quand les erreurs sont acceptables (ex: 3D), et c'est très bien comme ça.
Maintenant en Python par exemple tu as dans la bibliothèque standard (donc ça fait partie du langage) le type Decimal qui fait ce que tu veux ; pour les autres des bibliothèques qui font la même chose existent j'imagine.

Dans Django (framework web python) ce type Decimal est fourni de base pour les modèles sauvés en base de données. On s'en sert dans CremeCRM pour la facturation par exemple, et ça fonctionne nickel.

Maintenant les logiciels de gestion ne sont franchement pas les plus exigeants de manière générale, dans le sens où n'importe quel langage que tu apprécie peut faire l'affaire, et les problèmes que tu cites semble être des détails tout à fait anodins. Aucun des langages n'est parfait, mais une chose est sûre, si tu en créé un il sera bien plus mauvais que n'importe lequel des langages que tu as cités.

Je ne suis pas vraiment d'accord avec toi, mais ton commentaire est constructif cette fois, ça va être intéressant de discuter.

Les chances que cela soit de l'incompetence technique sont infinitesimales.

(Je ne peux pas trop en dire, mon identité n'étant pas un secret) tu sous-estimes le fait que dans nos instances dirigeantes (ou à la tête de grandes entreprise, je côtoie les deux) :

• des tas de gens agissent pour leur propre intérêt, pas le bien commun, quitte à couler un projet qui marche pour se faire mousser, ou à l'inverse mettre en avant une solution boiteuse en échange de service, par exemple.
• je ne sais pas si c'est typiquement français, mais ici on voit peu de techniciens dans les sphères dirigeantes. Les hiérarchies ont un niveau technique très faible, et se font facilement rouler par des roublards (des gens de leur staff aux dents longues par exemple), ou bien prennent des décisions techniques aberrantes par orgueil (ils pensent y comprendre quelque chose).

Ces choix sont dans l'enorme majorite des cas des compromis apres reflexion, de rares fois des choix evidents, et tres rarement une decision totalement stupide.

Je suis d'accord pour le compromis (en technique il est toujours question de compromis).

Mais surtout même les décisions stupides le sont rarement assez pour être fatales, ça ne veut pas dire que c'était de bonnes décisions pour autant. Par exemple un de nos ex-prospects, une école faisant partie d'un groupe d'écoles, c'était fait imposer un logiciel par ledit groupe. Ce logiciel avait été choisi car c'était le leader du secteur global, mais l'école ne l'utilisait pas, car il ne correspondait pas vraiment au besoin. L'école s'est ensuite fait imposer en remplacement un second logiciel (le leader au niveau des écoles), mais là encore il n'était pas très pertinent et restait inutilisé. Mais bon au final les gens s'en sortait quand même avec du bon vieux papier (et sûrement des fichiers excel). Je pense que cet exemple n'est pas isolé.

Mais cette habitude qu'on certains ici de mettre au pilori automatiquement toute decision qui va dans le sens de MS, sans rien savoir de la situation sinon leurs prejuges pourris, est vraiment a vomir.

Oui j'ai aussi horreur des fanboys/hateboys de tous bords, mais de manière générale je trouve que le MS-bashing se fait moinser rapidement. Et dans le cas qui nous intéresse on a quand même des gens qui sont partis en masse, dégoûtés par leur hiérarchie, et ici en France les mauvais techniciens préfère généralement rester planqués. Je ne peux tout de même pas me prononcer sur la prétendue incompétence de l'armée, mais on a plus d'arguments factuels que s'il s'agissait d'un simple MS-bashing je trouve.

Ce qui est drôle c'est ce que tu fais exactement ce que tu dénonces, à savoir affirmer de manière arrogante. Si encore tu avais dit "ce n'est pas forcément de l'incompétence".

Des gens en interne nous donnent un témoignage ; leurs avis n'est pas pour autant 100% objectif, mais ils connaissent à priori mieux le dossier que toi. Tu affirmes que ça ne peut pas être de l'incompétence, comme si ça n'arrivait jamais qu'une hiérarchie n'ayant pas de compétence technique prenne des décisions techniques (à l'encontre de leur staff) ; personnellement je l'ai vu plusieurs fois.

Ça me fait un peu penser aux Exceptions (sans les problèmes de sûreté) mais la syntaxe est quand même assez différente et… perturbante. Ça me parait plus souple que les exceptions, mais à voir à l’utilisation.

Si ça ressemble visuellement aux Exceptions, la sémantique est assez différente, puisqu'il manque la fonctionnalité la plus puissante (mais aussi la plus controversée), à savoir la remontée au travers de la pile (et donc des appels de fonctions). En effet dans Rust, le gestionnaire de conditions est exécuté à l'endroit du raise, et ne constitue pas une autre façon de sortir de la fonction.

Bien utilisée, la remontée dans la pile permet d'écrire du code court et d'éviter pas mal de code boilerplate. Malheureusement ce comportement casse la sémantique de Rust, qui ne pourrait plus fournir ses garanties.

Je suis assez sceptique sur l'utilité des conditions, parce que si le discours est qu'on peut coder le comportement que l'on veut face à une erreur, j'ai l'impression qu'il faudrait plus ou moins penser à tous les comportements possibles, afin que la signature du handler permette dans les faits de gérer l'erreur comme on le veut. Je me dis que dans la pratique on va peut-être la plupart du temps finir par gérer l'erreur d'une manière figée et retourner un Option/Result.

Mais j'espère me tromper, et je vais faire confiance aux développeurs de Rust qui ont fait du super boulot pour le reste, donc y a pas de raisons ! Et Rust possède à côté d'autres outils permettant d'éviter le boilerplate.

Mon précédant jeu est en "pause" ; le choix de notre moteur 3D (JME) s'est avéré mauvais à l'usage ; ça a beaucoup ralenti le développement, et la motivation est partie. Mais j'ai attaqué un jeu un peu moins ambitieux depuis (avec Ogre), dans lequel je peux réutiliser en grande partie mes assets ; je vais essayer d'avancer substantiellement pendant mes vacances.

Autant GIMP peut clairement me servir pour SàT (icônes, tutos, etc), autant Blender c'est juste pour le plaisir

Il y a quelques années j'avais utilisé Blender pour faire des icônes avec un rendu assez réaliste pour un prototype client, et ça marchait plutôt bien. Avec un peu d'imagination ça peut être un outil très utile pour de la 2D ; on pourrait aussi imaginer des avatars sous la forme de sprites animés etc….