rewind a écrit 3416 commentaires

La librairie standard c++ utilise les exceptions, mais dans certains cas limités, comme une allocation ratée.

Elle l'utilise aussi dans vector::at (et d'autres du même genre comme string::at) qui est l'équivalent de l'accès indicé (celui avec les accolades) mais avec vérification du domaine. Et il y a les fonctions de conversion genre std::stoi qui peuvent renvoyer des exceptions. Il y a aussi des fonctions liées au système comme std::thead::detach. Et puis, il y a quasiment toutes les fonctions de std::filesystem qui ont deux versions : une avec exception et l'autre avec un code d'erreur.

Bref, affirmer que la bibliothèque standard utilise les exceptions dans des cas limités est erroné. Elle utilise les exceptions pour les cas exceptionnels, ce qui est la raison d'être des exceptions.

C'est fondamentalement différent.

Dans le système par répartition, tu paies les retraites de l'instant n avec une partie de la production de l'instant n (via des cotisations sociales). On considère que c'est la production qui doit payer pour les travailleurs (maladie, vieillesse, chômage). Donc tu n'as à t'occuper que de l'instant n (même si en vrai, tu peux essayer de faire des projections démographiques pour voir si ça va continuer à fonctionner). La cotisation sociale t'ouvre des droits.

Dans le système par capitalisation, t'as intérêt à serrer les fesses, parce que tu mets de côté à l'instant n pour payer ta retraite à l'instant n + 20 ans (en moyenne). En attendant, ben ça alimente la bulle financière qui peut éclater à tout instant (et en 20 ans, elle éclate quelques fois) et du coup, ça te ruine tout ton pécule régulièrement.

Moi je propose qu'on sacrifie tous les baby-boomers, comme ça ils ne coûteront rien. Et sinon, plus sérieusement, si François Lenglet avait des choses intéressantes à dire, ça se saurait depuis le temps. Beaucoup de ses bouquins partagent le même genre de titre racoleur :

• La crise des années 30 est devant nous, 2007
• Qui va payer la crise ?, 2012
• Tant pis, nos enfants paieront, 2016

euh ouais, non, moi je trouve pas ca normal que ma gamine paie pour moi. Je met mes cacahouètes de cote, pas envie d'être un boulet pour elle, ca marche pas dans ce sens la…

Indices : cotisation sociale, retraite par répartition

En fait, ça ne le dérange pas que les gens compilent leur version chez eux. Mais il ne veut pas de redistribution.

En fait, en cherchant un peu plus, on comprend un peu mieux le pourquoi du comment dans la FAQ:

If Aseprite is open source, how is that you are selling it?

Aseprite started being open source since its very beginning in 2001, and we would like to keep it in that way. You can download its source code, compile it, and use it for your personal purposes. You can make commercial art/assets with it too. The only restriction in Aseprite EULA is that you cannot redistribute Aseprite to third parties.

In June 2014, when Aseprite v1.0 was released, we enter into this new world of selling open source software. And its lead developer is working full-time on Aseprite since March 2015.

C'est la dernière phrase qui est importante. Il flippe. Il veut simplement contrôler la redistribution pour pouvoir faire de l'argent. Argument classique, même si complètement erroné, à mon avis.

… dit le gars qui développe un soft libre sur un OS non-libre (alors que là, pour le coup, il y a le choix).

J'adore ce genre de réponse. Avant on nous vendait systemd comme un sysinit killer qui allait tout mieux faire, bien proprement et qu'on était vraiment des dinosaures à vouloir encore rester avec sysinit. Là, on est passé à un stade où on doit accepter d'avoir les mêmes bugs (parce que c'est un bug) que sysinit. Tout changer pour que rien ne change. D'autant plus que la réponse ne correspond pas à la question. On s'en fout qu'il y ait les mêmes problèmes avec sysinit. On l'a enterré sysinit (ou presque), le problème là il est bien dans systemd.

Personnellement, si je devais choisir un moteur, je prendrais Godot.

Et pour le reste, ce n'est pas en gérant les derniers gadgets à la mode (les modes passent et un jeu libre a vocation a durer dans le temps) qu'un jeu libre se démarquera mais en réalisant un jeu avec un excellent game design et sur une niche peu exploité par les AAA. Le mauvais choix typique serait de vouloir faire un FPS, marché saturé par des gros titres. Un bon exemple, c'est Wesnoth qui s'est placé sur la stratégie tour par tour.

Tu peux me contacter à l'adresse mail indiquée ici

Houla, il faut que je vois si c'est techniquement possible. J'habite un peu à l'autre bout de la France :)

Ouais, en gros, tu expliques qu'avec ce CD, tu ne fais que perpétuer activement tous les clichés sexistes de nos sociétés. Tu véhicules tous ces clichés en toute connaissance de cause sous prétexte que c'est comme ça. J'avais donc bien compris.

Si jamais un sondage fait proprement dit qu'un certain groupe possède une préférence (et ce de manière significative) mais que tu n'expliques pas de manière « objective », tu vas simplement nier son existence ?

Tu n'as pas cité ma phrase en entier et notamment la partie la plus importante : du fait de leur sexe. Je ne nie pas qu'un groupe puisse avoir des préférences (heureusement) mais lier ces préférences à leur sexe est une autre chose. Le fait que le groupe interrogé ne contiennent que des filles ne permet absolument pas de dire que les filles, de manière générale, préfèrent ces jeux. Dit autrement, qu'est-ce qui explique qu'une fille, c'est-à-dire un individu avec des chromosomes XX, préfère ces jeux plutôt que d'autres ? Est-ce vraiment le fait qu'elle ait des chromosomes XX ou alors c'est tout autre chose ?

