Recherche bilbliothèque 2D

Bonjour à tous,

En espérant ne pas ouvrir un x-ième topic sur le même sujet, je voudrais avoir la réponse à cette question : Quelle est la bibliothèque la plus efficace, sachant que je travaille sur un projet sur lequel je ne fait que du pixel par pixel, en dessinant directement les pixels en utilisant leur adresses : je ne passe donc pas par des fonction compliqué donnée par ma bibliothèque.

J'ajoute que je travaille avec la SDL, avec laquelle je travaille bien, mais dont je peut facilement changer puisqu'elle ne me sers uniquement à gérer la fenêtre et la mise à jour de l'écran.

De fait, j'avais entendus dire que la SDL n'était pas la meilleure bibliothèque, et qu'il valais mieux utiliser la SFML.

Quel est votre avis sur la question ?

En vous remerciant d'avance pour vos réponses,

Lapotose

De ce que j'ai constaté, la SFML est en effet plus efficace (il semble qu'elle utilise "vraiment" le GPU, contrairement à la SDL qui reste beaucoup plus sur le CPU).
Mais attention, la SFML ne fonctionne qu'en C++ il me semble !

C'est vrai que la SDL est pas mal mais comme dit, n'utilise pas directement le GPU cela dit, on peut utiliser des buffer matériels si je me souviens bien, à vérifier. SDL 2 encore en cours de développement mais utilisable je crois utilise quant à elle, le GPU il me semble.

Il me semble également qu'il existe un binding pour le C en ce qui concerne la SFML d'après ce qu'un de ces créateurs m'a une fois dit mais ca remonte à un certains temps.

Bonjour,

La SFML a bien un binding C : la CSFML

Sinon, il y a la manipulation directe d'openGL, qui reste envisageable (il suffit souvent d'une camera orthographique)

Mais j'ai un penchant pour la SFML (dont la version 2.0 vient de sortir)

Il y a aussi une autre possibilité, si c'est seulement du travail pixel par pixel et sans affichage: taper dans le fichier image lui-même.

Citation:

---

Envoyé par Franck.H

C'est vrai que la SDL est pas mal mais comme dit, n'utilise pas directement le GPU cela dit, on peut utiliser des buffer matériels si je me souviens bien

---

Si tu parles de surface type SDL_HWSURFACE, je penses qu'il faut plutôt éviter dans certains cas (mais je ne retrouve plus mes sources qui datent de matuzalem).

Pour travailler pixel par pixel, tu vas utiliser soit le CPU, soit le GPU (shaders) pour les calculs. En partant de là, la lib ne sert effectivement qu'a afficher l'image de travail et l'argument de l'accélération de la lib par le GPU ne change rien.

Je te conseille d'écrire ton algo d'abord sur CPU (plus simple, mais moins performant), puis de le parallélisé sur GPU avec les shaders (nécessite de comprendre/apprendre la prog parallèle).

Si tu fais que du CPU, choisit peut être la lib qui correspond "nativement" à ton langage : SDL pour le C et SFML pour le C++ (mais c'est vraiment qu'une question de goût)
Si tu souhaites passer par les shaders, utilise une lib moderne. Donc SFML 2 qui vient de sortir (elle a la préférence des devs actuellement) ou la SDL 2 en cours de dev.
Tu peux également utiliser directement OpenGL, ce qui te garantira une portabilité maximale (quelque soit la lib, voir quelque soit le langage)

En complément, parce qu'il faut bien que je vende ma lib préféré, si tu souhaites utiliser les shaders, tu peux également tester Qt : il fournit les classes ShaderEffect qui permettent d'écrire directement les shaders, sans avoir à se préoccuper (trop) du reste. Voir la doc pour un exemple d'effet pixel par pixel en quelques lignes : http://doc-snapshot.qt-project.org/q...dereffect.html

Bon courage

Merci à tous pour vos réponses très pertinentes !

Au vu des informations que vous me donnez, je pense rester sur la SDL pour le moment, car j'y suis à l'aise. De plus, comme je travaille en pixel par pixel, je pense effectivement ne pas changer car :

Citation:

---

gbdivers : Pour travailler pixel par pixel, tu vas utiliser soit le CPU, soit le GPU (shaders) pour les calculs. En partant de là, la lib ne sert effectivement qu'a afficher l'image de travail et l'argument de l'accélération de la lib par le GPU ne change rien.

---

Donc pour l'instant pas de changement, on verra plus tard...

Merci encore pour toutes vos réponses, et je laisse le topic ouvert encore quelque temps si vous avez d'autres remarques à me faire...

Moi je te conseillerai , et je le conseil toujours a ceux qui débute sur cette lib qu'est la SDL , de faire de la basse résolution (surtout si tu bosse pixel par pixel) , pour certain c'est dur a comprendre mais afficher pixel par pixel ud 800x600x4 en 60 fps ça tue le CPU :aie:
et ça pour un blit , je parle pas des autres blits qui seront assez conséquent pour une telle résolution.

Le 320x240 c'est largement correct et toute les vielles console supportait largement ce type de résolution qui est en terme de calcul et très faible , faut vraiment être parano pour se soucier des performances pour une tel résolution x).
Bon la résolution 640x480 est correct aussi (même si ça commence a flancher).

