Discussion :

[Invité4]

Bonjour,

nous sommes en plein développement d'un RPG en 2D multijoueur sur internet avec SDL, le développement touche gentillement à sa fin (d'ici 2 mois).
Le jeu s'exécute en 800x600.

En gros, à chaque cycle (20 par seconde) on affiche - la texture de sol puis les objets statiques (maisons, arbres...) puis les objets dynamiques (feux, animations) puis les autres joueurs en mouvement puis les messages de jeu (messages du serveur, messages du chat entre joueurs, pseudonymes des joueurs) puis le joueur incarné. Ensuite on blitte.
Enfin, on vérifie les collisions potentielles avecd es objets solides ou avec des déclencheurs d'actions.

Nous venons de terminer la gestion du jour; selon l'heure serveur, le programme affiche un PNG translucide, préalablement chargé dans une surface, juste avant le blit de fin de cycle. Cela permet de donner un effet de semi-obscurité afin de simuler la nuit.

Le jeu est très fluide sur le PC de test, mais lorsque l'on simule la nuit avec la surface semi-transparente, les performances chutent effroyablement.
Pourtant le PC de test est rapide : Kubuntu Linux 6.06, Celeron 2.8Ghz, Carte Nvidia avec le driver officiel nvidia et 512Mo de RAM.

Bref, ma question : existe-t-il une méthode afin de contrer cette chute de performances ?

Merci

EDIT: Pourtant la carte vidéo est utilisée pour blitter grâce à

Code :

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

1
2
3
4
5
6
7
8
9
10
11
void initSDL(void)
{
   if(SDL_Init(SDL_INIT_VIDEO|SDL_INIT_AUDIO|SDL_INIT_TIMER)!=0) {
      std::cout << "Problème pour initialiser SDL: %s\n" << SDL_GetError() << std::endl;
   }
   char title[50] = "iceconquestworld - www.ice-conquest.org ";
   SDL_WM_SetCaption(strcat(title, version), NULL);
   screen = SDL_SetVideoMode(WIDTH,HEIGHT, 32, SDL_DOUBLEBUF | SDL_HWSURFACE);
        if(screen == NULL)
           done = 1;
}

[Laurent Gomila]

Tu utilises quoi pour la transparence ? Typiquement c'est le genre de chose qui ne sera pas accéléré par la hardware avec SDL, donc très lent.

[Invité4]

En fait j'utilise directement la transparence du PNG chargé avec IMG_Load()

Exemple:

Code :

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

1
2
3
SDL_Surface *little_night;
little_night = IMG_Load("data/interface/soir"); // pendant le chargement du jeu
SDL_BlitSurface(little_night, NULL, screen, NULL); // a chaque tour, blit avec screen

[Laurent Gomila]

Je ne suis pas un pro de SDL, mais... ce code gère réellement l'opacité de l'image sans rien faire de plus ? Je pensais même que SDL ne gérait pas ça en natif et qu'il fallait utiliser une bibliothèque tierce.

Enfin bref

[Fiquet]

Je ne suis pas un pro de SDL, mais... ce code gère réellement l'opacité de l'image sans rien faire de plus ? Je pensais même que SDL ne gérait pas ça en natif et qu'il fallait utiliser une bibliothèque tierce.

En fait ici il utilise SDL_image, qui ajoute automatiquement la couleur de transparence pour les PNG s'il y en a une. Par contre pour la transparence alpha je ne suis pas sûr .

Sinon pour le problème de la transparence alpha on ne peut pas faire grand chose, SDL ne gère rien en hardware donc ça reste lent... La valeur alpha 128 (semi-transparent) est toutefois optimisée si ça peut faire gagner quelque chose.

[loka]

peut être que ça pourra t'être utile :

La fonction

SDL_Surface *SDL_AllocSurface (Uint32 flags, int width, int height, int depth, Uint32 Rmask, Uint32 Gmask, Uint32 Bmask, Uint32 Amask);

crée une surface de format arbitraire en mémoire. Les paramètres " mask " permettent de spécifier le masque RGB pour le format de pixels de la surface. Par exemple, un mode 24 bits (depth = 24) pourra avoir Rmask = 0xFF0000, Gmask = 0x00FF00, Bmask = 0x0000FF. Les flags supportés sont les suivants :

