Joli simplification ! Peut etre est-ce plutot parce que cela supporterait l'effort de fragmentation et de controle de Ubuntu sur le l'environnement graphique libre (Mir, c'est peut etre open source, mais ca manque un peu de contribution communautaire et c'est un code entierement controle par Ubuntu sans aucune valeur technique par rapport a Wayland). Peut etre aussi que l'effort de maintenance qui retombe sur l'upstream (Intel) ne donne de gain a personne d'autre qu'a Ubuntu.
Et dans le fond, si ils veulent faire leur propre fork de Linux, il est temps qu'ils acceptent d'en payer le prix. C'est a dire la maintenance dans son integralite et qu'ils arretent d'ennuyer les differents projets upstream avec leur communication marketing !
Un driver Intel Ivy Bridge sur Arch Linux. Quand tu edites du texte, en general, il n'y a que le curseur qui clignote pas bien vite et un peu de texte qui s'ajoute pas bien vite aussi. Alors forcement le software a un enorme avantage :-) Aussi j'utilise le compositeur software d'enlightenment compile specialement pour mon pc. Le tout tester avec PowerTop et c'est reproductible.
Comme le fait remarquer si bien la page de Wikipedia, l'effet Osborne est tres loin d'etre demontre. Et je pense que le ralentissement massif des ventes de Nokia n'a rien a voir avec.
Symbian etait un OS vraiment catastrophique pour les developpeurs et les utilisateurs. La concurrence est devenu juste meilleur et moins chere. Point. Pas la peine d'y voir autre chose. Les gens n'achetent pas un telephone comme un parie sur l'avenir. De toute facon, ils vont en changer dans 2 ans et Symbian, Android ou iOs ne change pas grand chose… si ce n'est l'usabilite !
celle là est simplement la plus optimale (tout sur le GPU).
Pour une certaine definition de optimale ;-) Pour certain cas d'utilisation, tel que editer du code dans un editeur texte quand on est sure batterie, le fait d'utiliser OpenGL pour faire le compositing au lieu du CPU augmente sensiblement la consomation de batterie (Je perds 1W, ce qui represente sur mon PC 1h d'autonomie).
Il est probable qu'avec le support du buffer age et de la mise a jour partiel dans Wayland, ces chiffres ne soit plus les meme. Mais pour l'instant, avec X, quand je suis sur batterie, j'evite d'utiliser OpenGL.
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…
Hors je n'ai jamais entendu personne se plaindre des problèmes de perf de la SDL.
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 :
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.
Battle for Wesnoth qui prend des plomb sur rpi.
Freeciv qui rame comme ce n'est pas permi (pour le rendu qui saccade alors que toute la logique est dans un serveur separe).
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 !
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 ?
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.
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.
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…
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.
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.
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, …
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.
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.
À 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.
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.
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…
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):
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) ?
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.
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 :-)
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.
Cyanogenmod propose cela si je ne me trompe pas. C'est une fonctionnalite que j'ai toujours voulu avoir dans un Android grand public, mais il faut croire que ce n'est pas une priorite que de proteger ses utilisateurs…
Je me suis mal exprime et n'est pas ete assez claire. Ce n'est pas une instruction en elle-meme, mais la combinaison, micro-architecture et systeme memoire, qui donne pour une tache equivalente la meme consomation d'energie. J'ai fait une vite recherche sur Google et je crois que le papier ci-dessous est ma source pour cette information :
Plus maintenant ! C'est Android qui a sauvé java. Il y avait un trend avant Android a la diminution du nombre de programme en java. Depuis ça a changé !
Pour faire simple, non. Pour le detail, la principale difference entre le monde du mobile et ton PC, c'est l'alimentation electrique et la densite en energie que doit contenir ta batterie. Il faudra bientot une densite superieur a des explosifs comme le TNT… Ce qui donne une contrainte. Certe on augmente la complexite des SoC en multipliant les coeurs dedies pour optimiser la consomation d'energie. On augmente aussi la quantite de memoire. Mais au final, un ARM et un x86 ont la meme efficacite energetique par instruction, ce qui veut dire que ton CPU generaliste est deja aussi performant energetiquement parlant que ton telephone. Ton telephone est plus lent parce qu'il doit consommer moins de batterie. Et les batteries ne suivent pas la loi de Moore, on admet en general dans les previsions une amelioration de 10% tous les 18 mois.
D'ailleur on remarque deja que la bande passante memoire des systemes mobiles commence a avoir une belle tete de plateau au lieu de la courbe exponentielle de Moore. Ca pose un gros probleme, car meme en ayant CPU plus performant, si ta memoire n'est pas capable de l'alimenter, et bien ca ne sert a rien. Hors aujourd'hui, meme un CPU mono-coeur est capable de saturer la bande passante de la memoire d'un telephone mobile. Voila pour les contraintes, donc je ne pense vraiment pas que tu auras un equivalent de i7 dans ton telephone bientot.
Non, faut arreter de dire des betises la ! En dessous de 60fps, ca laggue et ce n'est pas agreable. En dessous de 30fps, c'est horrible ! En dessous de 20fps, c'est pas loin d'une soiree diapo ! Faut etre serieux quand meme, ne pas etre capable de sortir 60fps est un probleme. Qui souleve des questions :
Consommation memoire ? Important lorsqu'on n'a pas de swap, peu de memoire et qu'on veut faire du multitache sans perdre toutes ses donnees des que la 3ieme application est lance.
Consommation CPU ? Si on a du mal a atteindre les 60fps, est-ce qu'il reste de la marge pour faire d'autre tache ou alors le systeme est juste deja completement charette ?
Tu sais qu'il y avait des reacteurs nucleaires naturels (qui ont ete stoppe par l'homme durant les dernieres decennies). Comme dit plus haut quelque soit l'energie que tu choisies, elle fait des degats sur l'environnement. Il n'y a pas d'energie propre et meme si il y en avait, nous utilisons l'energie pour changer le monde, donc son resultat n'est jamais propre. Il faut arreter de vouloir se donner bonne conscience et comprendre qu'il y a des consequences au mode de vie de tous les humains sur cette planete.
[^] # Re: Un petit rappel
Posté par cedric . En réponse au journal Intel boycotte officiellement le serveur d'affichage Mir. Évalué à 2.
C'etait un message a charactere informatif !
[^] # Re: Un petit rappel
Posté par cedric . En réponse au journal Intel boycotte officiellement le serveur d'affichage Mir. Évalué à 10.
Joli simplification ! Peut etre est-ce plutot parce que cela supporterait l'effort de fragmentation et de controle de Ubuntu sur le l'environnement graphique libre (Mir, c'est peut etre open source, mais ca manque un peu de contribution communautaire et c'est un code entierement controle par Ubuntu sans aucune valeur technique par rapport a Wayland). Peut etre aussi que l'effort de maintenance qui retombe sur l'upstream (Intel) ne donne de gain a personne d'autre qu'a Ubuntu.
Et dans le fond, si ils veulent faire leur propre fork de Linux, il est temps qu'ils acceptent d'en payer le prix. C'est a dire la maintenance dans son integralite et qu'ils arretent d'ennuyer les differents projets upstream avec leur communication marketing !
[^] # Re: drivers graphiques
Posté par cedric . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 5.
Quel est ta version de noyau et driver ? Tu utilises quoi comme composite manager et avec quelle version ?
[^] # Re: drivers graphiques
Posté par cedric . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 4.
Un driver Intel Ivy Bridge sur Arch Linux. Quand tu edites du texte, en general, il n'y a que le curseur qui clignote pas bien vite et un peu de texte qui s'ajoute pas bien vite aussi. Alors forcement le software a un enorme avantage :-) Aussi j'utilise le compositeur software d'enlightenment compile specialement pour mon pc. Le tout tester avec PowerTop et c'est reproductible.
[^] # Re: Lien complémentaire
Posté par cedric . En réponse à la dépêche Microsoft rachète les téléphones de Nokia. Évalué à 2.
Comme le fait remarquer si bien la page de Wikipedia, l'effet Osborne est tres loin d'etre demontre. Et je pense que le ralentissement massif des ventes de Nokia n'a rien a voir avec.
Symbian etait un OS vraiment catastrophique pour les developpeurs et les utilisateurs. La concurrence est devenu juste meilleur et moins chere. Point. Pas la peine d'y voir autre chose. Les gens n'achetent pas un telephone comme un parie sur l'avenir. De toute facon, ils vont en changer dans 2 ans et Symbian, Android ou iOs ne change pas grand chose… si ce n'est l'usabilite !
[^] # Re: drivers graphiques
Posté par cedric . En réponse à la dépêche Entretien avec Jérôme Glisse, développeur des pilotes graphiques radeon pour Red Hat. Évalué à 5.
Pour une certaine definition de optimale ;-) Pour certain cas d'utilisation, tel que editer du code dans un editeur texte quand on est sure batterie, le fait d'utiliser OpenGL pour faire le compositing au lieu du CPU augmente sensiblement la consomation de batterie (Je perds 1W, ce qui represente sur mon PC 1h d'autonomie).
Il est probable qu'avec le support du buffer age et de la mise a jour partiel dans Wayland, ces chiffres ne soit plus les meme. Mais pour l'instant, avec X, quand je suis sur batterie, j'evite d'utiliser OpenGL.
[^] # Re: Ni l'un ni l'autre
Posté par cedric . En réponse au journal SDL2 ou SFML2 ou ... ?. É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 cedric . En réponse au journal SDL2 ou SFML2 ou ... ?. Évalué à 0.
[^] # Re: Ni l'un ni l'autre
Posté par cedric . En réponse au journal SDL2 ou SFML2 ou ... ?. É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 cedric . En réponse au journal SDL2 ou SFML2 ou ... ?. É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 cedric . En réponse au journal SDL2 ou SFML2 ou ... ?. É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 cedric . En réponse au journal SDL2 ou SFML2 ou ... ?. É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: Limiter l'importance du choix
Posté par cedric . En réponse au journal SDL2 ou SFML2 ou ... ?. É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 cedric . En réponse au journal SDL2 ou SFML2 ou ... ?. É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: Ni l'un ni l'autre
Posté par cedric . En réponse au journal SDL2 ou SFML2 ou ... ?. É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) ?
# Ni l'un ni l'autre
Posté par cedric . En réponse au journal SDL2 ou SFML2 ou ... ?. É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: Limiter l'importance du choix
Posté par cedric . En réponse au journal SDL2 ou SFML2 ou ... ?. É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: SFML
Posté par cedric . En réponse au journal SDL2 ou SFML2 ou ... ?. É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.
[^] # Re: capacité réclamé par les applications ?
Posté par cedric . En réponse à la dépêche Firefox OS est lancé. Évalué à 5.
Cyanogenmod propose cela si je ne me trompe pas. C'est une fonctionnalite que j'ai toujours voulu avoir dans un Android grand public, mais il faut croire que ce n'est pas une priorite que de proteger ses utilisateurs…
[^] # Re: Liberté ?
Posté par cedric . En réponse à la dépêche Firefox OS est lancé. Évalué à 4.
Je me suis mal exprime et n'est pas ete assez claire. Ce n'est pas une instruction en elle-meme, mais la combinaison, micro-architecture et systeme memoire, qui donne pour une tache equivalente la meme consomation d'energie. J'ai fait une vite recherche sur Google et je crois que le papier ci-dessous est ma source pour cette information :
http://research.cs.wisc.edu/vertical/papers/2013/isa-power-struggles-tr.pdf
[^] # Re: HTML5
Posté par cedric . En réponse à la dépêche Firefox OS est lancé. Évalué à 2.
Plus maintenant ! C'est Android qui a sauvé java. Il y avait un trend avant Android a la diminution du nombre de programme en java. Depuis ça a changé !
[^] # Re: Liberté ?
Posté par cedric . En réponse à la dépêche Firefox OS est lancé. Évalué à 9.
Pour faire simple, non. Pour le detail, la principale difference entre le monde du mobile et ton PC, c'est l'alimentation electrique et la densite en energie que doit contenir ta batterie. Il faudra bientot une densite superieur a des explosifs comme le TNT… Ce qui donne une contrainte. Certe on augmente la complexite des SoC en multipliant les coeurs dedies pour optimiser la consomation d'energie. On augmente aussi la quantite de memoire. Mais au final, un ARM et un x86 ont la meme efficacite energetique par instruction, ce qui veut dire que ton CPU generaliste est deja aussi performant energetiquement parlant que ton telephone. Ton telephone est plus lent parce qu'il doit consommer moins de batterie. Et les batteries ne suivent pas la loi de Moore, on admet en general dans les previsions une amelioration de 10% tous les 18 mois.
D'ailleur on remarque deja que la bande passante memoire des systemes mobiles commence a avoir une belle tete de plateau au lieu de la courbe exponentielle de Moore. Ca pose un gros probleme, car meme en ayant CPU plus performant, si ta memoire n'est pas capable de l'alimenter, et bien ca ne sert a rien. Hors aujourd'hui, meme un CPU mono-coeur est capable de saturer la bande passante de la memoire d'un telephone mobile. Voila pour les contraintes, donc je ne pense vraiment pas que tu auras un equivalent de i7 dans ton telephone bientot.
[^] # Re: Liberté ?
Posté par cedric . En réponse à la dépêche Firefox OS est lancé. Évalué à 10.
Non, faut arreter de dire des betises la ! En dessous de 60fps, ca laggue et ce n'est pas agreable. En dessous de 30fps, c'est horrible ! En dessous de 20fps, c'est pas loin d'une soiree diapo ! Faut etre serieux quand meme, ne pas etre capable de sortir 60fps est un probleme. Qui souleve des questions :
Consommation memoire ? Important lorsqu'on n'a pas de swap, peu de memoire et qu'on veut faire du multitache sans perdre toutes ses donnees des que la 3ieme application est lance.
Consommation CPU ? Si on a du mal a atteindre les 60fps, est-ce qu'il reste de la marge pour faire d'autre tache ou alors le systeme est juste deja completement charette ?
Consommation batterie ?
[^] # Re: et l'éthique ?
Posté par cedric . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 2.
Wikipedia et Google sont tes amis… Mais bon, je vais t'aider : http://fr.wikipedia.org/wiki/R%C3%A9acteur_nucl%C3%A9aire_naturel_d'Oklo
Et toi, super hero qui veut sauver la planete ? C'est quoi ton super pouvoir ? il va en falloir un costeau !
[^] # Re: et l'éthique ?
Posté par cedric . En réponse à la dépêche Ubuntu Edge, premier smartphone Canonical : convergent, haut de gamme, financement participatif. Évalué à 1.
Tu sais qu'il y avait des reacteurs nucleaires naturels (qui ont ete stoppe par l'homme durant les dernieres decennies). Comme dit plus haut quelque soit l'energie que tu choisies, elle fait des degats sur l'environnement. Il n'y a pas d'energie propre et meme si il y en avait, nous utilisons l'energie pour changer le monde, donc son resultat n'est jamais propre. Il faut arreter de vouloir se donner bonne conscience et comprendre qu'il y a des consequences au mode de vie de tous les humains sur cette planete.