Si tu veux grossir ta fenêtre faudra passer par opengl (vu que faire un grossissement coter CPU c'est lourd) , ou alors tu fais un mode fullscreen et tu te casse pas la tete.

Bien compris !

Mais existe t-il par curiosité de faire du fullsrcreen avec une résolution du type 640*480 ?

ben oui avec la SDL ça donne ça.

Code:

---

1 2	screen = SDL_SetVideoMode(640,480,24,SDL_FULLSCREEN);

---

Tu peux mettre d'autre option avec http://www.libsdl.org/docs/html/sdlsetvideomode.html

Citation:

---

J'ajoute que je travaille avec la SDL, avec laquelle je travaille bien, mais dont je peut facilement changer puisqu'elle ne me sers uniquement à gérer la fenêtre et la mise à jour de l'écran.

---

Tu utilise donc pas SDL_Blitsurface donc ? pourquoi pas , pour ma part je pensais ne pas l'utiliser aussi ,mais c’était juste pour optimiser la mémoire/rendu 2D en utilisant le format pcx.

Je squat un peu le sujet... Je travaille actuellement sur un petit moteur 2D qui permettra d'afficher une fenêtre, des fenêtres à l'intérieur des programmes avec boutons, cases à cocher et tout le tatouin sans compter un petit garbage collector assez archaïque pour le moment et aussi de quoi mettre en place les bases des jeux qui tournerons avec comme un petit ordonnanceur de tâches qui permettra de gérer l'affichage des différentes parties d'un jeu....

Je connais la SDL et ses éventuelles lenteur étant donné que pour le moment elle n'utilise pas le GPU (la version 2.0 le fera ? et sera-t-elle compatible avec la 1.2 ?) mais je me demandais s'il n'était pas mieux d'utiliser quelque chose qui utilise le GPU comme OpenGL que au passage, je ne connais absolument pas du tout :aie:

Tous dépend de ce que tu fais j'ai jamais eu de souci de performance avec la SDL , Du coup pour moi j’espère que la SDL restera purement CPU (ça a ces avantage et inconvénient) , le version 2.0 est sorti il me semble mais en version unstable , j’espère en tous cas que la version 2.0 est compatible ,sinon ben je resterais a la 1.2.
Bref pour dire que moi si je fais un jeu 2D -> SDL.

Après un HUD j'en ai déjà fait , ça prend pas énorme en CPU , mais bon ça dépend beaucoup de la résolution comme toujours.

J'ai déjà fait de la 2D avec opengl ,oui niveau performance tu as moins de souci , après n’étant pas faite pour cela faut mieux coder quelque fonction 2D avec opengl pour en faire quelque chose.

Donc pour te répondre tous dépend de ce que tu fais mais pour répondre si tu fais une résolution 320x240/640x480 SDL est suffisante , plus il faut utiliser opengl.

Bin disons que c'est que pour du jeu 2D genre faire quelques remake d'anciens jeux (bubble bobble, tetris, arcanoid, etc...) d'époque ms-dos voir amiga ou de mon propre cru :P je ne pense pas dépasser du 640x480, un bon vieux 2D est plus joli légèrement pixelisé que trop lisse :mouarf:

Ok, merci à tous pour vos réponses, qui m'ont confirmé dans mon choix de garder la SDL.

Au fait, j'utilise bien SDL_BlitSurface() mais ce n'est pas ce qui me bloquerai le plus si je devais changer de bibliothèque. Par contre pour les performances, il est possible que je l'utilise, ca j'ai de plus des blits avec canal alpha à faire... mais ils ne viendrons que plus tard, pour l'instant c'est le pixel par pixel qui m'intéresse.

Citation:

---

Envoyé par Franck.H

Je squat un peu le sujet... Je travaille actuellement sur un petit moteur 2D qui permettra d'afficher une fenêtre, des fenêtres à l'intérieur des programmes avec boutons, cases à cocher et tout le tatouin sans compter un petit garbage collector assez archaïque pour le moment et aussi de quoi mettre en place les bases des jeux qui tournerons avec comme un petit ordonnanceur de tâches qui permettra de gérer l'affichage des différentes parties d'un jeu....

Je connais la SDL et ses éventuelles lenteur étant donné que pour le moment elle n'utilise pas le GPU (la version 2.0 le fera ? et sera-t-elle compatible avec la 1.2 ?) mais je me demandais s'il n'était pas mieux d'utiliser quelque chose qui utilise le GPU comme OpenGL que au passage, je ne connais absolument pas du tout :aie:

---

Perso il y'a plus de 6 ans j'avais ecrit un petit moteur basé sur la SDL .
Ce moteur permettre de créer des fenêtres avec des panel, contenant des composants etc avec un editeur visuel et tout... bref exactement ce que tu cherches. (J'en ai fait un synthetiseur modulaire appelé noobsynth (ici pour la référence et screenshots).

Il était au départ en SDL "normale" mais je me suis rendu compte au fur et a mesure que c'était beaucoup trop lent.
J'ai donc rajouter un support opengl (toujours avec la SDL) . Le rendu était équivalent sans changer le code utilisateur et donc la l'interface ne posait plus de problème des fluidités.

Donc perso je pense que la SDL couplée opengl est un très bon choix. Evidement je ne travaillais pas au "pixel" près durant les affichages (et heureusement).

J'ai presque terminer par avoir une sorte d'équivalent à Swing et j'étais extrêmement satisfait du résultat, je pouvais coder mes applications en l'utilisant facilement, rapidement.

Ouais effectivement ca à l'air pas mal mais je compte faire le miens quand même vu que je veux un comportement spécifique et une bibliothèque scindée en plusieurs parties. La base primaire pourra même servir, un peu comme la GLib, à des programmes autres que des jeux car elle n'est pas en SDL.

Je verrais bien au fil de l'avancement pour les performances :aie: