Je suis fondamentalement contre le tirage au sort. Je me demande bien comment cette idée a pu arriver jusque là, c'est vraiment un signe de mauvaise santé de notre démocratie. Pour moi, le tirage au sort, c'est la négation du choix, c'est l'antithèse de la démocratie et de la république.
Ce qui fonde notre démocratie et notre république, c'est que les citoyens choisissent des représentants en fonction de programmes qui auront été débattu auparavant de manière à éclairer leur choix. Ce choix permet de déterminer ce qui est l'intérêt général et les règles en cours font que le choix de 51 l'emporte sur les 49 autres. Je reviendrai dessus après pour Zenitram ;)
Dans le cas d'un tirage au sort, il n'y a plus de choix possible ! Croire qu'il n'y a qu'une seule politique possible, c'est ne rien comprendre à comment fonctionne ce monde : il y a toujours plusieurs choix. Et parfois, comme dans le cas actuel, il y a des décisions importantes à prendre (concernant l'écologie par exemple) qu'on doit prendre mais que certains partis politiques ne proposent tout simplement pas. D'où l'importance du choix. Je refuse de céder ma (maigre) part de souveraineté à un dé. Statistiquement, ça va aller. Sauf que dans le monde réel, il y a la loi de Murphy et qu'on n'est pas à l'abri de tomber sur une assemblée largement dominée par l'extrême-droite, chose impossible avec notre système actuel (même avec une proportionnelle) parce que l'extrême-droite est minoritaire.
Donc, absence de choix et risque de voir des absurdités statistiques : non merci pour le tirage au sort.
Maintenant, pour Zenitram qui répète souvent que la démocratie, c'est la dictature de la majorité, je répond : non. Le fait que 51 l'emporte face à 49, c'est une méthode de décision, pas une méthode de conviction. Ça signifie que les 51 n'ont pas forcément raison (et les exemples historiques ne manquent pas) et ça ne signifie pas que les 49 doivent se flageller et changer d'avis. Ça a des avantages et des inconvénients mais ça me semble être une méthode qui a fait ses preuves sur le long terme. Avoir des majorités qualifiés (genre 2/3) ne change rien au problème des minoritaires.
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 nanimstudio et qui est inutile. Je l'ai enlevé et ça marche bien chez moi. C'est nickel !
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.
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.
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.
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.
Non, c'est sûr que ça ne fait pas la décision. Mais c'est une fonctionnalité appréciable.
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.
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.
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.
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).
ça serait bien qu'il y ait une petite étoile dans le titre de la fenêtre quand on doit sauvegarder
ça serait bien de mapper CTRL+S sur la sauvegarde (et du coup, la première fois, il demande le nom du fichier)
pour l'UI :
dans les panneaux "Images" et "Frames" (surtout "Frames" en fait), un petit bouton "Apply" ne serait pas de refus parce qu'on a du mal à savoir si la modification qu'on a faite a été prise en compte ou pas
je n'ai pas compris à quoi servait "Format" dans le panneau "Images"
je devine à quoi sert (u1,v1) et (u2,v2) (c'est pour sélectionner une partie de l'image, j'ai bon ?) mais je me demande bien quelle est l'unité employée, c'est un pourcentage, c'est ça ?
Voilà, ce n'est pas très important, l'outil est tout à fait utilisable en l'état.
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 :
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.
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.
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) ?
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.
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.
[^] # Re: Du beau...
Posté par rewind (Mastodon) . En réponse au journal Benoît Hamon a encore frappé. Évalué à 4.
Je suis fondamentalement contre le tirage au sort. Je me demande bien comment cette idée a pu arriver jusque là, c'est vraiment un signe de mauvaise santé de notre démocratie. Pour moi, le tirage au sort, c'est la négation du choix, c'est l'antithèse de la démocratie et de la république.
Ce qui fonde notre démocratie et notre république, c'est que les citoyens choisissent des représentants en fonction de programmes qui auront été débattu auparavant de manière à éclairer leur choix. Ce choix permet de déterminer ce qui est l'intérêt général et les règles en cours font que le choix de 51 l'emporte sur les 49 autres. Je reviendrai dessus après pour Zenitram ;)
Dans le cas d'un tirage au sort, il n'y a plus de choix possible ! Croire qu'il n'y a qu'une seule politique possible, c'est ne rien comprendre à comment fonctionne ce monde : il y a toujours plusieurs choix. Et parfois, comme dans le cas actuel, il y a des décisions importantes à prendre (concernant l'écologie par exemple) qu'on doit prendre mais que certains partis politiques ne proposent tout simplement pas. D'où l'importance du choix. Je refuse de céder ma (maigre) part de souveraineté à un dé. Statistiquement, ça va aller. Sauf que dans le monde réel, il y a la loi de Murphy et qu'on n'est pas à l'abri de tomber sur une assemblée largement dominée par l'extrême-droite, chose impossible avec notre système actuel (même avec une proportionnelle) parce que l'extrême-droite est minoritaire.
Donc, absence de choix et risque de voir des absurdités statistiques : non merci pour le tirage au sort.
Maintenant, pour Zenitram qui répète souvent que la démocratie, c'est la dictature de la majorité, je répond : non. Le fait que 51 l'emporte face à 49, c'est une méthode de décision, pas une méthode de conviction. Ça signifie que les 51 n'ont pas forcément raison (et les exemples historiques ne manquent pas) et ça ne signifie pas que les 49 doivent se flageller et changer d'avis. Ça a des avantages et des inconvénients mais ça me semble être une méthode qui a fait ses preuves sur le long terme. Avoir des majorités qualifiés (genre 2/3) ne change rien au problème des minoritaires.
[^] # Re: Du beau...
Posté par rewind (Mastodon) . En réponse au journal Benoît Hamon a encore frappé. Évalué à 3.
Il n'est pas au PS, il est apparenté PS. D'ailleurs, je crois me souvenir que le PS avait mis un candidat en face de lui la dernière fois.
[^] # Re: J'ai choisi...
Posté par rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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 rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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: Faire le choix du long terme
Posté par rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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: J'ai choisi...
Posté par rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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.
[^] # Re: J'ai choisi...
Posté par rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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: Faire le choix du long terme
Posté par rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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: J'ai choisi...
Posté par rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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: Faire le choix du long terme
Posté par rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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: J'ai choisi...
Posté par rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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 rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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.# J'ai choisi...
Posté par rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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: Virtual box?
Posté par rewind (Mastodon) . En réponse au journal Premiers pas avec Manux. Évalué à 10.
C'est triste ton avis sur Packard Bell…
[^] # Re: Ni l'un ni l'autre
Posté par rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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 rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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 rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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: Limiter l'importance du choix
Posté par rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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.
[^] # Re: Ni l'un ni l'autre
Posté par rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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 rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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 rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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 rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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: Limiter l'importance du choix
Posté par rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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 rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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: SFML
Posté par rewind (Mastodon) . En réponse au journal SDL2 ou SFML2 ou ... ?. É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.