Discussion :

[lezebulon]

Bonjour,
Concernant un projet de jeux 2D avec plusieurs calques utilisant un tileset, je me pose une question d’optimisation.
Je vous explique l’organisation de mon code :
J’ai en mémoire en permanence environ 400 tiles (qui sont des SDL_surface de 32 x 32).
J’ai des « layers » qui grosso modo sont justes de tableaux à 2 dimensions contenant l’id de la tile à placer à telle case.
Ces layers (10 grand max) se superposent les uns sur les autres mais il y a d’autres éléments qui bougent entre ces calques (genre sprite qui s’anime)
J’ai une caméra correspond à la fenêtre de mon jeu (mettons 800 x 600) qui affiche donc juste une parti de tous les layers « fusionnés ». Le truc important est que ma caméra, d’une frame à l’autre, ne peut se déplacer que au max de 32 pixels.
Je vois 2 méthodes pour afficher la scène :
1) Pour chaque calque, je blitte les tiles qui seront à l’écran, aux bonnes positions. Ensuite je blitte les sucessivement les couches 2 à 2 (typiquement un truc genre calque / animation par-dessus / calque / etc), en effacant de la mémoire les calques une fois blités.
2) Une autre méthode qui utilise le fait que la caméra scrolle assez lentement serait la suivante :
Pour la 1ere image je garde la méthode 1, mais je n’efface pas de la mémoire les SDL_Surface correspondant à chaque calque. Pour calculer chaque nouveau calque à l’étape d’après, au lieu de recréer ce calque en blittant chaque tile dessus une par une, je m’appuie sur le calque précédent en mémoire et je décale juste la zone calculée (et je re-blitte les tiles manquantes). Une fois ces calques calculés, je les blitte entre eux comme précédemment mais je les garde en mémoire.

L’avantage de 1) est que je ne conserve pas mes 10 calques en mémoire, mais l’avantage du 2) est que chaque calque va très vite à être re-calculé (on ne calcule que les tiles qui sont apparus, pas ceux qui ont bougés), mais je dois constamment avoir 10 calques en mémoire.

Sauriez-vous me dire laquelle de ces méthodes est la meilleure niveaux perfs ?

[nouknouk]

Sauriez-vous me dire laquelle de ces méthodes est la meilleure niveaux perfs ?

Ben niveau perfs, celle qui garde les calques en mémoire, puisque la mémoire intervient pas vraiment dans les perfs ici

D'une façon plus générale, 10 calques en 800x600 en 32 bits (ARGB) ça fait grosso modo 20Mo de mémoire vive. A moins que ton jeu soit destiné à un équipement spécifique (smartphone, ...), 20Mo c'est rien du tout de nos jours: même il y a 5-10 ans, un ordi avait déjà 512Mo de RAM en standard.

Il n'y a donc aucun désavantage réel à utiliser la méthode des calques en mémoire.

[lezebulon]

Je code pour PC
En fait ça me parait assez violent d’utiliser 20 Mo de VRAM pour juste un bête scrolling 2D (c’est une impression), mais d’un autre côté avec cette méthode je ne vais blitter que une 60aine de tiles par calques, plus l’ancien calque à décaler, contre ~30*30 tiles à blitter si je repars d’un calque vierge.
D’ailleurs est-ce que blitter 60 petites tiles + une grosse image est beaucoup plus rapide que de blitter 900 tiles ? sachant que la surface totale est la même et que c’est juste une histoire de subdivisions.

edit : sinon quelqu'un sait si les anciens jeux type super nes, etc, utilisait l'une ou l'autre de ces méthodes?

[nouknouk]

En fait ça me parait assez violent d’utiliser 20 Mo de VRAM pour juste un bête scrolling 2D (c’est une impression)

Je n'ai pas d'expérience précise, mais moi j'avais l'impression que 20Mo c'est rien du tout au contraire.

D'où l'intérêt de ne pas trop essayer d'optimiser à priori. Amha, mieux vaut faire une version très basique et "à la bourrin" au départ, puis de procéder par itérations successives pour identifier un à un les 'points chauds' et y remédier.

