rewind a écrit 3425 commentaires

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).

Tout dépend bien entendu de ce que tu veux faire avec. Un jeu ? En 2d ? En 3d ? Avec OpenGL ou du rendu pur logiciel ?

Un jeu. En 2D. Je ne veux pas savoir comment est fait le rendu, la bibliothèque s'en occupe. Et je ne veux pas utiliser OpenGL directement.

la SDL n'excelle pas vraiment pour l'affichage : elle ne propose qu'un rendu matériel que depuis peu de temps.

Je pense que la version 2 de la SDL améliore vraiment les choses de ce point de vue. La différence entre ce qui est fait sur la carte graphique en accéléré et ce qui est fait en RAM en software est beaucoup plus explicite.

Ainsi, pour développer un jeu 2d, je conseillerais plutôt la SFML.

Ne me tente pas !

Si tu te lances dans un jeu, il y a une tâche très consommatrice de temps que l'on néglige souvent: les releases.

Je prend note.

il faut pouvoir sortir des binaires pour le maximum de plateformes

Dans un premier temps, si je release des démos, ça ne me dérange pas que ce ne soit pas disponible sur un maximum de plateformes. Mais je ne veux pas me bloquer par la suite, donc le choix est important dès le départ.

les API peuvent changer et ça prends du temps de migrer, surtout si ces API ne maintiennent pas la compatibilité entre deux versions.

Là dessus, c'est bien la raison pour laquelle je regarde des bibliothèques très jeunes et en version 2 : l'API est sans doute meilleure et plus aboutie que la version 1, et elle risque de durer un moment.

Sinon selon le type de jeu que tu veux faire, je te conseillerais des solutions plus facile à releaser: libgdx, playn, html5, pygame, haxe…

Je me sens très à l'aise avec C++, donc je vais laisser de côté Java et les autres langages ;)

Mais du coup, je ne me sens pas plus avancé. Parce que je comprends tout ce que tu dis et j'en étais là il y a peu. Mais quand même, une fois qu'on a regardé l'API de SFML2, on se dit qu'il manque des trucs à la SDL2. Et c'est ça qui m'embête bien.

Oui, c'est une différence, mais ça n'est pas si important. L'existence d'un binding C montre que la différence est essentiellement syntaxique, la SFML utilise assez peu les spécificités de l'orienté objet finalement.

Pas énormément de différence, c'est sur l'essentiel. Mais après, quand tu regardes de plus près, SFML a des trucs intégrés au niveau de la bibliothèque qui sont totalement absents de la SDL.