Gamedev Framework (gf) est un framework de développement de jeu vidéo 2D en C++14. Il est basé sur SDL et OpenGL ES 2.0 et s'inspire très largement de l'API du module graphique de SFML avec quelques différences mineures et surtout en ajoutant des fonctionnalités non-présentes dans SFML.
La version 0.7.0 est sortie il y a trois mois, le 14 janvier 2018. Elle contenait assez peu de nouveautés étant donné le peu de temps que j'avais pu y consacrer dans les trois mois précédents. On trouve toutefois un algorithme pour calculer des enveloppes convexes (Quickhull), et surtout un passage à C++14 au lieu de C++11. C++14 est une version mineure par rapport à C++11 qui améliore le quotidien (genre make_unique ou constexpr étendue) et les compilateurs majeurs permettent de compiler en C++14. C'est même la version par défaut dans les GCC et Clang récents. Donc aucune raison de ne pas l'utiliser.
La version 0.8.0 est sortie le 14 avril 2018. Il y a plusieurs gros morceaux dans cette version:
- Une bibliothèque de sérialisation basée sur le format MessagePack. L'idée est de ne plus avoir que ce format en entrée pour toutes les données structurées qu'on aurait plutôt tendance à écrire en JSON ou XML (ou autre). Du coup, j'ai déjà fait un petit outil qui permet de manger du JSON et qui crache du MessagePack. La sérialisation permet aussi de pouvoir créer des sauvegardes dans les jeux.
- Une triangulation de Delaunay basée sur l'algorithme de Bowyer-Watson. La triangulation de Delaunay peut être utilisée dans certains algorithmes de génération procédurale, notamment pour construire des cartes.
- Deux structure pour faire de l'indexation spatiale, c'est-à-dire organiser des objets de l'espace (ou du plan) pour pouvoir y accéder très rapidement. Ces deux structures sont Quadtree d'une part et une variante de R-tree d'autre part. Le code n'est sans doute pas encore suffisamment efficace mais c'est un début.
- Des widgets simples pour les interfaces à l'intérieur du jeu. Ce sont principalement des boutons qu'on peut appuyer. Il reste sans doute un peu de travail, y compris au niveau de l'API, mais la base est présente.
En prime, un nouveau jeu a été ajouté. Il a été conçu lors de la Global Game Jam 2018, et il s'appelle Krokodile. Le but est de croiser des espèces assez folkloriques pour obtenir un crocodile entièrement vert.
# bravo
Posté par arnodevo . Évalué à 4.
Un si beau travail, un beau post et zéro commentaires, c'est dommage. Mai c'est souvent comme ça, de mon expérience quand on post et qu'on n'a aucun commentaire. C'est qu'on a bien écrit et tout dit. Du coup il n'y a rien à troller et ni à critiquer.
[^] # Re: bravo
Posté par rewind (Mastodon) . Évalué à 6.
Ouais enfin, je suis un habitué du genre (voir les précédents journaux dans le même genre). Ceci dit, je te remercie beaucoup pour ton commentaire d'encouragement.
# Testé tous les jeux :)
Posté par anaseto . Évalué à 5.
Voilà, j'ai testé tous les jeux :) J'ai pas trop d'expérience en C++, mais j'aime bien les jeux 2D donc ça fait plaisir de voir des bibliothèques libres et qui plus est ça a l'air solide et pas gourmant en ressources.
Juste deux petits soucis lors de la compilation (sous OpenBSD, clang 5.0.1), je ne saurais pas dire exactement pourquoi vu mon manque d'expérience en C++.
Première erreur :
Pour cette première erreur, j'imagine que glibc doit inclure
<cstddef>dans un autre header de façon non standard.Deuxième erreur :
[^] # Re: Testé tous les jeux :)
Posté par rewind (Mastodon) . Évalué à 2.
Merci pour ce retour !
Pour la première erreur, je vais la corriger, c'est bien une vraie erreur.
Pour la seconde, c'est un truc bizarre de zlib. Normalement, l'erreur ne devrait pas arriver. En fait, les fonctions et les structures de zlib sont définies sans
const. Mais on peut ajouter desconstpartout où on veut simplement en définissantZLIB_CONSTà la compilation (via-D), ce que je fais dans monCMakeLists.txt. Ici, j'ai l'impression que cette constante n'est pas définie, ce qui provoque une erreur. Est-ce que ça vient d'OpenBSD qui force à ce que la constante ne soit pas définie ? Je vais essayer d'investiguer.[^] # Re: Testé tous les jeux :)
Posté par rewind (Mastodon) . Évalué à 3.
Du coup, j'ai trouvé. La version de zlib utilisée par OpenBSD est un peu trop vieille (version 1.2.3). La fonctionnalité avec le
consta été introduite dans la 1.2.5 (en 2011).Si tu veux patcher proprement, tu peux remplacer la ligne par:
[^] # Re: Testé tous les jeux :)
Posté par anaseto . Évalué à 3.
Ah là là, c'est vraiment pas évident d'être portable ! Ceci dit, d'habitude j'ai souvent bien plus de problèmes lorsque j'essaie de compiler des jeux sous OpenBSD qui sont pas dans les ports, gf s'en sort plutôt bien :)
[^] # Re: Testé tous les jeux :)
Posté par rewind (Mastodon) . Évalué à 3.
Dans gf, la portabilité est assurée par SDL et Boost. Ils font le travail et après, je n'ai plus qu'à utiliser le résultat ;) J'oubliais OpenGL aussi. Ce qui fait que dans gf, je n'ai aucun code spécifique à une plateforme particulière. Et je suis très satisfait de savoir que sous OpenBSD, ça compile et ça fonctionne correctement.
Tiens, d'ailleurs, si tu pouvais faire un petit
gf_infoet me coller le résultat histoire que j'enrichisse mes stats. Ce n'est pas obligatoire, ça donne des informations sur ton système (notamment les versions utilisées pour compiler), mais ça m'aidera à voir l'étendue des configurations possibles.[^] # Re: Testé tous les jeux :)
Posté par anaseto . Évalué à 3.
Ça m'encourage aussi à penser qu'il y a probablement pas trop de bugs du genre buffer overflow — des logiciels qui tournent “normalement” sous Linux ont tendance à faire segfault sous OpenBSD du fait des protections mémoire du noyau (c'est le genre de trucs qui m'arrive parfois, par exemple à un moment une version d'inkscape était inutilisable sous OpenBSD).
Et voilà le
gf_info!Le seul truc qui m'a fait bugguer, c'est le
Platform: Linux, mais j'ai découvert qu'en fait c'est normal :[^] # Re: Testé tous les jeux :)
Posté par rewind (Mastodon) . Évalué à 2.
Super !
Moi ce qui me chagrine là dedans, c'est le vide après «Base path». Mais bon, sur un système Unix, ce n'est pas très grave.
[^] # Re: Testé tous les jeux :)
Posté par anaseto . Évalué à 2.
Sur OpenBSD il n'est en effet pas possible d'avoir accès au répertoire du binaire exécuté, du coup en général les packageurs patchent si nécessaire avec un chemin en dur.
[^] # Re: Testé tous les jeux :)
Posté par rewind (Mastodon) . Évalué à 2.
Dans mon idée, cette fonctionnalité sert surtout pour les systèmes où l'installation est… chaotique. Sur un système Unix, tout est bien rangé donc on sait où on va retrouver ses assets. Mais sur un Windows, c'est plus compliqué et mettre tout dans le même répertoire est une solution à peu près correcte. Mais ça implique de savoir où se trouve le binaire.
Je ne savais pas que sur certains systèmes, cette fonctionnalité étaient absente.
[^] # Re: Testé tous les jeux :)
Posté par anaseto . Évalué à 3. Dernière modification le 25 avril 2018 à 12:16.
La plupart des OS passent par procfs, mais pas tous, d'autres ont un syscall. Sur OpenBSD il n'y a ni l'un ni l'autre, même si il y a un moyen détourné d'y arriver : par exemple en Go ils récupèrent le dossier courant en début d'exécution, puis déduisent ensuite le chemin de l'exécutable à partir du premier argument du programme et suivant les cas déterminent s'il faut aller jusqu'à chercher dans
$PATH(juste le nom de la commande, auquel cas c'est plus forcément fiable si l'environnement a changé) ou non (chemin complet ou relatif, auquel cas c'est fiable).Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.