* SDL_HWSURFACE : SDL_HWSURFACE : La surface sera allouée en mémoire vidéo (si possible). Chaque accès direct à la mémoire vidéo devra être entouré d'appels à SDL_LockSurface() et SDL_UnlockSurface() pour garantir un accès exclusif.
* SDL_SWSURFACE : la surface sera créée en mémoire principale
* SDL_SRCCOLORKEY : indique que la surface sera transparente, ce qui peut amener SDL à placer la surface en mémoire vidéo de manière à bénéficier d'accélérations matérielles.
* SDL_SRCALPHA : idem pour l'alpha blending

Les surfaces allouées par SDL_AllocSurface() doivent être libérées par SDL_FreeSurface(). Il est également possible de créer une surface à partir d'un fichier BMP (SDL_LoadBMP()), voire de sauver le contenu d'une surface dans un fichier BMP (SDL_SaveBMP())

ainsi que :

il est possible de transformer une surface ayant une couleur transparente en une surface ayant un indice de transparence, grâce à SDL_DisplayFormatAlpha qui convertit les pixels de la couleur transparente (color key) en pixels disposant d'une composante alpha, valant 0 (totalement transparents) pour les pixels qui étaient de la couleur transparente, et 255 (1, en composante alpha normalisée) pour les autres, qui gardent leur couleur. La valeur alpha intermédiaire 128 est souvent un cas particulier de transparence qui, appliqué sur toute une surface, fait l'objet d'optimisations la rendant spécialement rapide.

et pour finir :

l'encodage RLE (Run-Length Encoding), qui consiste à regrouper les pixels consécutifs de même couleur, peut significativement accélérer les transferts de mémoire (blittings) quand il s'applique à des sprites disposant de longues bandes horizontales de pixels transparents (i.e. de la même couleur que la color key).

[Invité4]

Ok Loka, je vais tenter tes fonctions.
Tu as trouvé cela dans la FAQ de Développez ou dans la doc SDL (histoire que je lise le document en entier) ?
J'espère que ça va résoudre mon problème, car le prochain truc à implémenter est la météo : pluie et neige, ça sera pire que la nuit question transparence
En fait ça sera 72 images qui seront blittées rapidement (je vous ai mis en pièce jointe deux des images de neige) mais je pense que ce sera pire niveau temps de calcul
Ok, donc je vais essayer les méthodes de Loka et je vous tiens au courant des résultats si 4a vous intéresse, sinon je mets en résolu.

merci à vous trois.

[Eusebe]

Moi, les résultats m'intéressent. Je vais sûrement passer par là un de ces jours.

Et une quetsion en passant : pour la texture des objets statiques, dynamiques et des joueurs, tu gérais bien aussi une transparence, non ? Et elle était rapide ?

La différence c'est uniquement que pour la nuit tu as une surface semi-transparente ?

[florent28]

Personnellement, j'utilise ceci :

Code :

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

SDL_SetColorKey( image, SDL_RLEACCEL | SDL_SRCCOLORKEY, colorkey );

Ca reprend les deux paramètres donnés plus haut.

Maintenant, est-ce que ça joue beaucoup quand on utilise la fonction sur une image déjà créée, je ne sais pas, faudrait faire plus de tests...

[Invité4]

Moi, les résultats m'intéressent. Je vais sûrement passer par là un de ces jours.

Et une question en passant : pour la texture des objets statiques, dynamiques et des joueurs, tu gérais bien aussi une transparence, non ? Et elle était rapide ?

La différence c'est uniquement que pour la nuit tu as une surface semi-transparente ?

En fait, au chargement de la zone, je blitte tous les objets statiques ensemble avec la texture de fond que je réutilise, comme ça : ça évite pleins de calculs à chaque cycle.
Autrement pour les textes, je fais une fois le rendu avec sdl_ttf et je mets aussi dans une surface tous les textes ensemble.
Pour les dynamiques et les joueurs, là c'est la même chose que pour la nuit. Mais ce sont de plus petits objets donc le rendu est rapide. Pour la nuit, c'est une texture totalement translucide et qui prend tout l'écran.

Donc je vous donnerai les résultats, faut juste que j'attende 20h pour que le serveur indique au jeu que c'est la nuit

florent28: je vais essayer aussi.

merci

[loka]

Ok Loka, je vais tenter tes fonctions.
Tu as trouvé cela dans la FAQ de Développez ou dans la doc SDL (histoire que je lise le document en entier) ?

Ce sont des morceaux que j'ai copier/coller il y a longtemp pour mes tutos et autres.

J'avais trouver ça dans la doc il me semble, mais comme ce sont copier/coller de plusieurs trucs (doc, sites parlant de sdl, forum...) en plus de mon apport perso, j'ai pas vraiment 1 source à te passer là :p