Parce que sinon, tu as toutes les chances de perdre du temps à optimiser des choses qui ne te feront rien gagner, et inversement.

[fearyourself]

En principe, la deuxième solution est meilleure mais comme le dit le post précédent, ne t'embête pas avec cela pour l'instant. Fait ta première version et regarde.

Cela ne sert a rien de faire une version supra optimisée si tu es déjà a 300 images par secondes.

Jc

[hpfx]

Salut,
c'est marrant, je fait moi aussi un truc du même genre, (4 layers seulement)
j'ai pris la 1ere solution (pour faire simple et aussi parceque certains calques ne sont pas statiques : modification, tileset animé...)
mais j'ai remarqué un petit truc qui peut être interessant a savoir : derrier tout celà j'utilise un image en background, qui au depart était en jpeg (mes tilesets sont en png voir même bmp pour edition rapides/debug)...
et bien j'ai remarqué une difference de performance en fonction du format d'image utilisé pour la background. en png c'est plus rapide qu'en jpeg.
Sans doute le fait de blitter des des images indexées par dessus du jpeg ? j'sais pas.
bref, je passe tout en png du coup.

[SofEvans]

j'ai remarqué une difference de performance en fonction du format d'image utilisé pour la background. en png c'est plus rapide qu'en jpeg.
Sans doute le fait de blitter des des images indexées par dessus du jpeg ? j'sais pas.
bref, je passe tout en png du coup.

Ca ne devrait avoir aucun rapport.
Tu manipule des SDL_Surface*, ce qui fait abstraction des bmp, png, jpeg etc etc.
La ou ca peut influe, c'est au temps de chargement.
Tu dois mal t'y prendre.

Charge bien qu'une suel fois tes image ? Utilise tu SDL_Display[Alpha] ?

[Mat.M]

Salut,

et bien j'ai remarqué une difference de performance en fonction du format d'image utilisé pour la background. en png c'est plus rapide qu'en jpeg.

apparemment tu fais l'erreur de recharger chaque image jpeg pour rafraichir l'écran.
Manipuler des jpeg sera plus long pour la raison toute bête que ce sont des images compressées....
maintenant reste à voir comment SDL gère ce format d'image ; si pour appeler SDL_BlitSurface SDL fait des conversions parce qu'initialement c'est une jpeg alors pas étonnant qu'il y ait des pertes de performances...

[hpfx]

Salut,


apparemment tu fais l'erreur de recharger chaque image jpeg pour rafraichir l'écran.

non non, pas du tout,
je charge mes SDL_Surface* au debut, une seule fois.
j'avoue ne pas comprendre...

Utilise tu SDL_Display[Alpha] ?

Je n'utilise pas d'alpha en plus (car reputé plus lent) j'ai une couleur de transparence avec SetColorKey (le rose, comme beaucoup)

voici ma petite procedure de chargement d'image...
qui me sert a charger tous les objets images (jpg, png...)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
//Prototype ==>
SDL_Surface* load_image(const std::string & filename,const bool setcolorkey=true,const Uint8 rr=255,const Uint8 gg=0,const Uint8 bb=255 );
 
//Implementation ==>
SDL_Surface *load_image(const std::string & filename ,const bool setcolorkey,const Uint8 rr,const Uint8 gg,const Uint8 bb)
{
    //L'image qui est chargée
    SDL_Surface* loadedImage = NULL;
 
    //L'image optimisée qu'on va utiliser
    SDL_Surface* optimizedImage = NULL;
 
    //Chargement de l'image
    loadedImage = IMG_Load( filename.c_str() );
 
    //Si l'image a bien chargée
    if( loadedImage != NULL )
    {
		if(setcolorkey)
		{
			SDL_SetColorKey( loadedImage, SDL_RLEACCEL | SDL_SRCCOLORKEY, SDL_MapRGB( loadedImage->format, rr, gg, bb ) );
		}
        //Création de l'image optimisée
        optimizedImage = SDL_DisplayFormat( loadedImage ); // adapte à l'ecran
 
        //Libération de l'ancienne image
        SDL_FreeSurface( loadedImage );
 
    }
 
    //On retourne l'image optimisée
    return optimizedImage;
}