rewind a écrit 3429 commentaires

Dans le cas de SDL et de SDL_RenderCopyEx, chaque dessin de tuile se traduit par un appel OpenGL même si toutes les tuiles partagent la même texture. Dans le cas de SFML, si toutes tes tuiles partagent la même texture, tu fais un seul appel OpenGL pour toutes les tuiles.

Ou ma première animation réalisée grâce à ce merveilleux outil qu'est nanimstudio ;)

Pour la première «release» d'une pré-démo version 0.0, j'aimerais bien intégrer les nanim dans le jeu (et comme le format est plutôt bien foutu, ça devrait aller assez bien), ainsi que quelques autres trucs et ensuite, je mets ça en ligne (disons dans deux-trois semaines). J'ai déjà le sprite qui bouge bien dans nanimstudio. Plus qu'à.

Qu'appelle-tu un sur-ensemble de SDL2? La SFML est basée sur OpenGL, pas sur SDL.

En terme de fonctionnalités, pas en terme de comment c'est implémenté. Dans le bout de code que j'ai en SDL, voici ce que j'utilise et l'équivalent en SFML :

• SDL_CreateWindow() : sf::Window
• IMG_Load() + SDL_CreateTextureFromSurface() : sf::Texture
• SDL_RenderClear() + SDL_RenderPresent() : window.clear() + window.display()
• SDL_PollEvent() : window.pollEvent()
• SDL_RenderCopyEx() : sf::Sprite

En fait, le seul truc que je n'ai pas vu côté SFML mais qui existe côté SDL, c'est l'ensemble SDL_SetTextInputRect, SDL_StartTextInput, SDL_StopTextInput.

Bon, résultat des courses, après avoir fait quelques essais avec SFML2, je l'adopte. Les arguments qui m'ont convaincu :

• elle est un poil plus haut niveau que la SDL2 et donc, il y a tout un tas de trucs bien foutus que je ne redévelopperai pas
• comme c'est un surensemble de SDL2, au pire, je peux revenir à SDL2 et redévelopper les bouts qui manquent
• le développement a l'air assez actif, donc je ne suis pas trop inquiet pour la pérennité de la bibliothèque
• tout est intégré de base (graphique, sons, texte, image, réseau) donc pas besoin d'aller voir ailleurs
• le code de la bibliothèque est plutôt bien fait, ce qui fait que je pourrai contribuer si jamais j'ai un souci

En plus, comme il n'y a pas encore de paquet Debian, j'ai du la compiler et l'installer à la main. Et bien, ça a été très vite fait : cmake, make, make install et en moins de 2 minutes, j'avais un truc prêt à l'emploi. Et comme les .pc sont fournis, c'est encore plus facile à intégrer au build system.

C'est triste ton avis sur Packard Bell…

Hormis les supposées perfs, les EFL n'ont rien à proposer en comparaison de SDL ou SFML. Quand on aura la même facilité à utiliser les EFL (c'est-à-dire avec des tutoriels, de la documentation, des examples sur des problèmes concrets liés aux jeux 2D), on en reparlera. D'ici là, on va continuer à utiliser nos pauvres bibliothèques lentes.

Wormux ou un autre de ces clones de Worm qui met une machine a genoux alors que l'on pouvait jouer a l'original sur un PC d'il y a plus de 15 ans.

Tu compares des choses pas comparables en terme de graphismes et de résolution d'écran…

Battle for Wesnoth qui prend des plomb sur rpi.

Je dois avouer que le rpi n'est pas une plateforme cible pour moi et que si ça ne marche pas là dessus, je n'en ferai pas des cauchemars.

Les performances sont juste ignorees et relegues a Moore qui resoudra forcement le probleme…

Ou alors, les jeux libres ne jouent pas à concurrencer les jeux qui exploitent à fond les cartes graphiques modernes. Ils tablent plutôt sur des concepts un peu en dehors des canons du genre, ou sur un gameplay original. Bref, sur l'imagination plutôt que sur la performance.

