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 6193 Date d'inscription mercredi 15 septembre 2004 Statut Contributeur Dernière intervention 4 juillet 2024 - 3 juin 2022 à 10:56
[Dal] Messages postés 6193 Date d'inscription mercredi 15 septembre 2004 Statut Contributeur Dernière intervention 4 juillet 2024 - 3 juin 2022 à 10:56
A voir également:
- Chargement des images coûteux en mémoire avec sdl2
- Des images - Guide
- Mémoire vive - Guide
- Mémoire virtuelle - Guide
- Test memoire pc - Guide
- Tv lg liberer memoire ✓ - Forum TNT / Satellite / Réception
2 réponses
mamiemando
Messages postés
33295
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
1 octobre 2024
7 788
2 juin 2022 à 15:26
2 juin 2022 à 15:26
Bonjour,
Tu peux t'inspirer de cet exemple.
Bonne chance
Tu peux t'inspirer de cet exemple.
Bonne chance
[Dal]
Messages postés
6193
Date d'inscription
mercredi 15 septembre 2004
Statut
Contributeur
Dernière intervention
4 juillet 2024
1 090
2 juin 2022 à 15:40
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
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
mariam-j
Messages postés
1304
Date d'inscription
mercredi 9 mars 2022
Statut
Membre
Dernière intervention
1 octobre 2024
8
3 juin 2022 à 10:26
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"
Le: ".bmp" est 140 fois plus lourd que le: ".jpg"
[Dal]
Messages postés
6193
Date d'inscription
mercredi 15 septembre 2004
Statut
Contributeur
Dernière intervention
4 juillet 2024
1 090
>
mariam-j
Messages postés
1304
Date d'inscription
mercredi 9 mars 2022
Statut
Membre
Dernière intervention
1 octobre 2024
Modifié le 3 juin 2022 à 10:57
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".
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".
