probleme de jeu qui ram a cause de blit surface

Version imprimable

19/10/2017, 01h18
JonathanTC

probleme de jeu qui ram a cause de blit surface
salut tout le monde

j'ai mon jeu de plateforme qui est grave lent qui ram, je pense que c'est a cause du blit des différents plan du niveau j'explique comment je procede.
Code:

1 2 3 4 5 6 7 while(){ blit arriere plan sur l'ecran blit second plan dur ecran blit premier plan sur ecran blit gui sur ecran flip ecran }
je me demandai si il y avais pas un autre moyen de faire deplacer mes surface. car avec ma methode je créer mes surface avant la boucle principal et je blit a chaque tour de boucle pour changer la position.
peut etre que sdl_surface prend un parametre special comme par exemple sdl_surface *premier plan; premier_plan.x = 10; etc.

petite precision , je charge des png donc transparent de base. je remplis une surface avec mon image grace a la fonction sdl_creatergbsurface() pui pour rendre cette surface transparente jutilise SDL_SetColorKey mais je me suis rendu compte que setcolorkey me fait ralentir le programme. ya t-il un autre moyen de gerer cette transparence sans cette fonction ?
19/10/2017, 10h38
Bousk

Salut,

4 blits ne devraient pas faire ramer un jeu.
Sauf si tu blit des trucs anormalement gros et qui sont hors écran ? Dans ce cas ça manque d'optimisation.
Assure-toi aussi de créer tes surfaces dans la mémoire vidéo (qqch comme HWSURFACE de mémoire) et non les traiter en software.

La résolution et les blit assez gros font ralentir la programme en général.

Citation:

petite precision , je charge des png donc transparent de base. je remplis une surface avec mon image grace a la fonction sdl_creatergbsurface() pui pour rendre cette surface transparente jutilise SDL_SetColorKey mais je me suis rendu compte que setcolorkey me fait ralentir le programme. ya t-il un autre moyen de gerer cette transparence sans cette fonction ?

Bizarre j'aurais dit le contraire , en faite le souci c'est les PNG transparent ça rame pas mal , je te conseille d'avoir une image non transparente et ensuite d'utiliser SDL_SetColorKey , avec un mask j'ai remarqué que sur la SDL les blits sont encore plus rapide.
Code:

1 2 3 4 5 6 void SDL_Mask(SDL_Surface *surface,int r,int g,int b) { Uint32 colorkey; colorkey = SDL_MapRGB( surface->format,r,g,b); SDL_SetColorKey( surface, SDL_RLEACCEL | SDL_SRCCOLORKEY, colorkey ); }

19/10/2017, 14h28
JonathanTC

rien a faire ça marche pas !

rien a faire j'ai tout essayer même avec mes image avec fond noir style jpeg et ta fonction c'est toujours pareil.
La transparence avec sdl c'est pas top ! Je pense que cette bibliothèque à fait son temps.

je ne comprend pas pourquoi il rame je sais que mon premier plan celui ou il y a toute les briques de mon niveau me bouffe trop de ressources déjà.
je pense m'orienté sur la SDL2 peut être qu'ils ont apporter des améliorations de ce coter la.

Qu'est ce que tu dis de ça ?

De plus si je m'oriente sur la version 2 je pense m'orienté sur du c++.
19/10/2017, 14h57
Kannagi

Sans code source (voir le projet) je ne peux pas te dire ou ça coince exactement.

Pour ma part j'utilise toujours la SDL 1.2 , ce qui est étonnant c'est que je ne vois pas pourquoi ça rame (je lai utiliser sur un eeepc et ça marche très bien :) ) , j'ai deja fait des jeux sur la SDL sur des consoles avec 300MHZ (PSP , Dreamcast) , donc je reste étonné que cela rame sur un PC Moderne.

Sinon oui en général on conseille d'utiliser la SFML ou la SDL2 , si tu fait de la SDL 1.2 donc en software , faudra bien comprendre comment fonctionne les fonctions SDL derrière pour optimiser au maximum le rendu ;)

Par exemple un de mes jeux sur SDL : https://www.youtube.com/watch?v=0pa64Zr8358
Sur mon PC ça utilise 5% du CPU et 17Mo de ram :p , et pourtant c'est pas le jeu le plus optimisé que j'ai pu faire !
19/10/2017, 21h17
JonathanTC

ouai je vais me diriger vers la SDL2

