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