Bonjour,
Pourquoi utilisez vous la sdl alors qu'il y a une belle bibliothéque qui s'appelle sfml et qui corrige les bugs de la sdl ? quelles avantages a la sdl par rapport à la sfml ?
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Pourquoi la sdl ?
Bonjour,
Pourquoi utilisez vous la sdl alors qu'il y a une belle bibliothéque qui s'appelle sfml et qui corrige les bugs de la sdl ? quelles avantages a la sdl par rapport à la sfml ?
SDL 1.2 est mature, et supporte plus de plateformes il me semble.
A part ça, SFML a l'air bien mieux, alors que SDL 1.3 se fait attendre depuis bien trop longtemps.
en attendant la 1.3 de la sdl, je vais rester avec la sfml.
dernier edit : je me rends compte à la relecture de mon post qu'il peut paraitre un peu dur, ce n'est pas mon objectif. je ne change pas mon poste, mais je rajoute ici que le travaille effectué par Laurent sur SFML est tout simplement ahurissant, et merite notre respect. un grand bravo. Bravo a Laurent aussi pour son implication et le fait qu'il passe un temps dingue a repondre sur son forum à toutes les questions. SFML à un vrai devenir, il se pourrait qu'elle prenne un grande importance au niveau mondial dans les années a venir (comme ce fut le cas de SDL). Les critiques que je formule sont essentiellement dues à un projet tres jeune, qui doit prendre sa place, se structurer, s'etoffer, se diffuser, puis se stabiliser. donc voilà j'aime bien SFML (fin de l'edit)
je ne dirait pas qu'elle corrige les bug de la SDL, disons qu'elle apporte des fonctionalité supplémentaire (et d'autre en moins : fichier midi...)Envoyé par rikkkki
disons que sfml demande de coder differement (plus objet)
perso je ne trouve pas encore tout ce que j'aime de sdl dans le codage en sfml, alors le dev donne bien des workarounds pour reproduire le comportement de SDL par SFML mais je trouve que ca fait bidouille (j'ai en memoire le fait qu'on ne pouvais pas bliter une image dans une image, je ne sais pas si on peu dans la version en cours, mais le dev avait décidé que ca n'avait pas d'interet, ca a peut être changé, mais si j'ai envie de composer des images en dehors du rendu sur la page, ca me regarde moi en tant que developpeur de l'appli).
voilà, en puis aussi parce que je dev en 2D, alors openGL ne m'interesse pas (j'aime pas coder en openGL) alors oui je sais qu'on peu faire de la 2D avec openGL, mais bon ca reste du style "openGL" que j'aime pas.
Sdl est stable (trop peut être), j'ai commencé un projet il y a 3 ou 4 ans, j'ai passé les quelques mises a jour SDL sans avoir a retoucher une ligne de code... je ne suis pas sur qu'on puisse faire de même avec SFML (SFML n'existait même pas quand j'ai commencé ce projet d'ailleur) encore une fois c'est normal.
A oui, aussi, il se trouve que SDL utilise directX sous windows, pas sfml.
voilà je reste fidele a SDL, tres stable, correct, tres bien diffusé sur les distro linux.
Je jette quand même un coups d'oeuil, une fois par an, sur sfml pour voir où ca en est (c'est un super bon projet).
Et j'ai oublié : il existe plein plein de module pour etendre SDL, ce que n'a pas (encore) sfml. c'est un vrai plus.
a aussi : j'ai pas eu de mal a compiler mon appli avec CMAKE, j'ai trouvé tres facilement comment configurer CMAKE (je m'y connais peu en chaine de compilation, chacun son truc) j'ai ravi de trouver le necessaire (grace a la notorité de SDL)
Edit : je viens d'aller voir la SFML, Laurent nous prepare une version 2.0 qui sera du tonnere ! mais (et c'est bien normal vu la jeunesse du projet) on perdra la compabilité : il faudra recoder un peu votre appli pour passer d'une 1.x à 2.0. un truc qui m'inquiete avec SFML : il semble n'y avoir qu'un seul developpeur... en terme de perenité, c'est pas top.
+1, J'ai tout simplement l'impression que Laurent a penser a tout!
personnellement j'avais commencer avec SDL, et ça m'avais paru assez simple et j'avais réussit assez rapidement a pondre mes premier jeux (sans grand intérêt, mis a part l'apprentissage)
je m'était ensuite intéressé a la SFML, et là ça s'était compliqué, d'après moi, SFML demande une plus grande organisation, plus de technique, ainsi qu'un code très structuré pour être utilisé.
ça vient peut être de moi, mes exigences ont surement changés au court du temps ( et encore heureux, quand je vois mes premiers bouts de code...), mais peut être aussi du fait que ce soit de l'objet.
Une fois que cette structure est mise en place pour la SFML, c'est simplement magique, l'outil est tellement puissant... chaque problème a une solution presque évidente, en cas de problème Laurent est toujours prêt a aider sur son forum, il n'y a pas besoin d'ajouter n librairies supplémentaires, les rotations zoom ect... sont gérés. Sans parler des gros plus, l'accélération matériel, les shaders!! ect... Et je suis loin d'avoir fait le tout de toutes les fonctionnalités.
Bref, SFML vaux vraiment le coup de s'y intéressé, je l'ai adopté!
et avec l'opengl, vu que les 2 ( sdl et sfml ) utilisent l'accélération matérielle, laquellle vaudrait-il mieux choisir ?
Une chose a ajouter
SFLM, c'est que en C++
Pour le C, il y a cSFLM, mais j'ai eu des retour extremement négatif (doc & tuto completement absent, "ridicule" selon certain, bug omnipresent).
Bref, un tres gros avantage de SFLM par rapport a la SDL, c'est que SFLM utilise l'acceleration materiel, donc est plus rapide.
La SFLM inclu aussi nativement des fonction tel que le zoom, rotation, pour la SDL, faut regarder a coté (SGE, rotozoom).
Bref, en C++, la SFLM ecrase largement la SDL, en C, ca reste a demontrer.
D'autant plus que si on s'y debrouille bien, on peut faire des jeux SDL fluide est pas forcement degueu.
Si tu utilises OpenGL directement à mon avis c'est pareil.
Personnellement, j'avoue que je n'ai jamais utilisé la SDL par contre SFML, il m'est arrivé de l'utiliser lorsque je n'avais pas envie d'utiliser Qt et j'avoue que c'est effectivement une API vraiment bien foutu.
En ce qui concerne le choix entre SDL et SFML quand on fait de l'OpenGL, je dirais SFML mais juste parce que j'ai un coup de cœur pour cette API et que je ne connais pas réellement SDL mais je pense que les deux doivent avoir leurs points forts et leurs points faibles donc le choix se fera plus au feeling finalement.
SFML offre aussi la possibilité d'avoir plusieurs fenêtre simultanément ( et ça a l'air assez facile a gérer en plus ), il me semble que c'est impossible avec SDL
ou pas...
car SDL utilise aussi l'accelleration materielle, et n'est pas limité a opengl, car pour les plateforme win32, il y a directX aussi. donc en terme de possibilité, c'est SDL qui offre le choix le plus complet.
Ben justement !
je ne veux pas voir la bibliotheque principale avec du rotozoom...
il se trouve que SDL utilise une infrastructure modulaire, c'est un de ses avantages, personne n'utilise 100% des features, alors pourquoi alourdir ?
pensez a firefox : il y a des plugins, ainsi vous pouvez piocher dans les multiples extension pour ne charger que ce qui vous interesse.. ben la c'est pareil. si j'ai pas besoin de police ttf, ni de rotozoom, ben je prends pas.
ensuite vous pouvez me dire que le rotozoom de SFML est implementé de maniere plus intelligente ou plus optimisée, c'est sans doute vrai. mais c'est un autre debat.
mais l'argument de la bibliotheque foure-tout, ou plein de fonctions sont natives tout ca juste pour ne pas distribuer 3 ou 4 dll, franchement... de toute maniere il faut bien en distribuer au moins une, alors pourquoi pas 3 ou 4 je ne vois pas ce que celà change ?
SDL : qu'on l'utilise dans un soft dev en C ou en C++ je ne vois pas ce que celà change en perf.
soyons précit, une bibliotheque fait pour du C++ (comme la SFML) offre des agrements au developpeur (espace de noms...) donc le seul temps qu'on est sûr de gagner c'est du temps de développement, rien a voir avec le temps d'execution (qui lui dependra peut être plus du compilo par exemple)
Donc si (j'en sais rien) SFML est plus rapide que SDL (même machine en utilisant le même driver : opengl par exemple) et bien c'est pas parceque l'un est en C et l'autre en C++, mais peut être parceque l'implementation de telle fonction est plus intelligente et/ou avec le bon compilo et les bonnes options.
oui tout reste a demontrer.
Et pas avec des tests tout moisis ou tu a une appli SDL qui tourne en GDI non optimisé contre une appli SFML openGL...
bien sur, ce qui prouve que la lib n'est pas tout, la maniere de coder l'appli compte aussi.
oui ça c'est vrai, c'est un vrai plus de SFML. (que je n'utilise pas dans un jeu)
Bon, puisque la question de la performance est abordée...
Je ne sais pas si beaucoups d'entre vous ont faits des tests (de maniere serieuse), mais je penses qu'il y a des choses qu'un débutant doit absolument savoir avant de choisir SDL ou SFML, et ne pas s'en ternir à des propos tout fait "sfml écrase sdl", c'est plus complexe que celà.
GENERALITE
Avant de parler performance, je rappelle que SDL est plus vieu que SFML, qu'il y a moins de fonctions implementées, mais que SFML est un peu plus instable (au niveau de l'API, pas de l'execution), mais que SDL permet d'ajouter des sorte de plugins (et il y en a plein, et de qualité diverses)
PERFORMANCE
il faut ensuite cibler la plateforme d'execution, il y a ceux qui veulent faire un jeu windows et ceux qui veulent faire un jeu multiplateforme.
* multiplateforme : question performance la question ne se pose pas : un seul choix, OpenGL. SFML comme SDL sont compatible.
* win32-only : Là c'est soit DirectX soit OpenGL. ensuite je ne sais pas ce qu'il y a de mieux... il faut reconnaitre que microsoft a bouffé le marché win32 avec son directX, ça ne doit donc pas être une bouse...
Jusqu'a preuve du contraire, seul SDL est compatible DirectX, même en 2D, il suffit de mettre une ligne pour que toute votre appli tourne sous directx :
DISTRIBUTION
Code : Sélectionner tout - Visualiser dans une fenêtre à part SDL_putenv("SDL_VIDEODRIVER=directx");
Maintenant la question qu'il faut se poser c'est : comment distribuer votre jeu ?
* windows : un zip ou un setup, aucune difficultée. pour sdl ou sfml.
* linux : soit en source (à compiler : config, make, make install) soit en package, mais dans tous les cas sous serez confronté à l'epineuse question des dépendances! Et le probleme (et je le deplore) c'est que pour trouver les packages sfml dans les distro c'est pas facile. Même si vous faites le necessaire pour faire compiler sfml en même temps que votre appli, il y a les dépendances de sfml (la lib qui affiche les images, qui gere les fonts...) et bien bon courage...
sous linux, le choix de la maturité n'est pas incoherent... et être bleeding-edge c'est un luxe qui necessite des competence et du temps.
Je suis pragmatique : le jour ou le deployement sera facilité (package sfml dans les majeurs distro) je serai super ravi mais en attendant, égoistement j'utilise ce qu'il se deploie de maniere simple ! (car on trouve les package sdl dans toutes les distro).
Oui c'est un peu egoiste : je laisse les autres s'occuper des packages, et j'attends qu'ils soient bien déployé (compter quelques années, pensez a debian)...
voilà ce à quoi il faut penser quand on choisit une lib
Je me permets de répondre sur certains points, car d'après moi il y a quelques raccourcis dangereux qui commencent à être pris
SDL n'utilise pas l'accélération matérielle. Et quand elle donne l'illusion de le faire, ce n'est pas ce que tu crois.car SDL utilise aussi l'accelleration materielle, et n'est pas limité a opengl, car pour les plateforme win32, il y a directX aussi. donc en terme de possibilité, c'est SDL qui offre le choix le plus complet.
En ce qui concerne DirectX, attention à ne pas tout amalgammer. SDL utilise DirectDraw, qui est une technologie préhistorique et plus supportée depuis longtemps par Microsoft, à ne surtout pas comparer à Direct3D et OpenGL.
Pour faire de la 2D, OpenGL et Direct3D sont tous deux largement suffisant, ce n'est pas un critère de choix. La différence sera fera plutôt sur les toutes dernières techniques à la mode, que telle ou telle API implémentera mieux ou pas. Mais pour dessiner des carrés, y a franchement aucune différence.* win32-only : Là c'est soit DirectX soit OpenGL. ensuite je ne sais pas ce qu'il y a de mieux... il faut reconnaitre que microsoft a bouffé le marché win32 avec son directX, ça ne doit donc pas être une bouse...
Jusqu'a preuve du contraire, seul SDL est compatible DirectX, même en 2D, il suffit de mettre une ligne pour que toute votre appli tourne sous directx :
Là on parle alors d'OpenGL, plus de SFML ni SDL.* multiplateforme : question performance la question ne se pose pas : un seul choix, OpenGL. SFML comme SDL sont compatible.
SFML vise justement à avoir le même genre de performances qu'OpenGL, mais sans que l'utilisateur n'ait à toucher à OpenGL.
On peut aussi faire un package "self-contained" avec ses dépendances, ce n'est pas un problème sous Linux.* linux : soit en source (à compiler : config, make, make install) soit en package, mais dans tous les cas sous serez confronté à l'epineuse question des dépendances!
Effectuer des transformations sur une forme que l'on affiche, ça ne me paraît pas être du superflu à mettre dans un plugin. Ca fait partie des fonctionnalités de base, je ne vois pas du tout pourquoi il faudrait le mettre à part.Ben justement !
je ne veux pas voir la bibliotheque principale avec du rotozoom...
A mon avis ton opinion est déjà un peu trop biaisée par ton expérience de SDL
Techniquement SDL ne fait rien de spécial, elle n'a pas une infrastructure modulaire. C'est simplement que c'est du bas niveau, et donc que tout le monde peut écrire du code par dessus pour ajouter des fonctionnalités.il se trouve que SDL utilise une infrastructure modulaire, c'est un de ses avantages
Rien n'empêche de faire la même chose avec SFML, d'ailleurs certaines personnes l'ont déjà fait.
Je suis d'accord avec toi sur le point des DLLs, mais ce n'est pas l'argument principal. Le gros hic avec SDL et ses add-on, c'est que rien n'est unifié, que ce soit au niveau de la qualité, des conventions de codage, des APIs, de la documentation, sites web, support, etc. Tout est disséminé dans la nature et implémenté sans cohérence, puisque chaque projet est totalement indépendant.mais l'argument de la bibliotheque foure-tout, ou plein de fonctions sont natives tout ca juste pour ne pas distribuer 3 ou 4 dll, franchement... de toute maniere il faut bien en distribuer au moins une, alors pourquoi pas 3 ou 4 je ne vois pas ce que celà change ?
Et SFML n'est pas fourre-tout, bien au contraire : son API reste ultra-légère, et crois moi que je me bats suffisamment avec les utilisateurs pour que ça le reste (tu n'imagines pas le nombre de demandes que je rejette tous les jours).
Mieux que SDL : découvrez SFML
Mes tutoriels 2D/3D/Jeux/C++, Cours et tutoriels C++, FAQ C++, Forum C++.
Merci pour ton intervention,
C'est sur.A mon avis ton opinion est déjà un peu trop biaisée par ton expérience de SDL
Je ne suis qu'un peu (de temps en temps) sfml, j'étais là au depart (j'ai posé quelques questions) mais j'attends la maturité.
mea culpa, tu m'apprends qqchose, je pensai que directdraw (qui était une partie de directx) était la couche qui permetait l'accelleration materielle (enfin si le driver du constructeur le permetait)
Ensuite directdraw est vieux ("préhistorique " ouais), mais on a un probleme similaire avec openGL assez mal implementé dans les cartes gfx (ou du moins si mais une version assez vieille... j'avais entendu dire que les constructeur n'était pas pressé d'implementer les dernieres version)
mais comme tu l'as dit, pour afficher des carrés, il n'y a pas de difference.
intention trés louable. j'ai toujours été rebutté par l'aspect codage openGL.
Ouais ?... bon moi perso je vais quand même attendre que les packages kivonbien arrivent dans les dépots.
Je suis d'accord, je l'ai dis il y a de tout (toute sorte de qualité)
Bon moi perso le ttf et le rotozoom j'utilise pas (mais je comprends que ca depanne bien si c'est built-in)
je ne voulais pas le dire dans le sens "bordel", mais dans le sens "plein de feature".
la rançon du succes
Encore une fois, le seul reproche que je fait à SFML, ce n'est pas l'implication et la motivation qui tu y apporte, c'est juste la jeunesse du projet. Il est probable que je passe à SFML dans quelques temps.
Et je me bat contre l'idée que "par définition" sfml explose sdl en performance.
ensuite en performance de codage, j'en doute pas (documentation etc).
Merci, bonne continuation.
Bonjour a tous,
Dernièrement, j'ai commencé un nouveau projet ( http://www.developpez.net/forums/d96...nce-wars-like/ ), de jeu en 2D. Du coup j'ai été confronté au choix entre SDL et SFML. Et au dernier moment, j'ai choisi SDL ( la prochaine fois ce sera SFML)
Je pense avoir une bonne raison pour avoir choisi la SDL, malgré qu'au tout début je n'étais pas du tout partant pour cela.
Effectivement, mon projet vise aussi des plateformes "ésotériques" tel que la GP2X et AmigaOS, qui, jusqu'à preuve du contraire, ne sont pas supportés pour la SFML.
Après, comme vous avez parlé de l'impact en terme de performance, il faut savoir ( et cela a été dit ) que la SDL n'a aucune accélération matérielle. Le direct draw n'est que la bibliothèque qui se cache derrière la SDL pour afficher les carrés ...
Du coup, comme je l'ai expliqué sur mon post, pour être sur de ne pas perdre en terme de performance, je vais avoir une partie du code en OpenGL ( cela ne me gêne pas trop, je connais :p ) afin d'être sur que cela soit pris par une puce accélératrice ( même si dans la théorie, pour un jeu comme le mieux, il se peut que je n'en ai pas besoin )
Après, pour conclure mon message, je conseillerai d'utiliser la SFML au lieu de la SDL, simplement parce que tout est mieux dans la SFML ( argument très débile, mais vous trouverez le pourquoi plus haut ). Les seuls cas ou l'on ne peut pas, c'est mon cas de plateforme dites "àlacon", ou que vous ne connaissez pas le C++
Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi
Ma page sur DVP
Mon Portfolio
Qui connaît l'erreur, connaît la solution.
Elle permet un certain niveau d'accélération matérielle, mais uniquement pour les transferts de pixels. C'est assez vieux comme concept.mea culpa, tu m'apprends qqchose, je pensai que directdraw (qui était une partie de directx) était la couche qui permetait l'accelleration materielle (enfin si le driver du constructeur le permetait)
On est très loin de ce qu'on appelle "accélération matérielle" aujourd'hui, à savoir utiliser des textures et des primitives, et laisser le GPU transformer et rasterizer le tout.
A priori il suffit de faire en sorte que l'applicatoin se lance via un script qui ajoute "." à la variable d'environnement LD_LIBRARY_PATH, et les bibliothèques qui se trouvent à côté de l'exécutable seront automatiquement trouvées lors de son exécution.Ouais ?... bon moi perso je vais quand même attendre que les packages kivonbien arrivent dans les dépots.
J'ai aussi vu récemment qu'on pouvait directement inclure à un binaire un chemin de recherche pour ses dépendances (rpath). J'ai pas trop creusé la question ceci-dit.
Bien entenduEt je me bat contre l'idée que "par définition" sfml explose sdl en performance
Par contre on peut constater que la version 1.2 de SDL a atteint une limite technique et qu'elle ne pourra pas faire mieux avant la sortie de la version 1.3.
SFML étant plus jeune, elle a pu partir sur des bases techniques optimales et ne traîne pas de vieilles technologies.
Mieux que SDL : découvrez SFML
Mes tutoriels 2D/3D/Jeux/C++, Cours et tutoriels C++, FAQ C++, Forum C++.
Beaucoup de réponse depuis la derniere fois.
@hpfx : J'ai vu des brenshmark fait par laurent gomila et d'autre ou l'on comparer la SDL (sans openGL) et la SFLML (sans openGL)
Le seul reproche, c'est que je crois qu'on utiliser pas SDL_DisplayFormat ce qui biaisé les resultat de facon totalement anormal.
On avait donc SFLM 12000% de fois plus rapide que SDL sur le blittage. Je n'y ai accordé aucun credit.
Par contre, pour les rotation, j'ai bien regarder le code et je dois dire que SFLM est vraiment mieux que SDL.
Bref.
@Laurent Gomila
Je n'ai pas suivi vraiment le developpement de cSFLM, mais qu'en est-il ?
est ce vous qui l'avez developpé ? Avez vous des retours ? Ces retours sont'il positif ou negatif ?
J'aimerai avoir une reponse de source sûr, j'aime pas accorder trop de credit au ragot.
Ca a été corrigé depuis longtemps, du moins dans le benchmark que j'avais fourni.Le seul reproche, c'est que je crois qu'on utiliser pas SDL_DisplayFormat ce qui biaisé les resultat de facon totalement anormal.
On avait donc SFLM 12000% de fois plus rapide que SDL sur le blittage. Je n'y ai accordé aucun credit.
Par contre, pour les rotation, j'ai bien regarder le code et je dois dire que SFLM est vraiment mieux que SDL.
En ce qui concerne les rotations, comme toute autre transformation il est normal qu'il n'y ait aucune comparaison possible : avec SDL c'est fait pixel par pixel "à la main" alors qu'avec SFML c'est le GPU qui s'en occupe, c'est donc quasiment gratuit.
CSFML ? Le binding C ? Personnellement je ne le maintiens que dans le but de créer d'autres bindings par dessus, donc je n'ai pas grand chose à en dire, c'est uniquement une version C de l'API C++.Je n'ai pas suivi vraiment le developpement de cSFLM, mais qu'en est-il ?
est ce vous qui l'avez developpé ? Avez vous des retours ? Ces retours sont'il positif ou negatif ?
Mieux que SDL : découvrez SFML
Mes tutoriels 2D/3D/Jeux/C++, Cours et tutoriels C++, FAQ C++, Forum C++.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager