Chargement des images coûteux en mémoire avec sdl2

Fermé
Landry_Boy Messages postés 7 Date d'inscription samedi 8 août 2020 Statut Membre Dernière intervention 13 juin 2022 - 1 juin 2022 à 19:58
[Dal] Messages postés 6198 Date d'inscription mercredi 15 septembre 2004 Statut Contributeur Dernière intervention 13 décembre 2024 - 3 juin 2022 à 10:56
Bonjour,
Svp j'aimerais savoir s'il existe un moyen pour charger un Total de 54 images en sdl2 en c sans affecter les ressources, je développe actuellement un jeu de solitaire et je dois créer touts les cartes

J'attends vos réponses svp c'est très important





Configuration: Android / Chrome 101.0.4951.61

2 réponses

mamiemando Messages postés 33446 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 20 décembre 2024 7 812
2 juin 2022 à 15:26
Bonjour,

Tu peux t'inspirer de cet exemple.

Bonne chance
0
[Dal] Messages postés 6198 Date d'inscription mercredi 15 septembre 2004 Statut Contributeur Dernière intervention 13 décembre 2024 1 096
2 juin 2022 à 15:40
Bonjour Landry_Boy

54 cartes à jouer, ce n'est pas la mer à boire et les complexités ou inconvénients que tu introduirais en optimisant prématurément ne se justifient peut-être pas.

As-tu mesuré l'empreinte mémoire des 54 cartes ?

Une façon différente de faire serait de ne pas charger les 54 cartes, mais de charger seulement celles qui sont nécessaires à l'affichage courant (les cartes visibles) et le libérer la mémoire lorsqu'elles n'ont plus à être affichée. L'inconvénient est que tu consommes des ressources de calcul et de lecture sur la mémoire de masse (le disque) à chaque affichage d'une nouvelle carte.

D'autres pistes consistent à faire un rendu des cartes en composant la carte avec les éléments qui la composent à la volée : tu dessines un rectangle blanc et tu ajoutes les éléments (chiffres, symboles, figures), pour les figures, dois même pourvoir, si tu les fais d'une couleur unie, utiliser des fonctions SDL2 pour modifier la couleur (voir du côté de SDL_SetTextureColorMod() je pense).

Encore une fois, tu ne devrais te lancer là dedans que si c'est vraiment nécessaire.

Dans ta conception, tu devrais clairement séparer l'implémentation de la logique du jeu par rapport à l'affichage, et autant que possible, la gestion de l''affichage par rapport à la gestion de l'obtention d'un pointeur sur une surface ou d'une texture représentant une carte donnée.

Si tu dois changer la façon dont les cartes sont générées ou chargées, tu le feras dans le module C dédié.

Dal
0
mariam-j Messages postés 1391 Date d'inscription mercredi 9 mars 2022 Statut Membre Dernière intervention 20 décembre 2024 15
3 juin 2022 à 10:26
Il faudrait déjà savoir dans quel format sont les images
Le: ".bmp" est 140 fois plus lourd que le: ".jpg"
0
[Dal] Messages postés 6198 Date d'inscription mercredi 15 septembre 2004 Statut Contributeur Dernière intervention 13 décembre 2024 1 096 > mariam-j Messages postés 1391 Date d'inscription mercredi 9 mars 2022 Statut Membre Dernière intervention 20 décembre 2024
Modifié le 3 juin 2022 à 10:57
@mariam-j:

Le format de l'image que tu indiques n'aura un impact que sur la taille du stockage sur le disque.

Une fois chargée en mémoire sous la forme d'une surface ou d'une texture, elle est stockée sous une forme décompressée en mémoire vive de l'ordinateur pour les surfaces ou du GPU pour les textures (qui détermine comment il les stocke).

Ce peut avoir un impact c'est le type d'image. Les images RGB nécessiteront 3 bytes par pixels, celles RGBA auront besoin de 4, celles avec des couleurs indexées un seul byte (avec une palette pour chaque index de 0 à 255). Cette dernière forme sera la plus économe, et était bien gérée par la SDL 1.2. Avec la SDL2, elle me semble largement dépréciée d'après ce que je comprends, car le matériel (les GPU, c'est à dire les cartes graphiques qui fournissent l'accélération matérielle) ne supporteraient aujourd'hui que des images avec des couleurs "true color".
0