Discussion :

[black is beautiful]

Bonjour à tous,

Je réalise un projet en SDL, c'est un petit jeu en 2D avec des tanks. Au départ j'utilisais une boucle infinie qui réaffichais sans arrêt les tanks, les faisais bouger et gérer les collisions. Pour plus de performances j'ai commencé a utilisé le multi-threading, pour séparer toutes ces tâches.

Mais rien n'y fait, il suffit d'ajouter un peu trop de tank (par exemple une dizaine) et l'ordinateur se mets à ramer. Pourtant je fais tourner crysis tranquille...

Quelle est la solution ? Est-ce que je n'utilise pas les bonnes techniques ?

Peut-on demander une priorité plus importante à notre jeu au niveau du processeur ?

Merci d'avance

[pierreyoda]

Bonjour.
Si je me trompe, qu'on me corrige, mais je crois qu'il faut accélérer avec OpenGl (il y a plein de tutos pour cela), car la SDL utilise un rendu 'software' (logiciel) et non 'hardware' (matériel), contrairement à la SFML par exemple, ce qui fait que quelle que soit la carte graphique utilisée le résultat sera identique.
C'est pour cela que, lorsque on fait un projet légèrement évolué, SDL rame mort.
Maintenant, il existe peut-être des solutions pour améliorer les performances autrement, mais je ne les connais pas (j'utilise SFML).

[Mat.M]

Bonjour.
Si je me trompe, qu'on me corrige, mais je crois qu'il faut accélérer avec OpenGl (il y a plein de tutos pour cela), car la SDL utilise un rendu 'software' (logiciel) et non 'hardware' (matériel), contrairement à la SFML par exemple, .

Oui mais il me semble qu'on peut spécifier un rendu matérielle je crois en appelant SDL_InitVideo()
De toute façon je n'aime pas SDL c'est trop lent..
SDL c'est bien pour débuter mais pour faire un bon jeu c'est un peu lourd

[Mat.M]

Bonjour à tous,

Je réalise un projet en SDL, c'est un petit jeu en 2D avec des tanks. Au départ j'utilisais une boucle infinie qui réaffichais sans arrêt les tanks, les faisais bouger et gérer les collisions. Pour plus de performances j'ai commencé a utilisé le multi-threading, pour séparer toutes ces tâches.

Mais rien n'y fait, il suffit d'ajouter un peu trop de tank (par exemple une dizaine) et l'ordinateur se mets à ramer. Pourtant je fais tourner crysis tranquille...

Quelle est la solution ? Est-ce que je n'utilise pas les bonnes techniques ?

Peut-on demander une priorité plus importante à notre jeu au niveau du processeur ?

Merci d'avance

RE je n'aime pas SDL je préfère directement programmer avec Direct X.
Maintenant il se peut qu'il y ait des 'bottlenecks" , des goulots d'étranglements dans ton code..
Par exemple comme j'ai vu dans un code hier si dans ta boucle tu fais SDL_Load cela risque de nuire aux performances.
Si tu veux des meilleures performances il faut programmer directement avec Open GL ou Direct X.

Pour plus de performances j'ai commencé a utilisé le multi-threading, pour séparer toutes ces tâches.

C'est qu'il ya un blocage au niveau de la vidéo alors ; coté CPU les opérations se font rapidement c'est coté rendu vidéo qu'il ya des ralentissements

[hpfx]

Avec tout ces messages si negatif envers SDL, je me dois de repondre

SDL c'est bien pour débuter mais pour faire un bon jeu c'est un peu lourd

il existe quand même quelques jeux "assez gros" et "assez bon" qui tournent bien en SDL : openttd, secret maryo chronicle...

ensuite il est vrai qu'on ne peux pas programmer comme un bourin et esperer que le hardware compence les lacunes des developpeurs ou defaut de conceptions.

perso, j'utilise SDL en 2D, sans openGL, je suis hyper scrupuleux je chasse le moindre octet, la moindre operation, je benchmark mes bouts de codes, ca fait plus de 2 ans que je suis dessus, a chaque nouvelle feature, j'analyse l'impact sur un cycle de jeu (temps entre deux affichage) et je suis tres vigilent, il y a des tests que je n'effectue qu'une fois sur 2 ou même une fois sur 4.

D'ailleur pour tester une fois sur deux je n'utilise pas le classique : if(++cpt%2) {/*faire un truc*/ } car celà implique un reste de division par deux (donc une division) je préfere tester avec if(var^=1) { /* faire un truc */ }
voilà vous allez trouver celà ridicule comme gain, mais tout compte.
autre exemple, je n'utilise pas de fonction telle que sinus... j'ai plutot un tableau de valeurs approchant un sinus.

Quelle est la solution ? Est-ce que je n'utilise pas les bonnes techniques ?

J'ai du reprendre des morceaux entier de mon code a cause de probleme de conception qui faisait que ce n'était pas optimum, pour liberer les ressources au plus tôt par exemple. j'y ai passé pas mal de temps c'est le prix a payer (si j'était meilleur j'aurai moins tatonné).

bon courage a toi, c'est tres formateur.

D'une maniere generale, si ca peu t'aider, j'ai remarquer que ce qui prends le plus de temps c'est l'affichage. a partir du moment ou tu applique un sprite, ca ne coupe pas plus cher de le faire se deplacer (sauf si tes algo de deplacement sont trop lourds bien sur... a toi de les optimiser!). conclusion, si tu place 100 sprites fixes ou 100 sprites qui se deplacent c'est pareil en terme de perf.
et si tu anime ces 100 sprites (tu alternes les images, par exemple 4 images par sprites) et bien ca ne change rien (sauf qu'il faut 4 x plus de memoires pour travailler). voici une petite astuce pour rendre un jeu plus sympas pour un cout en perf quasi nul.

une autre astuce toute bête, passe en 800x600 dans l'init de la video sous SDL, la surface a remplir étant plus petite, tu aura un vrai gain de perf !

ha! Et puisque j'en parle dans un autre thread... une autre astuce, si tu est en mode directx, n'utilise surtout pas de canal alpha avec SDL (alphablending).
Et même en windib, je deconseille l'alpha sauf pour la valeur 127.

d'ailleur :

Oui mais il me semble qu'on peut spécifier un rendu matérielle je crois en appelant SDL_InitVideo()

oui : voir là.

Voilà.

PS : je ne parle pas de faire un jeu tel que crysis bien sur. mais en dehors de la 3D, SDL peut faire mieux que des petits jeux ridicules. Ensuite je ne suis pas un dev 3D, donc je ne parle pas de cet aspect là.

[Djakisback]

Si tu rames avec seulement 10 tanks il y a des chances que le problème soit dans ton code. Tu peux essayer de cibler les parties qui prennent le plus de ressources. Le plus simple sans profiler étant a priori d'afficher les cycles par seconde, et de commenter/décommenter les parties lourdes (blittage, collisions).

[black is beautiful]

Ok, j'ai tout pris en compte. Premièrement je pense que mon code peut-être une cause puisque je ne me suis pas retenu sur l'utilisation des fonctions trigos et les collisions sont très lourdes.

Puis pour ce qui est de l'utilisation de DirectX, j'aimerai le lancer mais comment faire un jeu sans canal alpha ? C'est bien le SDLSetColorKey ?

Parce-que sans ça le jeu devient très moche et même injouable, est-ce qu'il y a une alternative au canal alpha ?

Ensuite peut-on gérer les priorités des threads, car certaines méthodes, si je les lancent dans des threads, le jeu rament plus que si je les laissent dans le thread principal.

[black is beautiful]

En fait, je viens de me renseigner sur la librairie SFML, c'est vrai qu'elle a l'air bien, surtout que je programme en C++ donc c'est plus adapté.

Mais mon projet est pour dans deux semaines, je pense pouvoir me lancer là dedans, est-ce que ça vaut vraiment le coup pour ce qui est des performances ?

[Djakisback]

Personnellement je te conseille d'oublier DirectX pour l'instant et de te concentrer sur l'amélioration des parties bloquantes de ton code.
Idem pour le multithreading sauf si tu en as vraiment besoin et que tu sais ce que tu fais.
"l'utilisation des fonctions trigos et les collisions sont très lourdes" à mon avis y a pas à chercher plus loin.

[black is beautiful]

Le problème des threads, c'est que certaines fois c'en est un qui prends la main et d'autres fois c'est un autre. Donc ça varie entre ralentissement des mouvements et ralentissement de l'affichage donc mouvement saccadé...

Quelle est la solution alors, l'amélioration du code pourra régler ce problème ?

[Matthieu Brucher]

Il est aussi probable que tu mettes à jour plus que ce tu as vraiment besoin, non ?

[black is beautiful]

Oui effectivement, puisque j'atteins 100 en valeur de FPS.
Comment puis-je ralentir ce thread pour donner plus souvent la main aux autres threads ?

Une simple boucle avec un compteur suffit ?

[Matthieu Brucher]

Non, je te parle de ne rafraîchir que ce qui a été changé.

[hpfx]

Puis pour ce qui est de l'utilisation de DirectX, j'aimerai le lancer mais comment faire un jeu sans canal alpha ? C'est bien le SDLSetColorKey ?

ha non, ca n'a rien a voir, j'en parle dans le poste dont j'ai mis le lien.
le canal alpha est une valeur de transparence par pixel sur 8 bit (256 val) c'est le fameux A du RGBA (c'est donc le 4eme canal, a coté du rouge, vert et bleu)
on peut dire que tel pixel est transparent a 50% par exemple en mettant la val 127, on peut donc regler 256 val de transparence.

Alors que le colorkey, c'est une couleur qu'on definie comme transparante a 100%. on prends une couleur de la palette qui sera completement transparente. On utilise souvent le magenta pris comme color key.

Voilà, donc pas question d'arreter les colorkey, je te rassure

Sinon, au passage, SFML est pas mal et a du success en ce moment. Elle evolue rapidement (un poil trop a mon gout, j'attends que ca soit "feature complete and stable".. et un peu plus multiplateforme, en particulier j'attends un port sur la wii comme la sdl)

Oui effectivement, puisque j'atteins 100 en valeur de FPS.
Comment puis-je ralentir ce thread pour donner plus souvent la main aux autres threads ?

un exemple (code pas genial, mais c'est un bon debut):

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
tempsActuel = SDL_GetTicks();
if (tempsActuel - tempsPrecedent > 20)
{ 
  // dessiner
  // ici!
  tempsPrecedent = tempsActuel;
}
else
{
  SDL_Delay(20 - (tempsActuel - tempsPrecedent));
}

la val 20 pour 20 milisecondes, soit 1000/20 = 50 FPS.
ce code donne au max un 50 FPS.

Une simple boucle avec un compteur suffit ?

ya du boulot ! (ou alors j'ai pas compris ce que tu veux dire, tu m'excusera dans ce cas)
Bon, déjà, on ne "ralentit" pas un process pour aider les autre, mais on lui demande de rendre la main (sleep, delay, etc...).
En effet, ca ne sert a rien de bouffer du CPU a faire une boucle (qui sera optimisé par le compilo au passage d'ailleurs), car ce n'est pas du temps CPU que tu rendra aux autres thread, puisque tu le bouffe justement...

Bon, pour le coups du SDL_Delay, c'est dans les tres bon tuto de ce même site, commence par là.

[hpfx]

Personnellement je te conseille d'oublier ...
(Idem pour) le multithreading

Completement d'accord.
je suis sûr qu'une bonne gestion du temps dans ta boucle te donnera de meilleur resultat d'une implementation multithread dison.. moyenne.
Deplus, c'est franchement pas facile le multithreading.

pour ce qui est du directx, il n'est pas dit que ca acellere quoi que se soit (si le point faible se situ en dehors de l'affichage).
mais ca ne coute pas grand chose de tester, il s'agit une simple ligne a ajouter au debut de ton programe.

a mon avis t'as du boulot d'optimisation a réaliser...
Un exemple bête, est-ce que tu a verifié que tu ne blit que ce qui est dans l'ecran ? (je ne sais pas comment réagit la SDL sur des blit hors affichage, elle est peut être assez intelligente pour ne pas pedre de temps a le faire, j'en sais rien, j'ai pas testé : je ne blit que des sprites qui sont à l'ecran)

[Mat.M]

Oui effectivement, puisque j'atteins 100 en valeur de FPS.
Comment puis-je ralentir ce thread pour donner plus souvent la main aux autres threads ?

Une simple boucle avec un compteur suffit ?

Dans toute cette histoire tu ne dis pas à quoi te sert cette programmation multithreading.
Est-ce que tu as jetté un coup d'oeil dans les sources de SDL ?
En interne il y a déjà un système de threads...
je ne vois pas trop l'intérêt d'utiliser des threads tout le monde veut utiliser cela a toutes les sauces, sauf si tu veux exploiter des connections réseaux.
Un bon timer et un bon ordonnancement des taches.
Faut pas perdre de vue que lancer des threads risquent de ralentir le jeu plus qu'autre chose car redite encore une fois le CPU et l'OS doivent faire l'ordonnancement des taches en quantum CPU
Si tu ne maitrises pas la programmation multithread je ne recommande pas d'y avoir recours surtout que cela semble provoquer des ralentissements.

[black is beautiful]

Ok alors premièrement DirectX ne m'améliore rien et même au contraire j'ai l'impression que c'est plus lent .
Pour ce qui est du multi-threading, j'en ai besoin dans le sens où c'est un projet sur les IA et j'utilise des réseaux neuronaux qui font des calculs de décisions sans arrêt. Je préfère donc le séparer.

Pour la trigo, je viens de tout remplacer par des tableaux, et en fait je me suis rendu que je n'en utilisais pas tellement, mais en tout cas il y a déjà une amélioration.

Matthieu Brucher, pour ce qui est du rafraîchissement, c'est vrai que je rafraîchi tout l'écran à chaque fois. Je vais donc mettre un système pour ne rafraîchir que ce que les tanks en enregistrant le terrain environnant.

Je vais aussi implémenter le système de Delay pour la vitesse de rafrachissement.

Merci pour toute cette aide en tout cas

[black is beautiful]

Mat.M je n'avais pas vu ta réponse

En fait j'utilise le multi-threading seulement pour séparer l'affichage de tout le reste. Et je vais me tourner vers les performances.

encore merci

[Matthieu Brucher]

Matthieu Brucher, pour ce qui est du rafraîchissement, c'est vrai que je rafraîchi tout l'écran à chaque fois. Je vais donc mettre un système pour ne rafraîchir que ce que les tanks en enregistrant le terrain environnant.

Intéressant comme projet. C'est un exercice de cours ?

[Mat.M]

Ok alors premièrement DirectX ne m'améliore rien et même au contraire j'ai l'impression que c'est plus lent

Direct X c'est vague...tu veux dire via SDL ??
Je te conseille d'utiliser plutot SFML si tu veux pas te casser la tête voire Irrlicht3d.
J'ai vu qu'on pouvait faire de la 2d avec Irrlicht il y a un exemple pour cela