rewind a écrit 3425 commentaires

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.

C’est un peu dommage qu’stp::optional arrive si tard

Il y a boost::optional en attendant.

Faut maintenir deux fois plus de code? Ou c’est juste la fin de la fonction qui change?

Non, il y a une fonction commune aux deux versions qui est appelée et en fonction envoie une exception ou renvoie un code d'erreur.

Pour les classe de type vecteur mathématique, l'usage est de fournir un pointeur sur les données qui doivent être contiguës. Par exemple: dans eigen ou dans glm. Outre le fait d'assurer l'interopérabilité avec les autres bibliothèques du même genre, ça permet aussi d'utiliser directement les fonctions OpenGL qui attendent des données contiguës.

De mon expérience de développeur java

Les exceptions en C++ n'ont à peu près rien à voir avec les exceptions en Java, hormis le principe général. Déjà, le fait qu'en C++, elles ne soient pas déclarées dans le prototype de la fonction rend leur utilisation très pénible, contrairement à Java. Ensuite, beaucoup de projets C++ découragent l'utilisation des exceptions, parce que, sur certaines architectures, elles ont un coût non-négligeable.

En C++, on va avoir std::optional en C++17 qui joue exactement le même rôle et qui marche avec toutes les classes, pas uniquement les pointeurs.

À noter aussi que dans std::filesystem, il y a les deux. Pour chaque fonction, on a une version avec un code de retour (en dernier argument) et une fonction sans code de retour mais qui lève une exception. De cette manière, chacun fait bien comme il veut.

C'est bien un des seuls cas où, effectivement, une exception serait justifiée. Actuellement, dans ce cas, je renvoie un pointeur (et donc un pointeur null si l'objet n'existe pas). Mais la question reste la même : où gérer l'exception ?

Oui et non.

C'est un peu plus qu'une API de dessin. Mais après, ça n'impose pas vraiment de structure comme pourrait le faire un moteur de jeu. Ceci dit, il est tout à fait possible d'avoir des classes pour fournir un scenegraph, je crois qu'il y a tout ce qu'il faut. Ça se fera peut-être dans le futur.

En attendant, il y a la classe gf::Entity qui permet d'ordonner les entités (via la classe gf::EntityContainer et donc d'avoir du z ordering. C'est basique mais ça marche bien (je l'utilise systématiquement dans mes jeux).

Je ne sais pas lire rapidement les 1600 lignes de ta classe Vector elle fait quoi du coup ?

C'est un vecteur au sens mathématique, un truc avec des coordonnées (2D, 3D et 4D principalement). Tandis que le std::vector est un tableau dynamique.

Un pointeur ou un itérateur ?

Un pointeur. Plus pratique pour échanger avec du C. Et un pointeur est un itérateur (mais l'inverse est faux).

Je redis : dans le cas où le seul try/catch est dans main, ça ne fait aucune différence : arrêt immédiat pour l'utilisateur. Donc je repose ma question, où est-ce qu'on rattrape l'exception ?

Entre mon assert et l'exemple avec exception plus haut, il n'y a aucune différence, ça crashe le programme. Et je suis d'accord, c'est rédhibitoire. Maintenant, c'est aussi pour ça que je préfère des codes de retour explicite.

Ceci dit, les assert ont une utilité pour vérifier que tout se passe correctement, sous-entendu si ce n'est pas le cas, c'est une erreur de programmation qui doit être corrigée.

Non, je préfère :

int c()
{
    assert(!a_failure);
    return 123;
}

int b()
{
    return c() * 456;
}

int main()
{
    std::cout << b() << std::endl;
}

Sur les exceptions, je crois qu'on ne sera pas d'accord. Déjà, tu parles de lancer une exception mais jamais de la rattraper. Si tu ne la rattrapes jamais, autant mettre un bon vieux assert ou un abort et on n'en parle plus. Si tu la rattrape, j'aimerais bien savoir où : si c'est pas très loin, utiliser une exception ne sert à rien par rapport à un code de retour ou un booléen pour gérer un truc immédiat; si c'est très loin, alors tu ne peux rien faire de vraiment très sérieux à part quitter le programme.

J'ai regardé rapidement ton projet, pour le ResourcesManager, tu pourrais retourner des std::unique_ptr plutôt que des pointeurs bruts. Ça marquera complètement l'ownership et tu pourras toujours retourner un std::unique_ptr null si l'objet n'est pas trouvé :)

Houla non, malheureux ! Justement, l'intérêt du RessourceManager, c'est que c'est lui qui a la responsabilité du pointeur, il ne doit absolument pas la donner à l'utilisateur ! Ça lui permet de maintenir un cache des ressources et donc, de ne pas charger des choses en plusieurs exemplaires inutilement.

Pourquoi avoir implémenter tes propres conteneurs plutôt qu'utiliser ceux de la stl ou d'une bibliothèque comme eigen ?

Quels conteneurs ? Vector ? Ça n'a rien à voir avec std::vector. Et eigen est une très bonne bibliothèque mais un peu trop vaste pour un framework de jeu. Quite à avoir une dépendance externe, j'aurais choisi glm mais avoir le minimum de dépendance est aussi un avantage.

Tu a créé des ponts entre certains ?

J'ai fait tout ce que je pouvais pour que ça soit facile d'importer et d'exporter les données pour ce genre de bibliothèque. En particulier, prendre en paramètre un pointeur sur les données et fournir un pointeur sur les données.

pas d'exception

Ça, ça ne va pas changer, je déteste les exceptions en C++. Et je ne vois pas bien où je pourrais en mettre.

pas de RAII

En interne, il y a quelques classes qui utilisent RAII. Maintenant, où est-ce que tu en verrais dans l'API publique ?

Ça ne s'articule pas, c'est complètement indépendant. Le seul point commun que je vois est que ça s'appuie sur SDL2, mais bon, c'est très maigre.

je crois qu'il n'a même pas incorporé les nouveautés du C++11

Je crois que ça vient doucement mais comme tu dis, c'est très frileux. Il est resté sur des supposition qui datent de l'époque où il a commencé SFML, soit il y a bientôt 10 ans maintenant.

Tu confonds données et service ! Ils pourraient très bien reprendre les données (libres) de OSM et monter leur propre service avec. Pour GrassHopper, je ne connais pas, donc je ne dis rien.