Admettons, il y a eu un sondage : sur combien de personnes ? est-ce que le panel était représentatif ? est-ce que depuis 2011 la situation a évolué ? Mais même si tout était nickel de ce point de vue (ce que je ne crois pas), il n'y a aucune raison objectives que les filles prises dans leur ensemble préfèrent certains jeux à d'autres du fait de leur sexe. Ça n'a aucun sens.

Une grande partie de l'industrie est passée à des langages plus hauts niveaux, comme Unity+C# (j'ai quand même regardé rapidement et il semble bien que leur API parle d'exceptions, comme ici).

Deux choses. Premièrement, dire qu'une partie de l'industrie est passée à Unity+C#, c'est un peu trop fort je pense. Il y a probablement autant de jeux sous Linux que de jeux commercialement viable fait avec Unity. En revanche, si on parle en termes de projet à peine commencé, là oui Unity est devant tout le monde. Deuxièmement, d'aucuns diraient que le C# de Unity, c'est très différent du C#, et qu'à part cette Exception, il n'y a pas d'autres traces. Ce qui pourrait s'expliquer par le fait que le cœur de Unity est écrit en C++ et que le C# ne sert qu'à faire du scripting et que les deux systèmes d'exception ne doivent pas collaborer très bien.

Depuis 1989, date du papier, on a un peu plus d'expérience sur l'utilisation des exceptions. Et parmi toutes les entreprises qui utilisent C++, de grands pans refusent les exceptions dont toute l'industrie des jeux vidéos (puisqu'on en parle), et des petites PME du genre Google qui doit avoir une des plus grosses bases de code en C++ au monde.

Vulkan vient de sortir, il est disponible à peu près nulle part. Dans les arguments pour le choix de OpenGL ES 2, j'ai précisé qu'il était suffisamment vieux pour être présent quasiment partout. C'est un critère important.

À l’utilisateur de récupérer l’exception.

Ça, ça finit toujours en exception non-rattrapée et qui finit dans main…

J'ai modifié mon code pour enlever cette spécialisation (je m'en servais pour initialiser RenderStates) et je l'ai remplacé par une autre fonction avec un nom différent pour garder le constexpr.

J'ai pushé dans la branche develop si tu veux tester.

Je réponds sur le début de ton message.

Est-ce que passer par Thor ne permettrait pas de compléter la SFML sans devoir forker ou créer une bibliothèque alternative ?

Thor, c'est un peu comme les classes que j'avais fait au début, ça vient en plus avec tous les avantages et inconvénients (une dépendance de plus). Mais si les classes de Thor étaient si bien, pourquoi ne pas les avoir intégrées dans SFML directement ? C'est ça que je ne comprends pas. En l'occurrence, dans Thor, il y a pas mal de fonctionnalités que j'ai aussi dans mes classes ou que j'ai mis dans gf. C'est donc qu'il y a bien un besoin et donc, ça devrait être directement dans SFML. Et du coup, c'est directement dans gf.

Tu sembles très porté sur le C++, mais as-tu tout de même ne serait-ce que regarder la possibilité de faire un port pour d'autres langages ?

Pour les bindings, il faut déjà avoir une API relativement stable. Or, pour l'instant, rien n'est stable, tout peut bouger. Après la version 1.0, on verra.

Tu utilises quelle version de GCC ?

Il faut que je regarde de plus près parce que mon code n'est peut-être pas valide (c'est ce que semble dire le message d'erreur). Je vais essayer de corriger ça assez vite.

On peut voir ça comme ça. Pour l'instant, ça se destine plutôt à des jeux qui visent le bureau (Windows, Linux, etc). Et je ne me sens pas du tout en concurrence avec OpenFL, le public développeur cible n'est pas le même je pense.

En fait la question du fork aurait pu se poser quand tu t'es rendu compte que SFML était incomplet par rapport à tes besoins, avant que tu ne décides de laisser tomber SFML. Enfin, moi je me serai posé la question, après je ne sais pas du tout si ça aurait été une bonne solution.

Disons que quand j'utilise une bibliothèque et qu'il me manque des choses, mon premier réflexe n'est pas de forker mais de compléter autant que je peux. Parce que maintenir quelques classes supplémentaires et maintenir un fork, ce n'est pas vraiment le même travail ni la même philosophie. Les classes supplémentaires, tous ceux qui utilisent la bibliothèque de base peuvent les utiliser. Tandis qu'un fork impose un choix à l'utilisateur.

Par contre je ne comprends pas trop ta démarche pour arriver à ce résultat. Pourquoi ne pas avoir simplement forké SFML, pour y ajouter les bouts d'API dont tu avais besoin ? Cela ne t'aurait pas non plus empêché de moderniser le code.

Parce qu'au départ, ce n'était pas clair que j'allais reprendre l'API de SFML. Mais au fur et à mesure, en y réfléchissant, je me suis dit que c'était une bonne solution. Mais du coup, il était trop tard, et j'ai préféré rester sur mon code plutôt que de repartir d'un fork.

Note bien aussi que gf ne clone que l'API graphique de SFML. SFML contient aussi un module réseau et un module audio que je n'ai pas du tout repris. Ils sont assez indépendants et peuvent être utilisés conjointement avec gf. Sur ces deux modules, je n'aurais rien apporté du tout tandis que sur le module graphique, je pense avoir apporté suffisamment pour que ça soit considéré comme plus qu'un fork.

Autre chose, pour des jeux 2D pourquoi passer par OpenGl et pas par les fonctions de la SDL?

Les fonctions 2D de la SDL sont assez limitées et sont des fonctions en C. Je pense offrir bien plus de fonctionnalités et en orienté objet. De plus, j'ai une meilleure maîtrise du code bas niveau OpenGL en passant directement par OpenGL et donc, je peux optimiser certaines opérations.