[Invité4]

ok, je vais me débouiller avec ceci, sinon la doc officielle

[mat.M]

Le jeu est très fluide sur le PC de test, mais lorsque l'on simule la nuit avec la surface semi-transparente, les performances chutent effroyablement.
Pourtant le PC de test est rapide : Kubuntu Linux 6.06, Celeron 2.8Ghz, Carte Nvidia avec le driver officiel nvidia et 512Mo de RAM.

Bref, ma question : existe-t-il une méthode afin de contrer cette chute de performances ?

Oui tu mets SDL à la poubelle
SDL c'est trop lent j'ai vite fait d'abandonner tu ne peux rien controler à moins d'aller trifouiller dans les sources.
Faut programmer avec Direct Draw PUR et DUR pas SDL ;

BlitSurface(little_night, NULL, screen, NULL); // a chaque tour, blit avec screen

Peut-être en copiant un buffer vers un autre avec un memcpy cela sera + raide plutot que des opérations de "blitting"
Si tu peux essayer d'optimiser en ASM....

[Invité4]

Oui tu mets SDL à la poubelle
SDL c'est trop lent j'ai vite fait d'abandonner tu ne peux rien controler à moins d'aller trifouiller dans les sources.
Faut programmer avec Direct Draw PUR et DUR pas SDL ;



Peut-être en copiant un buffer vers un autre avec un memcpy cela sera + raide plutot que des opérations de "blitting"
Si tu peux essayer d'optimiser en ASM....

Hello, je pense que les méthodes d'utilisations de la carte graphique (loka et florent28) ci-dessus vont m'aider.

Pourquoi j'utilise SDL et non pas DirectDraw ? Car l'exécutable compile sous Linux, sous Windows et sous OS X Donc ça nous fera plus de clients.

Pour l'ASM, je ne connais pas l'assembleur, donc je laisse tomber. Je préfère ne pas mélanger.

[Laurent Gomila]

Peut-être en copiant un buffer vers un autre avec un memcpy cela sera + raide plutot que des opérations de "blitting"
Si tu peux essayer d'optimiser en ASM....

Pour accélérer l'affichage il faut utiliser l'accélération matérielle, pas l'ASM.

Faut programmer avec Direct Draw PUR et DUR pas SDL

Non plus

Pour avoir des effets graphiques du genre alpha-blending, transformations, ... en 2D, il faut taper dans les API 3D, rien de magique.

[mat.M]

Pour avoir des effets graphiques du genre alpha-blending, transformations, ... en 2D, il faut taper dans les API 3D, rien de magique.

que ne supporte pas.....SDL

.

Pourquoi j'utilise SDL et non pas DirectDraw ? Car l'exécutable compile sous Linux, sous Windows et sous OS X Donc ça nous fera plus de clients.

Ouais c'est sur que si on veut porter la chose sous Linux...

[Invité4]

que ne supporte pas.....SDL


Ouais c'est sur que si on veut porter la chose sous Linux...

SDL supporte quand même le Blitting accéléré par la carte, la seule chose dont j'ai besoin, donc c'est nickel

[mat.M]

SDL supporte quand même le Blitting accéléré par la carte, la seule chose dont j'ai besoin, donc c'est nickel

(Damned plus rapide que moi )

SDL s'appuie exclusivement sur des surfaces DirectDraw à ma connaissance ( cf code source de SDL ).
Avec DirectDraw/Direct X ce sera la même chose; et évidemment avec Direct Graphics comme le laisse entendre Loulou24.
Mais c'est certain tout cela n'est pas portable sous Linux; regarder le code source de SDL il y a maints directives de précompilation

Sinon j'ai voulu jeter un coup d'oeil sur le projet mais le site WWW de ton profil ne fonctionne pas

[Laurent Gomila]

SDL + OpenGL c'est bien aussi, pour faire du portable rapide.

[Invité4]

rojet mais le site WWW de ton profil ne fonctionne pas

http://www.ice-conquest.org/ fonctionne ce sera le site du jeu, mais l'exécutable n'est pas encore à disposition.

Le jeu en PHP actuel, (.com) fonctionne, mais là il met de jolies 404 car l'hébergeur nous a coupé pour quelques longues heures (surconsommation de ressources du mutualisé), heureusement que le jeu en développement est sur un dédié.

Si on aurait pas voulu faire portable, c'est sûr qu'on aurait opté directement pour Direct X, mais développant sous un poste Linux on s'est dit : Portabilité ! SDL !