Discussion :

[Kannagi]

Pour les performances, oui la SFML est plus rapide, mais que si on l'utilise correctement. Un noob (comme moi), qui utilise mal la SFML, peut se retrouver avec une chute de performance, à cause d'une mauvaise utilisation de la classe, ou un autre truc idiot.
Après, je n'ai pas fait l'amalgame plus haut niveau == plus lent. Je sais que dans les fait , dès que l'on atteint de plus grande résolutions la SFML est plus rapide

Le portage est une bonne chose, car beaucoup trop de développeurs se limite à penser uniquement "Windows". Le portage apporte l'apprentissage d'un générateur de Makefile (CMake ou autre), d'une programmation plus stricte (car souvent les compilateur pour les consoles portables sont plus limités). Donc, pourquoi se priver d'un portage lorsque celui-ci n'est pas si difficile que ça (pour peu que l'on y pense dès le début).

Je rejoins LittleWhite , les performances sont souvent lié a la bonne utilisation de la lib (déjà joué sur une démo de jeu utilisant la SFML ça l’empêcher pas de ramer).

Mais les jeux de incubateur seront a mon avis sur des basses résolution donc les performances gagnés ne seront pas si grand , la SDL est pas faite pour les grosse résolution (mais d'un point de vue perso je préfère passer sur opengl si je dois utiliser des résolution plus grosse).

[LittleWhite]

Qu'est ce que vous appelez basse résolutions ?
Je pense que 800x600 n'est pas mal du tout (sachant que le jeu Atomix a été sur Atari ST, qui était très loin de cette résolution ).
L'autre point que l'on peut voir, c'est que si la surcouche de la bibliothèque est bien réalisé, il n'est pas difficile d'imaginer un changement de la bibliothèque, pour de l'OpenGL ou même du Qt (le NEngine permet de faire ce changement, rapidement).

[Kannagi]

j'appelle basse résolution pour les jeux étant a 640x480 ou moins (le plus courant pour les vieux jeux c'est 320x240).

Pour Atomix ça résolution est 320x240 apparament donc j’espère que celui qui fera le jeu respectera cette résolution (et mettra une option fullscreen ou un touche pour le plein écran).
Je trouve 800x600 beaucoup et c'est limite pour la SDL.

Oui Si on prog bien il est facile de changer de lib avec la SDL ( je l'ai déjà fait SDL a opengl en changeant quasiment pas de code).

[LittleWhite]

800x600 c'est ok pour la SDL (surtout pour un jeu comme Atomix). Pour au dessus, je ne me prononcerai pas

Oui Si on prog bien il est facile de changer de lib avec la SDL ( je l'ai déjà fait SDL a opengl en changeant quasiment pas de code).

[gbdivers]

Euh... je connais pas trop la SDL, mais si vous dites que l'on peut pas faire un jeu 2D en 1440 sur 900 sur mon portable vieux de 4 ans, c'est qu'il y a un problème avec la lib (ce que j'ai du mal à croire) ou avec le développeur (possible ? )
Ou alors je me fais beaucoup d'illusion sur les capacités de mon portable ?

[screetch]

avec des blits hardware dans la SDL, on peut très facilement atteindre des résolutions hautes. Il faut quand même être sûr de pouvoir utiliser l'accélération 2D

je ne sais pas si la SFML utilise l'accélération 2D par exemple.

[LittleWhite]

En fait, sous Windows, même si on demande à avoir l'accélération matérielle (SDL_HWSURFACE), la SDL retourne une SDL_SWSURFACE (et indique que l'accélération matérielle n'est pas présente). Je n'ai vu que la GP2X pour le moment à avoir l'accélération matérielle.
Peut être que la SDL 1.3 améliorera cela, mais pour l'instant c'est toujours en développement.
Sinon, la lenteur peut peut être venir du fait que la SDL utilise une très vieille version de DirectX (DirectDraw?).
Pour SFML, si j'ai bien compris, tout est accélérer, car cela utilise OpenGL.

[gbdivers]

On parle quand même de jeux qui ne vont pas mettre à genou les ordinateurs même ancien (regardez la page des projets). Donc même sans accélération matériel, si j'ai pas un FPS à 500, je tape sur les doigts de LittleWhite.

Peut être que la SDL 1.3 améliorera cela, mais pour l'instant c'est toujours en développement.

La développement de la SDL à reprit ?

[LittleWhite]

Oui, la SDL 1.3 est en développement (depuis un bon bout de temps ) -> http://www.libsdl.org/hg.php (et les sources -> http://hg.libsdl.org/ )

Actuellement, OpenAWars, dans VS2008 en debug tourne à environ 380 FPS (et la résolution est très petite, mais aucune optimisation car tous les éléments sont affichés à chaque image).
Toujours dans VS2008, en release, je tourne autour des 1000 FPS.

Ce soir, je ferai un test simple, pour la SDL, sur une grande résolution (sans OpenAWars et sans NEngine).

Pourquoi je disais qu'une bibliothèque pouvait être lente par une mauvaise utilisation, c'est que dans le cas de la SDL, pour améliorer les performances, il faut appliquer un SDL_DisplayFormat() sur les surfaces à afficher et aussi, éviter la transparence

Pardon, si je donne des mesures, il ne faut pas que j'oublie de spécifier la machine :
Geforce 8800 GTS
Intel Core 2 6600 (2,4Ghz)
2Go de RAM

[gbdivers]

Pardon, si je donne des mesures, il ne faut pas que j'oublie de spécifier la machine :
Geforce 8800 GTS
Intel Core 2 6600 (2,4Ghz)
2Go de RAM

Ouch, quelle bête de course (ton ironique puisque mon portable est moins puissant... je vais retourner au labo tester OpenAWars sur mon double i7 GTX580 x4 SLI !)

[screetch]

En fait, sous Windows, même si on demande à avoir l'accélération matérielle (SDL_HWSURFACE), la SDL retourne une SDL_SWSURFACE (et indique que l'accélération matérielle n'est pas présente). Je n'ai vu que la GP2X pour le moment à avoir l'accélération matérielle.
Peut être que la SDL 1.3 améliorera cela, mais pour l'instant c'est toujours en développement.
Sinon, la lenteur peut peut être venir du fait que la SDL utilise une très vieille version de DirectX (DirectDraw?).
Pour SFML, si j'ai bien compris, tout est accélérer, car cela utilise OpenGL.

hmmm apparemment il y a une version DirectX 5 quand même.
Au niveau de l'accélération 2D il y a beaucoup plus de plate-formes que ca qui utilisent l'accélération matérielle; il ne faut pas oublier que sous linux, le server X et donc par extension la SDL utilise une forme d'accélération 2D (blitting)
De même, la version "non accélérée" de Win32 utilise BitBlt qui est accélérée par la carte vidéo si disponible.

Si on a une version software integrale, ca veut dire que le blit est fait avec un memcpy ou quelque chose de ce genre, que le zoom est calculé en software, avec donc une complexité carrée, donc qui mettrait a genoux même un processeur puissant sur des surfaces trop grandes. Je ne sais pas quels drivers de la SDL ne sont pas "accélérés" dans ce cas.

On obtient bien entendu de meilleures performances en utilisant des textures OpenGL, mais même dans le cas ou l'on utilise la version X11 ou Win32 sans "surface hardware" elle est quand même accélérée.

[Kannagi]

La SDL peut pas avoir de bonne performance au haute résolution , elle travaille pixel par pixel , donc a chaque blit d'une image de 800x600 il parcours le tableau en entier ce qui n'est pas rien.
Et si on a plusieurs blit a faire le calcul deviens beaucoup plus important , on peut limité les calcul on limitant le nombre de Blit (mais c'est a prévoir a avance).

Donc j’espère avoir répondu a gbdivers pourquoi elle le permet pas , la lib n'a aucun souci , mais juste que niveau calcul en haute résolution y 'en aura beaucoup plus , et y a pas d'autre alternative que la logique de dessiner comme des 'calques' a part utiliser opengl.

[screetch]

La SDL peut pas avoir de bonne performance au haute résolution , elle travaille pixel par pixel , donc a chaque blit d'une image de 800x600 il parcours le tableau en entier ce qui n'est pas rien.

je pense que non.

[screetch]

apparemment, si, tu as raison (seuls les blits OpenGL, Dx5 sont possiblement accélérés sur windows)

[Kannagi]

J'allais te répondre que j'en étais quasi sur , oui seul les blits opengl/DX sont accélérer , le reste ça reste du software , et donc c'est un parcours d'un tableau, ce qui est lourd pour les haute résolution.
Pour les vieux PC , 800x600 avec la SDL c'est limite , les ordi plus récent auront moins de mal mais faudra pensé dans les 2 cas a optimisé.

[LittleWhite]

Voilà, j'ai enfin le benchmark (voir pièce jointe).

C'est un simple starfield.
On peut choisir la résolution et le nombre d'étoiles par la lignes de commandes (optionnel):

benchmark --width 1024 --height 768 --number 10000

Il n'y a pas grand chose à dire dessus. Il suffit juste de lier la SDL et ça compile.
Pour quitter, appuyez sur la touche échap.
Pour la commande donnée ci-dessus, j'obtiens:

Is hardware surface present ? : No
Is hardware blits accelerated ? : No
Is hardware colorkey blits accelerated ? : No
Is hardware alpha blits accelerated ? : No
Is software blits accelerated ? : No
Is software colorkey blits accelerated ? : No
Is software alpha blits accelerated ? : No
Is fill accelerated ? : No
FPS: 25
FPS: 26
FPS: 26
FPS: 25

Effroyable ?
Je suis sous Ubuntu 10.04 avec un i7 et une GTX 360 M.
Rien n'est accéléré, d'après la SDL sous Linux ...

Enfin, n'hésitez pas à donner vos résultats, à faire joujou avec le code et à me rapporter les erreurs (je ne suis pas à l'abris).

[Kannagi]

Je ferais pas d'autre test x)

Mais comme tu l'as surement déjà testé a basse résolution on atteint de très bon résultats.

Ce n'est pas étonnant je vois pas comment c'est possible d'accéléré un blit ,quant on utilise

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SDL_BlitSurface(pStarSprite, NULL, pScreen, &sdlDestRect)

il parcours les tableau pStarSprite pour le coller a pScreen , même niveau Hardware ce n'est pas possible sauf si dans une autre architecture le hardware peut modifier la mémoire ram.

Edit :
Quoique voila mon benchmark :
1024x768 :480fps
800x600 : 850fps
640x480 : 1430fps
320x240 : 6000fps
(fichier test.txt pour changer la résolution).

Voila bon mon ordi est tres recent , mais bon on voit que c'est optimal pour 320x240.
Mais je me souviens que 800x600 c’était limite sur mon ancien portable.

[LittleWhite]

Comme je l'ai mis dans mon commentaire, le SDL_FillRect qui efface l'écran est une des opérations les plus couteuses. En théorie, dans les jeux il est possible de ne pas l'utiliser (exemple, OpenAWars).

[Kannagi]

C'est pas en théorie c'est sur , rare sont les jeux qui possède pas un fond.
Pour cela que je l'ai pas mis dans mon test , vu que c'est quasi-jamais utilisé,juste fait un blit ( avec une surface que j'ai créer avec SDL_CreateSurface).