Au final, le desktop et les jeux en particulier de Linux aujourd'hui consomme plus de ressource qu'il ne devrait et n'a aucun avantage competitif avec le logiciel proprietaire.

Là encore, tu compares de choses pas comparables. Sur Linux, il y a essentiellement des jeux amateurs (dans le sens noble du terme) fait le plus souvent par une personne (sauf quelques exceptions notables). Dans le logiciel propriétaire, il y a des équipes d'au minimum 5 à 10 personnes pour les jeux indie et jusqu'à plusieurs centaines pour les gros titres.

Je pense que tu sous estimes les bibliotheques de plus haut niveau en te disant que rajouter une couche ne peut pas etre une optimisation, mais une source de ralentissement et de lourdeur… Et pourtant…

Les EFL ne répondent pas à mon problème. Ou plutôt répondent à mon problème supposé qui serait la lenteur (mais ce n'est pas un problème pour l'instant). Ce que je cherche, c'est une bibliothèque qui me permettent de faire les choses simplement. Pas rapidement, simplement ! Je ne considère pas que les EFL sont trop haut niveau, au contraire, je les considère trop bas niveau ! Quand je vois la SFML, j'ai plein de fonctionnalités attendues par un jeu 2D, avec de la documentation et des exemples simples. Et ça me suffit amplement pour l'instant ! Quand je serai devenu une star interplanétaire et multi-millionaire grâce à mon jeu, et que celui-ci sera devenu un gros bloat tout lent, j'envisagerai une solution. D'ici là, je me contente de régler les petits problèmes que j'ai.

… quand ton projet prendra de l'ampleur.

Oui mais pour l'instant, il fait quelques lignes, il permet de bouger un pauvre sprite sur un écran. Je ne vais pas m'amuser à gérer des problèmes que je n'ai pas encore ou que je n'aurai jamais.

Et comme tu le dis, le manque de documentation est un frein majeur. Avec SDL ou même SFML, il y a une tonne de documentation, de tutoriels et de bouts de code pour faire tout un tas de choses spécifiques aux jeux.

Après réflexion et lecture des nouveaux commentaires, je confirme : essaie de trouver un moteur de jeux existant que tu peux utiliser.

Oui mais non. J'ai lu pas mal de choses ces dernières semaines à propos de la création de jeux. Et il y a quelques principes que je retiens : le principal dans un jeu, ce n'est pas le code (et donc pas le moteur) mais le contenu. Niveau code, je veux un truc simple, pas une usine à gaz. Le Bear Engine a l'air complet mais il est beaucoup trop complet pour moi (et en plus, plusieurs aspects ne conviennent pas à ce que je veux faire).

J'ai regardé pas mal d'autres moteurs de jeux et pas mal de bibliothèques (dont des moteurs physiques), mais à chaque fois, j'ai l'impression de sortir un char d'assaut alors que j'aurais besoin d'un petit sous-ensemble indépendant. Sans compter que ces bibliothèques sont assez invasives sur l'architecture globale du reste du jeu. Mon but est aussi de faire des choses simples côté code et d'investir sur le gameplay et l'univers du jeu.

Mais je vais te prendre au mot et renverser la question, as tu un exemple de jeu libre avec un bon scene graph et portable en tete (OpenGL, OpenGL ES et software) ?

Vu la quantité industrielle de jeux utilisant SDL comparé aux deux démos que tu me montres, je crois que le choix est vite fait.

Plus j'y pense et plus je me dis que Qt n'est vraiment pas fait pour ça. D'ailleurs, dans la description de Nikki and the robots, ils précisent : «For the rendering of the 2D-graphics (as well as for some other things) we use Qt, more precisely the hardware accelerated OpenGL® backend.» Donc, en gros, ils ont utilisé OpenGL (parce que bon, OpenGL dans Qt, ça se rapproche beaucoup d'OpenGL, moins les différences entre les différentes versions d'API).

Pour moi, mais je peux me tromper, les deux catégories d'API n'ont pas du tout la même utilité et pas les mêmes prérequis, même si de loin dans le brouillard on peut se dire que c'est pareil. Qt et les EFL doivent surtout afficher des choses essentiellement statiques et passent l'essentiel de leur temps… en dehors de la bibliothèque à attendre un événement. Quand on regarde un bureau qu'on n'utilise pas, quasiment rien ne bouge. À l'inverse, un jeu passe le plus clair de son temps à calculer des entités qui bougent, même sans intéraction de l'utilisateur, et le reste (affichage et événements utilisateur) doit donc être très rapide pour laisser un maximum de temps à la logique du jeu. Il y a eu peut-être quelques convergences récemment mais on est loin de pouvoir substituer les unes aux autres.

As-tu déjà essayé de faire un jeu avec les EFL ou Qt ? Connais-tu un jeu fait avec les EFL ou Qt ? Parce que je me dis que si tu as raison, on devrait avoir des exemples, mais je n'en connais pas. Et je dis bien un jeu, pas un moteur 2D.

Je pense, à l'inverse de toi, que Qt ou les EFL ne sont pas adaptés pour faire des jeux. Oui, on peut avoir quelques widgets dans un jeu, mais on n'a pas besoin d'une usine à gaz pour ça.

Sinon on peut choisir un toolkit graphique qui se charge de faire l'abstraction graphique pour toi.

Il ne s'agit pas que de faire l'abstraction graphique, il faut savoir ce qui se passe dans la boucle et avoir une maîtrise du temps que ne permettent pas, à mon avis, les toolkits généralistes.

Faire un moteur de rendu 2D

Mon but n'est pas de faire un moteur de rendu 2D mais de faire un jeu. Dans SDL et SFML, tout est disponible pour faire le rendu, je n'ai qu'à indiquer où mettre les objets, ce qui me semble être le minimum d'intéraction pour un jeu.

À mon avis, tu sous-estimes la SDL et SFML et tu surestimes les EFL pour les jeux. Montre-moi comment charger une texture dans la mémoire graphique avec les EFL (parce que j'ai cherché 5 minutes, j'ai pas trouvé, c'est une fonctionnalité de base dans SDL2 et SFML2), et je reconsidérerai les EFL. Pour Qt, d'après ce que je vois, il faut passer directement par OpenGL. Non merci.

Sans même parler de netbook, est-ce tu as observé des différences pour ton jeu entre Linux et Windows ou entre différents drivers graphiques ?

je pense que tu trouvera quand même des trucs intégrés dans SFML que tu aura à faire à la main coté SDL

Oui, c'est mon impression et je n'ai pas envie de refaire si c'est déjà fait et que ça marche.

Par contre les arguments qui t'ont été donné en faveur de SDL sont vrais aussi: c'est très portable (Hurd, haiku, android, …), c'est sérieux alors qu'à coté Laurent qui développe la SFML est pas irréprochable, il a a arrêté de supporter la 1.6 avant que la 2.0 sorte du stade beta, il a retardé la sortie pour une histoire de logo, …

Cette bibliothèque est de plus en plus utilisée, j'ai l'impression. Ce qui fait que, si un jour l'auteur fait n'importe quoi, je pense qu'un fork verra le jour, comme ça s'est déjà passé pour d'autres projets.

Même pour de la 2D simple, c'est difficile de faire un jeu qui tourne vraiment bien sur un netbook.

On verra bien. J'espère ne pas trop avoir à souffrir de ces ralentissements. Est-ce que tu les observes aussi bien sur Windows que sur Linux ?

Il y a les ViewPort qui semble plus ou moins identique, peut être que c'est moins puissant en terme de fonctionalité ?

Ce n'est qu'une partie de la fonctionnalité.

Justement avec SDL2, c'est aussi en hardware (utilisation de SDL_Texture au lieu de SDL_Surface)
Et on y trouve les fameuses rotations (https://bugzilla.libsdl.org/show_bug.cgi?id=1308) qui étaient en soft en version 1.2

Oui, on peut utiliser SDL2 pour implémenter une fonctionnalité similaire, je ne dis pas le contraire. Mais ce n'est pas immédiat.

J'avoue ne pas avoir trop compris de quoi il s'agissait (rapport avec les tile map?), mais il est question de "Position, rotation, scale" qui est justement integré dans RenderCopyEx de SDL2 (ainsi que le flip)

Rien à voir. Là, tu définis tout un tas de figure associé à la même texture (par exemple des tuiles) et tu envoies tout d'un coup et tout est dessiné en une seule fois. Avec SDL, tu dessines chaque tuile indépendamment, même si tu utilises la même texture.

Nous sommes d'accord. Et l'architecture que j'utilise offre de bonnes opportunités si jamais il y a besoin.

Vu que l'on ne sait pas le type de jeu dont il est question ici,

Je garde le suspense ;)

Merci, tu confirme l'impression que j'avais par rapport à ces deux bibliothèques. Notamment sur l'aspect un peu plus «bas niveau» de SDL2.

Concernant la portabilité, SFML2 est disponible sur Linux, MacOSX et Windows. Ça fait déjà pas mal et ça me suffit.

En plus de ce que dit devnewton, j'ajouterai que ce n'est pas le seul moyen de mettre dans des threads séparés, il y a d'autres architectures qui permettent également de faire du multi-thread assez facilement. Et que tenter d'optimiser au départ, ça n'est jamais une bonne idée, je ferai du multi-thread quand j'en aurai besoin.

Mais sachant qu'un ordi est capable de calculer et d'afficher des millions de triangles et que j'en suis très très loin, je pense que je n'en aurai pas besoin dans l'immédiat. À l'heure actuelle, j'en suis plutôt à mettre un sleep dans la boucle principale pour que ça n'aille pas trop vite.

Tu pourrais concevoir une architecture qui sépare parfaitement la gestion de l'affichage et des entrées utilisateurs de tout le reste du jeu.

Ça pourrait se faire mais ça serait assez difficile je pense. Disons que d'un point de vue conceptuel, c'est assez intéressant, mais dans la pratique, c'est quand même plus simple quand on mélange un peu tout. Et qui dit plus simple dit plus rapide à développer (le temps est l'ennemi du développeur seul).

En tout cas, vu que t'as déjà touché à la SDL2 et que tu sembles être tenté par SFML (je n'ai jamais touché à l'un des deux), je te conseillerais de partir sur SFML avec une bonne architecture. Si tu te rends compte que finalement c'est moins bien que la SDL pour ton utilisation, tu peux repartir sur de la SDL sans impact sur la totalité du code.

Ça, c'est un argument qui me plaît :)

Je pense qu'aujourd'hui la communication doit faire partie d'un projet dès le début.

J'ai déjà pensé à ça. J'envisage de faire une démo dès que j'aurai quelque chose de montrable (jouable avec quelques fonctionnalités de base).

gagner une visibilité dont on récoltera très vite les fruits lors d'une campagne de crowdfunding (à lancer aussi très tôt).

Pour l'instant, je n'image pas passer par du crowdfunding.

Tu as quelques exemples de trucs qui te semble necessaire et absent de SDL2 (en incluant sdl_image, sdl_mixer et sdl_ttf biensur)

Oui, j'ai quelques exemples:

• Les View qui permettent de simplifier la correspondance entre coordonnées du jeu et coordonnées de l'écran.
• les transformations simples d'entité (et ce n'est pas fait en software à la fin alors que si je devais le réimplémenter avec SDL, ça serait fait en software).
• Les vertex array qui permettent de dessiner rapidement plein de choses. Très pratique pour les tile map (l'exemple est donné sur la page).