pas mal ton jeu ! si tu veu j'ai une place pour toi dans ma team mdr
21/10/2017, 10h47
LittleWhite

Bonjour,

Le problème de la SDL 1.2 est que tous les blits sont réalisés en software sur PC (mais pas sur GP2X, et je ne pense pas que ce soit le cas pour Dreamcast, PSP et autre console). Du coup, il est compliqué de vraiment avoir une bonne comparaison. On peut vérifier le support du blit hardware avec une fonction de la SDL.
Ensuite, cela dépend vraiment de la résolution que vous utilisez. Il est vrai qu'utiliser des PNG tranparents est déjà un point où les performances vont fondre (il suffit de voir l'algorithme de SDL_BlitSurface qui est expliqué dans la doc). Plus rapide, ce sont les images avec une couleur (généralement rose) déterminée comme transparente (avec le ColorKey). De plus, SDL_Image peut ne pas faire ce qu'il faut lors de la création de la surface à partir de l'image PNG. Du coup, un autre gain (idiot, mais c'est ainsi) est de passer par du BMP (mais ça craint à mort pour l'espace disque).
Aussi, il faut toujours comparer avec les résolutions -> http://alexandre-laurent.developpez....ces-de-la-SDL/
On voit que des qu'il y a trop de pixel coverage (couverture de pixels), ça commence à fondre (normal, surtout software). Pour remédier à cela, il faut mettre en place un mécanisme de dirty rect (comme dans pygame, qui repose sur SDL 1.2). Ce mécanisme permet de définir les zones à redessiner sans redessiner l'intégralité de l'écran. C'est bien mieux, afin de ne pas dessiner 100% du background (qui prendre la taille de la fenêtre) et donc de réduire le nombre de pixels à dessiner par frame.

Pour finir, la SDL 2 effectue ses rendus en OpenGL, donc en utilisant le GPU, donc avec l'accélération matérielle, donc, c'est bien plus rapide. Pour moi (avis personnel et qui ne tient qu'à moi (coucou Kannagi)), rester en SDL 1.2 de nos jours est une ineptie, sauf pour les cas spécifiques tels que le support de la Dreamcast :D.

(Note : la SDL 2 ne force pas l'utilisation du C++, vous pouvez continuer en C, si vous le souhaitez.)
21/10/2017, 20h00
JonathanTC

merci littlewhite pour ta réponse qui confirme ce que je pense.

Merci Littlewhite pour ta réponse. effectivement c++ n'est pas obligatoire mais c'est un choix personnel pour avancer dans mon apprentissage puis je trouve que manipuler des objets en programmation est plus plaisant pour moi. Pour cette technique dont tu m'a parler j'y ai pensé mais je voulais pas trop me casser la tête du coup j'ai tout de même migrer sur la SDL2 de toute façon j'aurai du un jour partir vers d'autres horizons.
22/10/2017, 19h58
Kannagi

Citation:

Envoyé par LittleWhite

Bonjour,

Le problème de la SDL 1.2 est que tous les blits sont réalisés en software sur PC (mais pas sur GP2X, et je ne pense pas que ce soit le cas pour Dreamcast, PSP et autre console). Du coup, il est compliqué de vraiment avoir une bonne comparaison.

Je te confirme que elle sont bien software ;)
(de toute façon sur PSP la VRAM est trop petite).

Citation:

Envoyé par LittleWhite

Pour finir, la SDL 2 effectue ses rendus en OpenGL, donc en utilisant le GPU, donc avec l'accélération matérielle, donc, c'est bien plus rapide. Pour moi (avis personnel et qui ne tient qu'à moi (coucou Kannagi)), rester en SDL 1.2 de nos jours est une ineptie, sauf pour les cas spécifiques tels que le support de la Dreamcast :D.

Inversement , si on code en C on est dans le logique de l'optimisation , donc un jeux en Softxware ne pose normalement aucun souci (d'ailleurs je peux prendre l'exemple de l'Atari ST) et je ne pense pas qu un amateur fera un jeu de 'folie' avec une tel lib qui demanderai une puissance et des optimisations en plus.
Je reste toujours dans l'optique que inutile de sortir le bazooka pour tuer une mouche , et cela permet pas de former la personne , après effectivement d’où dépens de la logique du PO , soit la finalité de faire un jeux donc je trouve que le C et la SDL 1.2 est un mauvais choix sauf pour un programmeur averti , soit ben la technique et l'optimisation est son but principal et la SDL 1.2 est un des meilleurs choix a mes yeux ;)