Bonjour nal,
Les bibliothèques graphiques pour faire des jeux vidéos 2D connaissent actuellement une deuxième jeunesse. En particulier, les deux principales (SDL et SFML) sont sortis en version 2.0 récemment.
La SDL est une bibliothèque C qui gère les aspects graphiques. Elle est sortie en version 2.0. Avec ses petites sœurs (SDL_image, SDL_net, SDL_ttf, SDL_mixer, …), elle permet d'avoir un ensemble à peu près cohérent de fonctionnalités de base pour les jeux. Le paquet Debian pour SDL2 est déjà disponible dans unstable.
La SFML est une bibliothèque C++ qui gère les aspects graphiques ainsi que le son et le réseau. Bref, pareil que la SDL sauf que tout est regroupé en une seule bibliothèque plutôt que d'être éclaté. Elle est sortie en version 2.0 (news en cours de rédaction) et même 2.1. Le paquet Debian pour SFML2 ne devrait pas tarder à arriver dans unstable.
Bref, on voit qu'il n'y a pas énormément de différence entre les deux. Alors la question qui se pose, c'est : laquelle choisir ? Quelles sont les avantages et inconvénients de chacune ?
J'ai un peu joué avec la SDL2 (et avant avec la SDL1.2) mais jamais avec SFML (2 ou 1.6). À lire la documentation de SFML2, il semble qu'il y ait quelques trucs mieux intégré avec SFML qu'avec SDL, comme les View (avec SDL, on doit refaire ce travail à la main, c'est chiant). D'un autre côté, la SDL me paraît être mieux prise en charge (du fait de l'entreprise qui la maintient là où la SFML est maintenue par un gars tout seul). Bref, j'hésite.
Avez-vous un avis sur la question ?
# Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: SDL
Posté par rewind (Mastodon) . Évalué à 2.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Orienté objet ?
Posté par palkeo (site web personnel) . Évalué à 2.
Tu as une bibliothèque C, et une bibliothèque C++, pour moi déjà c'est une grosse différence…
Pour avoir testé assez rapidement les deux, je préfère largement la SFML, mais c'est aussi lié au fait que ce soit de l'orienté objet.
[^] # Re: Orienté objet ?
Posté par rewind (Mastodon) . Évalué à 8.
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.
# Faire le choix du long terme
Posté par devnewton 🍺 (site web personnel) . Évalué à 10. Dernière modification le 01 septembre 2013 à 11:50.
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.
Faire un super jeu qui tourne sur le PC à la maison, c'est bien, mais pour qu'il soit jouer par plus d'une personne, il faut pouvoir sortir des binaires pour le maximum de plateformes. Il vaut donc mieux choisir
javala bibliothèque qui sera la plus portée et la mieux packagée.Un autre point à prendre en compte: la maintenance au cours du temps. Le développement d'un jeu prends plusieurs années, les API peuvent changer et ça prends du temps de migrer, surtout si ces API ne maintiennent pas la compatibilité entre deux versions.
Pour ces deux raisons, je choisirais la SDL. La version 1.2 est partout, est restée stable pendant des années et il y a un guide de migration complet pour la 2.0.
La SFML a l'air d'être une bonne bibliothèque, mais bon voilà l'annonce de la 2.0:
…
Sinon selon le type de jeu que tu veux faire, je te conseillerais des solutions plus facile à releaser: libgdx, playn, html5, pygame, haxe…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Faire le choix du long terme
Posté par rewind (Mastodon) . Évalué à 2.
Je prend note.
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.
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.
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.
[^] # Re: Faire le choix du long terme
Posté par fabien . Évalué à 4.
Tu as quelques exemples de trucs qui te semble necessaire et absent de SDL2 (en incluant sdl_image, sdl_mixer et sdl_ttf biensur)
Je demande par curiosié, parce que vraiment moi je taquine la sdl et il ne m'a rien manqué (du moins, en comptant sur les nouveautés de la version 2, la je trouve qu'ils ont bien completé)
[^] # Re: Faire le choix du long terme
Posté par rewind (Mastodon) . Évalué à 6.
Oui, j'ai quelques exemples:
[^] # Re: Faire le choix du long terme
Posté par fabien . Évalué à 2.
Ce que tu cites me semble plus s'appliquer a SDL 1.2
Il y a les ViewPort qui semble plus ou moins identique, peut être que c'est moins puissant en terme de fonctionalité ?
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
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)
Je sais pas, Peut être que l'utilisation est plus simple avec sfml ?… Mais en tout cas pas "absente" de sdl2.
Après, je dis pas… peut être que c'est mieux à utiliser en sfml qu'en sdl, mais ça reste une question de goût.
[^] # Re: Faire le choix du long terme
Posté par rewind (Mastodon) . Évalué à 3.
Ce n'est qu'une partie de la fonctionnalité.
Oui, on peut utiliser SDL2 pour implémenter une fonctionnalité similaire, je ne dis pas le contraire. Mais ce n'est pas immédiat.
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.
[^] # Re: Faire le choix du long terme
Posté par reynum (site web personnel) . Évalué à 2.
Heu non, tu crées une texture de tu "colle" dans ton rendrer en lui appliquant éventuellement des transformation au passage et une fois que du a défini tout ton rendrer tu le rafraîchis.
Je ne suis pas un pro de SDL2 j'en ai juste fait un peu il y a 3 ou 4 mois, mais ce que je viens de dire j'en suis sûre.
kentoc'h mervel eget bezan saotred
[^] # Re: Faire le choix du long terme
Posté par rewind (Mastodon) . Évalué à 2.
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.[^] # Re: Faire le choix du long terme
Posté par reynum (site web personnel) . Évalué à 1.
Ha ? même si je trouve ça étrange admettons.
Et du coup ça se passe comment quand tu appliques des transfos (rotations, homothétie, … ) sur tes textures ? il faut bien calculer les changements sur les pixels, et comme chaque "objets" contient la même texture il ne faut pas la recharger en mémoire, mais il faut faire appel à plusieurs fonctions (peut être des shaders) à chaque nouvel affichage de cette texture en fonction de sa transformation.
Si tu as la réponse je suis preneur, car ça m'intéresse beaucoup.
kentoc'h mervel eget bezan saotred
[^] # Re: Faire le choix du long terme
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Ca n'a pas l'air spécialement optimisé SFML. Tu as soit sf::Sprite qui va provoquer plein de changements d'états, soit sf:VertexArray pour envoyer des graphismes statiques. Bref c'est juste des petits helpers sympas.
Pour rendre un grand nombre de sprites/tuiles, il doit falloir taper directement de l'OpenGL avec des shaders, des vbo ou de l'instancing.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Faire le choix du long terme
Posté par rewind (Mastodon) . Évalué à 2.
Je connais assez peu OpenGL mais voilà ce que me dit mon intuition.
Déjà avec les VertexArray de SFML2, tu précises pour chaque objet (vertex) des coordonnées sur la texture et des coordonnées sur l'écran (je simplifie, en réalité, c'est un peu plus subtil). Puis, pour l'ensemble, tu spécifies une texture et éventuellement une transformation (mais qui du coup s'applique à tous les objets). Du coup, cette fonctionnalité est assez restreinte mais elle est utile dans certains cas particuliers, dont les tile map. Dans ce cas, tu as bien une seule texture, une seule transformation, et tout un ensemble de petits carrés issue de la texture à mettre sur l'écran. Et avec SFML, tu fais tout ça en une seule opération OpenGL. L'avantage, c'est que tu peux préparer ta struture (tous tes vertices) une seule fois et demander uniquement l'affichage à chaque tour de boucle (avec la transformation appropriée qui peut changer à chaque tour).
[^] # Re: Faire le choix du long terme
Posté par fabien . Évalué à 2.
ouais ça à l'aire interressant…
on parle bien d'appliquer une transformation (en general une rotation) à un ensemble de tiles.
Si c'est bien le cas, c'est super, mais assez restrint, c'est pas tous les jeux où t'as besoin de faire des rotations hein (oui je sais, newton aventures..) et surement pas necessairement besoin d'appliquer la rotation à tous les tiles.
Je ne pense pas que cette fonctionalité soit en mesure à elle seule de justifier l'utilisation de telle ou telle librairie, sauf cas particulier d'un jeu bien specifique, sinon c'est anecdotique.
à mon sens il y a d'autres bonnes raisons de priviliegier sfml.
[^] # Re: Faire le choix du long terme
Posté par rewind (Mastodon) . Évalué à 3.
Et bien figure toi que je vais en avoir besoin, et je ne vais pas du tout redévelopper un clone de Newton Adventures. Avec la SDL, je devais faire tous les calculs (et honnêtement, j'étais pas loin de m'y perdre) et là, tout sera géré dans la lib.
Non, c'est sûr que ça ne fait pas la décision. Mais c'est une fonctionnalité appréciable.
[^] # Re: Faire le choix du long terme
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Je pense qu'aujourd'hui la communication doit faire partie d'un projet dès le début. Ca veut dire que dès que tu as un prototype, il faut pondre un site, faire des annonces, poster dans les forums et releaser des démos, bref toucher un maximum de personnes afin:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Faire le choix du long terme
Posté par rewind (Mastodon) . Évalué à 2.
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).
Pour l'instant, je n'image pas passer par du crowdfunding.
[^] # Re: Faire le choix du long terme
Posté par Frederic Bourgeois (site web personnel) . Évalué à 7.
J'ai une réel question à ce propos, est-ce vraiment un choix judicieux pour développer un jeu ? Je ne suis pas un expert mais à chaque fois que j'utilise un soft en java, par exemple des logiciels pour gérer des équipement réseaux, ma machine souffre atrocement et j'ai l'impression de revenir 10 ans en arrière en terme de performance.
Le seul jeu que je connaissance dans ce langage c'est Minecraft et je trouve que c'est une brouette sur des petites machines, je fais tourner des jeux bien plus beaux sur les mêmes PC. Je trouve que l'équipement requis est complétement disproportionné par rapport au résultat à l’écran.
A chaque fois qu'il y a une discussion à ce sujet on me répond c'est plus comme ça maintenant, je veux bien, mais - et c'est une vrai question et pas un troll - quelqu'un connaît un jeu performant en Java ?
[^] # Re: Faire le choix du long terme
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Soyons clair: Java n'est pas un bon langage pour faire des jeux performants.
Ça tourne mieux que python ou javascript, mais de toute façon, tous les langages avec un ramasse miette et sans manière d'organiser précisément les données en mémoire ne sont pas adaptés pour les jeux.
Mais en informatique, ce n'est pas parce qu'un outil est inadapté qu'on ne produit pas de bonnes choses avec, car done is better than perfect.
Beaucoup de jeux android sont fait en Java, tu peux aussi essayer ceux fait avec libgdx, lwjgl ou playn:
http://libgdx.badlogicgames.com/gallery.html
http://lwjgl.org/projects.php
http://code.google.com/p/playn/wiki/DemoLinks
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Faire le choix du long terme
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
Un dev de Mozilla avait expliqué que Java était utilisé pour présenter la première interface graphique, tandis que l'application se charge. Charger toute l'application C++ en mémoire prend du temps, mais les éléments graphiques Java sont déjà en mémoire, dessiner une UI en java prend donc très peu de temps. Ensuite, dès la première action, on suppose que l'application aura fini de charger et donc l'UI java passe directement la main à l'appli C++ et on ne revient plus sur le java tant qu'on est encore dans l'application. Ce qui explique l'utilisation de Java dans les applications Android.
Certains devs mobile ne se prennent pas la tête et affichent directement une capture d'écran du menu principal, au lieu de redessiner le menu principal en java.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Faire le choix du long terme
Posté par dinomasque . Évalué à 3.
C'est même plus que "certains" devs mobiles : c'est le comportement par défaut sous iOS (capture d'écran du dernier écran affiché par l'app)
BeOS le faisait il y a 20 ans !
[^] # Re: Faire le choix du long terme
Posté par dinomasque . Évalué à 1.
C'est même plus que "certains" devs mobiles : c'est le comportement par défaut sous iOS (capture d'écran du dernier écran affiché par l'app)
BeOS le faisait il y a 20 ans !
[^] # Re: Faire le choix du long terme
Posté par Julien Jorge (site web personnel) . Évalué à 2.
Je ne suis pas certain que ce genre de comportement soit le bienvenu dans une dépêche qui ne parle pas d'une personne bronsonisée.
[^] # Re: Faire le choix du long terme
Posté par Grunt . Évalué à 2.
Javascript ça rame aussi.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Faire le choix du long terme
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Ajoutons qu'aujourd'hui ce n'est pas très intéressant de développer un jeu en directement javascript puisqu'il existe des solutions pour générer un jeu html5 à partir d'une base de code java (libgdx, playn) ou C++ (emscripten).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Faire le choix du long terme
Posté par Julien Jorge (site web personnel) . Évalué à 3.
J'ai testé
emscriptenpour faire une version web d'Andy Super Great Park (qui est donc écrit en C++) et je ne le conseille pas pour de nouveaux projets. C'est encore trop jeune pour permettre de faire un projet sereinement et il faut donc être prêt à rencontrer des erreurs obscures de compilation. Dans mon cas j'ai notamment souffert pour utiliser Boost. Alors à moins que la personne ait envie de s'impliquer dans le développement d'emscriptenautant que dans son projet, je pense qu'il faut éviter pour l'instant.[^] # Re: Faire le choix du long terme
Posté par binbin . Évalué à 1.
Pourquoi cela ne serait pas intéressant de coder un jeu directement en Javascript ?
J'utilise Coffeescript, qui me semble très productif, associé à une lib telle THREE.js ou Raphaël.js pour moi c'est parfait.
Est ce qu'on aurait forcément des meilleures performances avec un code JS généré ?
[^] # Re: Faire le choix du long terme
Posté par xcomcmdr . Évalué à 2.
Les meilleurs perfs en js pour les jeux c'est surtout si on utilise asm.js
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Faire le choix du long terme
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Je voulais dire intéressant en terme de perf: aller sur mobile ou de "vieux" PC (= autre chose qu'un gros PC de gamer d'après mes tests) avec du html5, c'est encore difficile.
Tu auras de meilleures perfs en releasant des versions natives.
Et sans doute aussi en js, si le générateur ponds du asm.js.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Faire le choix du long terme
Posté par reynum (site web personnel) . Évalué à 0.
[troll]
Tu aurais pu élargir en disant :
quelqu'un connaît un soft performant en Java ?
[/troll]
En tout cas je t'aurais répondu non. Il existe de petites merveilles de technique et de conception, Eclipse par exemple, mais niveau perfs c'est encore et toujours de la mer…
[troll]
Donc AMHA il vaut mieux apprendre à programmer (avec son cerveau et tout et tout) et utiliser des vrais langages conçus pour autre chose que piloter un cafetière.
[/troll]
kentoc'h mervel eget bezan saotred
[^] # Re: Faire le choix du long terme
Posté par Yth (Mastodon) . Évalué à 4.
Alors j'ai découvert Elasticsearch qui exploite Lucene.
C'est du java, ça m'a rebuté.
Côté perfs, c'est simplement hallucinant.
Comme quoi on peut coder très bien avec Java aussi.
C'est techniquement possible.
Yth.
# Plutôt SFML, mais selon
Posté par Kévin Guilloy . Évalué à 4. Dernière modification le 01 septembre 2013 à 12:06.
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 ?
Ces deux bibliothèques ont une grosse différence : la SDL n'excelle pas vraiment pour l'affichage : elle ne propose qu'un rendu matériel que depuis peu de temps.
À l'inverse, la SFML est beaucoup plus complète, et fournit une surcouche à OpenGL pour du rendu 2d accéléré. Ainsi, pour développer un jeu 2d, je conseillerais plutôt la SFML.
Après, s'il s'agit d'un jeu en 3d écrit en OpenGL (manuellement), SDL ou SFML c'est du pareil au même. Et dans ce cas, la SDL est probablement un peu plus standard. Pareil si c'est pour faire un jeu avec des graphismes « années 90 », du genre OpenTTD ou Newton Adventures.
En ce qui concerne la jeunesse des version, les deux sont très récentes : SFML 2.0 et SDL 2.0 datent toutes les deux de cette année.
[^] # Re: Plutôt SFML, mais selon
Posté par rewind (Mastodon) . Évalué à 3.
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.
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.
Ne me tente pas !
[^] # Re: Plutôt SFML, mais selon
Posté par Eldermê (site web personnel) . Évalué à 3.
Pour avoir essayé un peu les deux sur des petits projets de jeu (mais en 3D par contre), je dirais que la principale différence à l'usage est que SDL est un peu plus "bas niveau" que SFML mais globalement le principe est très proche. Pas trop regardé pour les fonctions d'affichage pour de la 2D mais il me semble qu'avec SFML tu as beaucoup plus de fonctions qui te mâchent le travail, alors qu'avec SDL tu devras sans doute écrire davantage de code toi-même. En ce qui me concerne, pour l'affichage je voulais simplement que la bibliothèque me crée un contexte OpenGL, et ensuite tout faire moi-même, donc je n'ai pas usage de ces fonctions de SFML.
Dans ton cas, pour de la 2D, et comme tu dis que tu ne veux pas trop refaire de choses à la main, je te conseillerais plutôt SFML moi aussi.
Cela dit, SDL présente aussi des avantages par rapport à SFML sur d'autres points : comme dit dans d'autres commentaires, elle est portée sur davantage de plateformes. Elle a aussi quelques fonctionnalités qu'à ma connaissance SFML n'a pas, par exemple la gestion du multipoints. Comme je voudrais porter mon bazar sur Android, ces aspects m'intéressent. Mais suivant les plateformes où tu veux porter ton jeu, et si tu as tout ce qu'il te faut dans SFML, ce n'est pas forcément un critère de choix.
[^] # Re: Plutôt SFML, mais selon
Posté par rewind (Mastodon) . Évalué à 2.
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.
# Limiter l'importance du choix
Posté par dave_null (site web personnel) . Évalué à 3. Dernière modification le 01 septembre 2013 à 13:02.
Je ne sais pas quel jeu tu comptes faire et quel va être sa durée de vie, mais à mon avis tu devrais limiter l'importance du choix de la librairie graphique.
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. Si ton jeu contient un mode multijoueur en réseau, tu peux suivre l'exemple de Minecraft : ils sont passés à une architecture client/serveur permettant, ce qui a pour conséquence de séparer parfaitement une grande partie de l'application. Quand tu joues en local sur Minecraft, tu lances un serveur sur localhost :-)
Après si ton jeu est essentiellement basé sur les graphismes c'est peut-être inutile.
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.
[^] # Re: Limiter l'importance du choix
Posté par rewind (Mastodon) . Évalué à 3.
Ç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).
Ça, c'est un argument qui me plaît :)
[^] # Re: Limiter l'importance du choix
Posté par matteli . Évalué à 3.
Et pourtant, tu ne devrais pas mélanger UI du reste. Cela te permet notamment de les mettre chacun dans un thread séparé (ce qui évite un ralentissement de l'affichage) ou comme dit plus haut de prévoir tout de suite un mode multi avec une architecture client serveur.
Si tu pars en mélangeant tout, tu auras l'impression de gagner du temps au début car tu n'auras pas besoin de réfléchir à ton architecture mais tu en perdra certainement beaucoup plus après.
Quant à la lib graphique, perso j'utilise Qt 5 (c'est portable, bientôt répandu sur toutes les plate-formes). Ca va bien pour mon jeu mais c'est pas forcément adapté à ce type d'application.
[^] # Re: Limiter l'importance du choix
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Dans les jeux, ce n'est pas évident. D'une part parce que, pour avoir de bonnes perfs, même en 2d simple, il faut organiser les données de façon spécifique à l'API choisie et d'autre part parce qu'une grosse partie du code d'un jeu est de l'UI justement.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Limiter l'importance du choix
Posté par matteli . Évalué à 2.
Tout dépend du type de jeu en effet. Pour le tien devnewton que j'ai le plaisir d'essayer, l'ui est centrale.
Vu que l'on ne sait pas le type de jeu dont il est question ici, mon propos est peut être HS.
[^] # Re: Limiter l'importance du choix
Posté par rewind (Mastodon) . Évalué à 2.
Je garde le suspense ;)
[^] # Re: Limiter l'importance du choix
Posté par rewind (Mastodon) . Évalué à 2.
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.
[^] # Re: Limiter l'importance du choix
Posté par matteli . Évalué à 3.
Je n'ai jamais dit le contraire pour le multi thread.
Sans parler d'optimisation, penser une architecture qui si possible permet de bien séparer ce qui est séparable est au contraire une TRES bonne idée au départ.
Mais ce n'est que mon avis…
[^] # Re: Limiter l'importance du choix
Posté par rewind (Mastodon) . Évalué à 2.
Nous sommes d'accord. Et l'architecture que j'utilise offre de bonnes opportunités si jamais il y a besoin.
[^] # Re: Limiter l'importance du choix
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Attention un ordi aujourd'hui peut être quand même une sacré bouse si on n'optimise pas: il y a beaucoup de couches entre le soft et le hard, des drivers pourris…
Même pour de la 2D simple, c'est difficile de faire un jeu qui tourne vraiment bien sur un netbook.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Limiter l'importance du choix
Posté par rewind (Mastodon) . Évalué à 2.
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 ?
[^] # Re: Limiter l'importance du choix
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Je ne vois pas comment comparer, je n'ai pas de netbook avec dualboot.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Limiter l'importance du choix
Posté par rewind (Mastodon) . Évalué à 2.
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 ?
[^] # Re: Limiter l'importance du choix
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
C'est difficile d'isoler un composant, car les PC auxquels j'ai accès sont tous très différents: netbook linux avec gpu intel, portable de gamer windows avec une radeon, pc de bureau linux avec nvidia, poste de dev avec linux et carte intel…
Globalement pas de surprise: les meilleures perfs sont sur les meilleurs hardwares.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Limiter l'importance du choix
Posté par cedric . Évalué à 4.
On peut effectivement reinventer la roue… Sinon on peut choisir un toolkit graphique qui se charge de faire l'abstraction graphique pour toi. Les EFL et Qt fournissent une stack graphique et une main loop bien plus complete que ce que fournisse la SDL et SFML. Si tu veux faire de la 2D ne prend ni la SDL, ni SFML, tu vas perdre ton temps.
Faire un moteur de rendu 2D, ce n'est pas juste place des sprites a l'ecran betement. C'est limiter le nombre de requete au GPU si on l'utilise. Optimiser la bande passante memoire. Utiliser tous les CPU disponible au mieux. S'adapter a la resolution, a la distance de lecture, au peripherique d'input, …
La plus part des jeux linux font l'erreur de sous estimer cette tache et se retrouve avec des performances abyssal et des besoins materiels delirant. Si ton but est de faire un jeu, ne recode pas un moteur 2D, utilise en un qui existe deja et est bien optimise. Si tu veux t'amuser a faire ton propre moteur 2D, commence par etudier ce qui se fait deja. Participe meme peut etre a un projet libre qui en construit un. Mais par pitie ne fait pas ton propre moteur 2D ! Il y a trop de projet libre qui souffre de cette calamite et il devient impossible pour eux de changer apres, trop de code, plus assez de developpeur…
Donc oui, la librairie de rendu graphique immediat est assez peu importante. C'est le toolkit que tu branches au dessus qui l'est !
PS: Connaissant tres bien le moteur de rendu des EFL, je peux que te la conseiller. Il n'y a pas grande concurrence dans le domaine et on a meme un backend SDL, si vraiment tu veux l'utiliser :-)
[^] # Re: Limiter l'importance du choix
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Ca semblerait curieux comme choix. Est-ce que les EFL sont aussi multiplateformes que SDL ou SFML? Il y a de la doc qui montre comment utiliser les EFL pour les jeux?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Limiter l'importance du choix
Posté par cedric . Évalué à 2.
Les EFL fonctionnent aujourd'hui sur tous les BSD, Linux, OpenSolaris, MacOS X et Windows. Il y a un port PS3 et un port Android en cour. Je ne sais pas trop ce qu'il en est pour iOS. Clairement la plateforme la mieux fini, est Linux. Mais on pourrait etre a minima aussi portable que la SDL vu qu'on peut utiliser la SDL comme backend :-)
Par contre, niveau doc, je ne crois pas qu'on est grand chose. Peut etre quand faisant une recherche sur Escape from booty bay, on peut tomber sur le blog qui en decrit la creation. Mais globalement, il n'y pas trop de difference entre les techniques d'une application classique et un jeu avec les EFL. Par contre, clair, on manque de doc…
[^] # Re: Limiter l'importance du choix
Posté par rewind (Mastodon) . Évalué à 5.
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.
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.
[^] # Re: Limiter l'importance du choix
Posté par cedric . Évalué à 5.
Dans la theorie, oui. Dans la pratique, une main loop bien foutue te fournis un bon niveau d'abstraction et te fournit des trucs comme le support des thread ou le reseau sans impacter les performances de ton rendu. Elles font de plus tout pour avoir 60fps et ne pas dropper de frame durant les animations. J'en reviens la encore, mais les jeux commencent tous par une petite main loop simple, puis avec le temps, ca tourne mal et il n'y a pas de refactoring… Et finalement, ce qui etait un avantage devient un inconvenient ! Probleme de perf, perte de stabilite dans le frame rate, blocage lors d'IO, …
Tu viens juste de demontrer mon point precedent. Si tu utilises OpenGL ou OpenGL ES pour faire ton rendu, l'ordre dans lequel tu vas envoyer tes ordres au GPU est tres important. Il faut minimiser les changements de texture et de shader par exemple. De plus, certaine operation avec le GPU peuve bloquer ta boucle principal et il vaut mieux les executer depuis un thread (si ton driver en est capable). Si tu as un backend logiciel, il faut en profiter pour faire un delta et ne redessiner que ce qui a changer a l'ecran. Tu peux merger des layers qui ne changent pas entre eux pour diminuer la bande passante memoire consommer et avoir un rendu plus rapide. Juste des trucs de base que te fournirons des moteurs de rendu 2d que tu trouveras necessaire quand ton projet prendra de l'empleur.
o = evas_object_image_add(evas);
evas_object_image_file_set(o, "monimage.png", NULL);
evas_object_image_preload(o, EINA_FALSE);
Done et le chargement se faira meme de maniere asynchrone te laissant la possibilite de faire un autre truc dans ta main loop. C'est le meme code pour tous les backend et toutes les plate-formes. Celle qui n'aurait pas de support des threads, fairont le chargement juste de maniere synchrone. Enfin tu noteras que tu ne fais que gerer des objets et que c'est le scene graph qui va decider comment gerer les pixels a l'ecran au final.
Bon par contre, niveau doc, on est un peu lege. Tu trouveras des info principalements dans le doxygen des EFL et de Elementary: https://build.enlightenment.org/job/nightly_efl_gcc_x86_64/lastSuccessfulBuild/artifact/doc/html/index.html et https://build.enlightenment.org/job/nightly_elm_gcc_x86_64/lastSuccessfulBuild/artifact/doc/html/index.html .
[^] # Re: Limiter l'importance du choix
Posté par rewind (Mastodon) . Évalué à 6.
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.
# SFML
Posté par MCMic (site web personnel) . Évalué à 2.
Je conseillerais la SFML pour deux raisons:
1) C'est du C++, orienté objet donc c'est plus agréable à manier et mieux intégré dans ton code que du code SDL
2) C'est OpenGL derrière, ça permet plus de chose, tu es bien plus libre avec tes sprites, tu peux notamment les faire tourner d'un nombre de degré arbitraire sans soucis, chose qui n'est pas possible en SDL 1.2 (d'après ce qui est dis plus haut ça a l'air corrigé dans SDL2, mais je pense que tu trouvera quand même des trucs intégrés dans SFML que tu aura à faire à la main coté SDL)
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, …
Mais le plaisir du code prévaut amha.
[^] # Re: SFML
Posté par rewind (Mastodon) . Évalué à 2.
Oui, c'est mon impression et je n'ai pas envie de refaire si c'est déjà fait et que ça marche.
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.
[^] # Re: SFML
Posté par cedric . Évalué à 2.
1) Je ne connais pas vraiment la SFML et je n'ai lu que les tutoriaux/exemples, et c'est pas vraiment du C++ tres oriente objet. On dirait plus un binding a la SDL en terme de design. Si vraiment c'est du C++ que tu veux, il vaut mieux aller voir Qt a mon avis. Ca me semble un non argument ici.
2) OpenGL permet plus de chose, mais en meme temps il te rajoute des contraintes. Ainsi en exposant les shaders, tu te retrouves a te compliquer ta portabilite (les shaders OpenGL et OpenGL ES sont rarement compatible). De plus pour faire de la 2D OpenGL, c'est vraiment un truc qu'on martirise et torture pour arriver a en faire quelque chose… Quand un bon moteur 2D arrive a faire le meme resultat, mais c'est un truc qui se perd avec le temps.
Si tu veux un bon moteur 2D, ce que tu as besoin, c'est d'un scene graph ! Sans ca, tu vas te tapper des perfs minable et tu perdras ton temps dans de l'optimisation/reinvention de roue carre. De plus la SFML n'est pas si portable que ca, donc quite a etre moyen portable, un toolkit plus complet comme Qt ou les EFL t'apportera plus et reduira ton temps de developpement.
# Ni l'un ni l'autre
Posté par cedric . Évalué à 4.
Si tu veux faire de la 2D, oublie les. Elles ne sont pas adaptees ! La plus part des gens qui debutent pour un jeu 2D, se disent qu'il leur faut juste un moyen de pouvoir mettre quelques sprites a l'ecran avec un peu de texte. Rien de bien complique et ca ne devrait pas poser de probleme a n'importe quel PC moderne…
Puis un jour, c'est du logiciel libre, un fou tente de le porter sur un telephone, un autre sur une console etrange, … Et rapidement toute la complexite de faire un moteur 2D se revele. Optimiser l'utilisation de tous les CPU disponibles, limiter la consomation de bande passante memoire, avoir une portabilite OpenGL, OpenGL ES et software, s'adapter aux peripheriques d'entree et de sortie… Et voila apres quelques annees, on se retrouve avec une base de code qui ressemble a un toolkit complet, mais en moins bien et developpe plus par effet de bord que par volonte.
Pendant ce temps la, les toolkits graphiques, un peu comme le noyau Linux, attire des developpeurs avec des objectifs differents qui poussent le toolkit a s'ameliorer dans toutes les directions. Au final, ils sont plus performant que ce que n'importe quel jeu Linux arrivera a atteindre par lui meme. Les gens qui developpent ces toolkits, gagne en competence nettement plus rapidement que un projet unique, car ils sont expose a plus de variation et de contrainte. Il est donc une mauvaise idee de reinventer un moteur 2D, meme pour apprendre. Participer a un projet de toolkit existant de faira apprendre beaucoup plus et beaucoup plus vite que ce que tu decouvriras par toi meme en faisant ton propre moteur.
En conclusion, je te conseille Qt ou les EFL. Je ne presente pas Qt, ce n'est pas mon domaine :-) Mais pour les EFL, tu as une portabilite Linux, Windows et Mac. Un port Android est en cour. Le rendu et le code de ton application sont le meme quelque soit la plateforme et la methode de rendu graphique (OpenGL, OpenGL ES ou software). Tu as une main loop, le support reseau, le support audio, l'abstraction des peripheriques d'input et tu peux la compiler completement en static avec ton application pour faciliter la distribution avec une version particuliere.
[^] # Re: Ni l'un ni l'autre
Posté par rewind (Mastodon) . Évalué à 3.
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.
[^] # Re: Ni l'un ni l'autre
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Avec Qt, il y a le très bon Nikki and the robots.
Par contre il me semble que Qt ne gère pas les manettes de jeu…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ni l'un ni l'autre
Posté par rewind (Mastodon) . Évalué à 3.
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.
[^] # Re: Ni l'un ni l'autre
Posté par cedric . Évalué à 3.
Un toolkit comme les EFL se doit de pouvoir realiser des animations pleine ecrans tel qu'une liste qui se deplace verticalement, a 60fps en HD avec le minimum de lag entre le mouvement du doigt et l'image reelle a l'ecran, en consommant le moins d'energie possible sur une puce ARM en laissant un maximum de temps a la partie application pour les developpeurs qui ne savent pas ce qu'ils font. Bien entendu chaque item de ta liste va avoir plusieurs niveau d'image (le fond, l'ombre, le cote brillant par dessus, une image a gauche, une a droite) et du texte avec des attributs qui changent (gras, italic, collore). C'est a peu pres ca la contrainte d'un toolkit comme les EFL.
Exemple d'application EFL : http://www.dailymotion.com/calaos_home#video=xcx3v0 .
Le moteur de rendu des EFL, c'est tres exactement le state of the art en matiere de moteur 2D. La plus part des toolkits ne sont pas encore a ce niveau, je te l'accorde. Mais j'attend encore de voir un jeu libre qui est au meme niveau d'avancement pour son moteur 2D. 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…
[^] # Re: Ni l'un ni l'autre
Posté par rewind (Mastodon) . Évalué à 5.
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.
[^] # Re: Ni l'un ni l'autre
Posté par cedric . Évalué à 6.
Je ne parlerais que pour les EFL que je connais mieux. Il y a au moins deux jeux qui existent et on etait realise tres rapidement (moins d'un mois de dev a temps complet):
Eskiss: http://www.youtube.com/watch?v=j2kuxyzY7IU
Escape from Booty Bay: http://www.youtube.com/watch?v=WA9kj-99qsc
Contrairement a ce que tu penses, tu limites le boulot de ces toolkits a afficher des widgets. Hors je te parles de ce qu'un jeu va implementer, un scene graph 2d. C'est une tache complexe, qui demande beaucoup d'expertise et de connaissance sur un grand nombre de materielle. Sans compter qu'il faut l'architecturer proprement pour avoir un code maintenable et lisible. Je ne connais aucun jeu 2d libre qui soit capable de rivaliser avec les EFL. Et pour le coup, tous les jeux que j'ai regarde integre plus ou moins leur propre usine a gaz, mais en moins bien…
Le principe d'un toolkit graphique moderne tourne au tour d'un scene graph qui connait l'ensemble des objets dessiner a l'ecran. Cela lui permet de decider efficacement quoi et dans quel ordre dessine a l'ecran. En prenant en compte un maximum de contrainte pour s'adapter a tous les systemes. Le scene graph des EFL a ete optimise pendant plus d'une dizaine d'annee et continue d'etre encore optimise aujourd'hui.
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) ?
[^] # Re: Ni l'un ni l'autre
Posté par navaati . Évalué à 1.
Sinon ya Clutter avec un scenegraph.
[^] # Re: Ni l'un ni l'autre
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Ca n'a l'air ni simple, ni spécialement bien documenté (j'ai mis 5 min avant de trouver que le scenegraph était Evas… Pourquoi pas EScenegraph?), c'est du C pur, peu de jeux semblent l'utiliser…
Bref je vois encore mal pourquoi un développeur de jeu jeterait son baril de SFML ou SDL pour le baril EFL sur la seule base d'une promesse de bonnes performances du scenegraph.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ni l'un ni l'autre
Posté par rewind (Mastodon) . Évalué à 5.
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.
[^] # Re: Ni l'un ni l'autre
Posté par cedric . Évalué à 2.
Vu la quantite industrielle d'utilisateur de Windows que faisons nous ici !
Dans cette liste, peux-tu me donner un bon jeu 2D qui n'a pas de probleme de performance. Ca ne devrait pas etre difficile, vu la quantite industrielle.
[^] # Re: Ni l'un ni l'autre
Posté par xcomcmdr . Évalué à 2.
Battle for Wesnoth, FTL, …
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ni l'un ni l'autre
Posté par cedric . Évalué à 1.
Battle for Wesnoth est clairement assez demandeur en terme de ressource, bien plus qu'il ne le devrait. De plus la derniere fois que j'avais regarder, ils etaient coince avec le rendu software et ne pouvait pas tirer parti d'OpenGL et OpenGL ES.
Pour ce qui est de FTL, j'ai pas vu les sources. Tu peux me donner un pointeur ?
[^] # Re: Ni l'un ni l'autre
Posté par xcomcmdr . Évalué à 1.
Il est propriétaire, mais n'a pas de problèmes de perfs.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ni l'un ni l'autre
Posté par cedric . Évalué à 0.
[^] # Re: Ni l'un ni l'autre
Posté par Zenitram (site web personnel) . Évalué à 4.
La liberté ou non du jeu est indépendante de ce qu'on demande (la qualité de la lib sous-jacente).
-> Si un jeu non libre peut être performant avec x, alors un jeu libre le peut aussi.
Inutile d'ajouter des contraintes hors sujet par rapport à la question. Ce n'est pas la qualité des développeurs libre qu'on souhaite tester.
(après, que tu ne puisses pas voir comment ils font est un autre problème, mais externe aux capacités de SDL)
[^] # Re: Ni l'un ni l'autre
Posté par cedric . Évalué à 3.
La SDL est une bibliotheque bas niveau qui necessite de coder un moteur 2D par dessus. La SDL ne fait rien. C'est juste un truc qui t'ouvre une fenetre, te donne des inputs, te fournit des primitives de blit un peu lente, et c'est tout. C'est ce que tu fais au dessus qui compte. Comment tu ordonnes tes blits, ce qu'ils contiennent, comment tu construit tes atlas, and so on. Ce n'est pas complique de comprendre que la SDL ne fait rien et qu'il faut tout faire a la main. La difficulte, elle est dans la couche au dessus.
Mon point est que si tu es un developeur seul ou une petite equipe non professionnelle, ce qui est le cas des developpeurs de logiciel libre, tu n'as probablement pas le temps de passer 10 ans a developper un moteur 2d. Si tu as les moyens de te payer une equipe pour te developper un moteur 2D ou obtenir une license sur un moteur existent, alors tres bien, tu peux atteindre les perfs des EFL. C'est quand meme assez logique que si tu implementes par toi meme un scene graph state of the art, tu vas pouvoir avoir les meme perfs qu'une autre implementation qui fait la meme chose (Surtout que les EFL ca marche aussi au dessus de la SDL).
Le fait que personne dans cette conversation n'est saisie la difficulte de faire un moteur de rendu 2D (et non, une bibliotheque de rendu immediat n'est pas une solution) prouve assez fortement mon point. Et la deuxieme preuve, c'est que je ne connais toujours pas de jeux libre dans la liste industrielle presente qui reponde a mon critere. Ca doit pourtant pas etre si difficile a trouver, si je raconte des betises…
[^] # Re: Ni l'un ni l'autre
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
En même temps, malgré Java et un moteur commencé en rendu immédiat sans souci de perf, j'arrive à faire tourner mon jeu sur un netbook après quelques optimisations bien ciblées…
Ca prouve surtout que les développeurs de jeux veulent d'abord faire des jeux, pas des benchmarks.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ni l'un ni l'autre
Posté par Zenitram (site web personnel) . Évalué à 3.
Quel est le rapport avec ta question?
Je te cite :
donc la base de la question est SDL. Le haut dessus libre ou pas n'a aucune incidence sur la base de la question.
Après, que SDL n'ai pas de moteur avancé, c'est une autre histoire qui n'est pas le sujet de la question que tu as posée.
Qu'essayes-tu de démontrer, et quel est le lien avec la "question renversée" que tu as posée?
Tu as dis juste avant "En conclusion, je te conseille Qt ou les EFL.", je ne connais pas EFL ok, mais Qt niveau "moteur 2D" c'est euh… complètement hors sujet. EFL, à première lecture, fait bouger des choses à l'écran tout seul comme un grand, super, mais est-ce qu'il répond au besoin de faire bouger autre chose que des widgets (genre faire un Parallax scrolling plus facilement que SDL ou SFML)?
Je ne comprend rien à ton argumentaire, car tu essayes de démontrer A en démontrant B. Ca part donc dans tous les sens, impossible à suivre.
[^] # Re: Ni l'un ni l'autre
Posté par rewind (Mastodon) . Évalué à 3.
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.
[^] # Re: Ni l'un ni l'autre
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Si tu y tiens, opentyrian tourne bien sur mon netbook.
Mais tu prends le problème du mauvais côté. Tu supposes que les jeux SDL ont des problèmes de perf, que c'est un souci tellement important que les développeurs cherchent autre chose et qu'utiliser EFL les règlera.
Hors je n'ai jamais entendu personne se plaindre des problèmes de perf de la SDL.
Si tu veux convaincre les développeurs d'utiliser les EFL, il faut montrer pourquoi cela leur fera gagner du temps par rapport aux solutions éprouvées.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ni l'un ni l'autre
Posté par cedric . Évalué à 6.
Les problemes de perf ne sont pas du a la SDL, mais aux jeux qui n'implemente pas une boucle de rendu plus optimise parce que ce n'est pas leur competence. Pour ce qui est des plaintes, tu peux entendre les miennes :
La plus part des developpeurs et utilisateur Linux acceptent juste ce fait qui n'est pour moi pas une fatalite et pourrait etre resolu avec une gestion plus optimal de la phase de rendu. Les developpeurs de jeux ont deja de gros problemes a regle : l'histoire, les ressources de leur jeu et le gameplay a regler en premier. Les performances sont juste ignorees et relegues a Moore qui resoudra forcement le probleme…
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. Il y a 15 ans quand on passait a Linux, c'etait pour des raisons techniques. Aujourd'hui si tu utilises Ubuntu avec un clone de Wormux, tu fairais mieux d'etre sous Windows avec la version original !
[^] # Re: Ni l'un ni l'autre
Posté par rewind (Mastodon) . Évalué à 3.
Tu compares des choses pas comparables en terme de graphismes et de résolution d'écran…
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.
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.
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.
[^] # Re: Ni l'un ni l'autre
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Vu que je me suis intéressé au sujet récemment, voici quelques remarques:
Enfin si tu veux vraiment pousser EFL, il faut écrire des tutoriaux et des exemples qui montrent bien la valeur ajoutée du "produit"!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ni l'un ni l'autre
Posté par xcomcmdr . Évalué à 3.
L'original était en 320x200, etc…
Et quand je vois wormux tourner sur un netbook Atom, j'me dis qu'il n'est pas si mal fichue niveau perfs.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ni l'un ni l'autre
Posté par gouttegd . Évalué à 5.
Pour ce que ça vaut, pour avoir essayé la version SDL et la version GTK du client Freeciv, chez moi il n’y a pas photo : la version SDL est effectivement terriblement lente, là où la version GTK est parfaitement fluide.
[^] # Re: Ni l'un ni l'autre
Posté par MCMic (site web personnel) . Évalué à 3.
Après réflexion et lecture des nouveaux commentaires, je confirme : essaie de trouver un moteur de jeux existant que tu peux utiliser.
Pour avoir écrit ou contribuer à plusieurs jeux, écrire la gestion des menus, les collisions, les préférences, la configuration et le stockage des contrôles, c'est drôle la première fois mais ça devient vite agaçant de pas avoir des trucs tout prêts pour ça.
Pour en avoir récemment discuté avec l'auteur, je serais très intéressé par un retour sur la création d'un jeu avec le bear engine.
C'est le moteur derrière ces jeux là : http://www.stuff-o-matic.com/projects.html
Il se trouve ici : https://github.com/j-jorge/bear
Ça gère pas mal de choses assez intéressantes visiblement.
Le moteur a jamais été utilisé que par ses créateurs donc manque probablement un peu de doc, mais si tu peux voir s'il te convient et faire des retours ça m'intéresse, ça fait quelques temps que je cherche un candidat pour faire des jeux C++ rapidement en réutilisant de l'existant.
Note: c'est SDL et OpenGL derrière donc ça doit être assez portable.
[^] # Re: Ni l'un ni l'autre
Posté par rewind (Mastodon) . Évalué à 2.
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.
[^] # Re: Ni l'un ni l'autre
Posté par devnewton 🍺 (site web personnel) . Évalué à 3. Dernière modification le 02 septembre 2013 à 13:50.
Je pense que la bonne approche est celle de libretro: une seule GUI et gestion des configurations pour plusieurs jeux, exactement comme on a pour les émulateurs de console.
Malheureusement cette implémentation est encore très jeune et inapplicable aux jeux non C/C++ (un jeu rétro doit être une bibliothèque C).
Si quelqu'un est motivé pour reprendre cette idée et en faire quelquechose d'universel, je suis prêt à adapter mon jeu!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# J'ai choisi...
Posté par rewind (Mastodon) . Évalué à 7.
Bon, résultat des courses, après avoir fait quelques essais avec SFML2, je l'adopte. Les arguments qui m'ont convaincu :
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 installet en moins de 2 minutes, j'avais un truc prêt à l'emploi. Et comme les.pcsont fournis, c'est encore plus facile à intégrer au build system.[^] # Re: J'ai choisi...
Posté par MCMic (site web personnel) . Évalué à 3.
Qu'appelle-tu un sur-ensemble de SDL2? La SFML est basée sur OpenGL, pas sur SDL.
[^] # Re: J'ai choisi...
Posté par rewind (Mastodon) . Évalué à 3.
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::WindowIMG_Load()+SDL_CreateTextureFromSurface():sf::TextureSDL_RenderClear()+SDL_RenderPresent():window.clear()+window.display()SDL_PollEvent():window.pollEvent()SDL_RenderCopyEx():sf::SpriteEn 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.[^] # Re: J'ai choisi...
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Plus qu'à poster ton premier screenshot!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: J'ai choisi...
Posté par rewind (Mastodon) . Évalué à 2.
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'à.
[^] # Re: J'ai choisi...
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Si tu vois des choses à améliorer dans nanimstudio, j'assure un support "quand j'ai le temps"!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: J'ai choisi...
Posté par rewind (Mastodon) . Évalué à 2.
Et bien puisque tu le demandes, voilà :
Voilà, ce n'est pas très important, l'outil est tout à fait utilisable en l'état.
[^] # Re: J'ai choisi...
Posté par devnewton 🍺 (site web personnel) . Évalué à 3. Dernière modification le 04 septembre 2013 à 10:06.
Oui, c'est pour sélectionner un sous rectangle. C'est le système de coordonnées d'OpenGL:
C'est surtout utile pour le "texture packing": j'utilise une image par frame puis je lance Tools=>Optimize qui regrouper les images dans de grandes textures en mettant les bonnes coordonnées ( voir l'explication complète https://linuxfr.org/users/devnewton/journaux/nanimopt-un-optimiseur-de-nanim ).
Le champs format ne sert à rien, j'ai oublié de le virer de la GUI!
Je note les autres points.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: J'ai choisi...
Posté par rewind (Mastodon) . Évalué à 2.
Ha ben ce petit schéma va bien m'aider pour le rendu. Dans SFML2, l'auteur a pris le parti de ne pas utiliser le système OpenGL en pourcentage mais d'utiliser des pixels (je suppose qu'il calcule le pourcentage après). Du point de vue du développeur, c'est plus facile. De même ici, je vois que l'axe vertical est «inversé» par rapport à la normale, il faudra que j'y prête attention.
[^] # Re: J'ai choisi...
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Jusqu'à ce que tu changes la résolution de tes textures.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: J'ai choisi...
Posté par rewind (Mastodon) . Évalué à 2.
J'essaie d'éviter au maximum d'hardcoder la taille des textures dans le jeu. Généralement, je la récupère dynamiquement (il y a des fonctions pour ça en SDL et en SFML) si j'en ai besoin.
[^] # Re: J'ai choisi...
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
J'ai fait une nouvelle release avec les changements suggérés sauf le bouton "apply": j'ai fait en sorte que tous les changements s'appliquent en direct.
http://devnewton.bci.im/projects/nanim/home
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: J'ai choisi...
Posté par rewind (Mastodon) . Évalué à 2. Dernière modification le 05 septembre 2013 à 13:45.
Super ! En plus, il y a un installeur et on a accès à tous les outils, c'est chouette :)
Seul petit bug, il y a un "dirname" qui apparaît dans le fichier shell
nanimstudioet qui est inutile. Je l'ai enlevé et ça marche bien chez moi. C'est nickel !Et la capture d'écran n'est plus à jour du coup.
[^] # Re: J'ai choisi...
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Corrigé!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: J'ai choisi...
Posté par fabien . Évalué à 3.
felicitation pour ton choix, j'aime autant sdl que sfml.
ton premier argument (+ haut niveau) est à mon sens le meilleur.
par contre :
J'ai pas suivis ces derniers mois, mais n'y a t'il toujours pas qu'un seul et unique developpeur ? (laurent, qui fait du super boulot). A t-il été rejoint par d'autres ?
[^] # Re: J'ai choisi...
Posté par rewind (Mastodon) . Évalué à 2.
Si, je crois qu'il est encore seul. Mais sur le github, il intègre pas mal de pull request venant d'autres développeurs. Et dans le README, il y a un autre nom que le sien pour la partie Mac OS X apparemment.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.