Choix d'une lib graphique pour coder en C - Page 5

Mais si il stocke les png dans le fichier c'est double utilisation mémoire, et il lui faudra libpng non ?

Oui mais comme je dis, il les a bien convertis en SDL_SURFACE la première fois, donc il sait faire.
C'est lui qui veut que tout soit dans son exe, mais si c'était moi, je passerais sans doute par une archive externe aussi

Donc ok, un fichier extern (je suis bien d'accord avec ça).
Un tableau de char : faut que j'écrive le programme qui le fasse ?
Comment ensuite aller récupérer mes tableaux de chars ? fopen et compagnie ?
Comment aller chercher le sprite n°x en plein miieu du fichier ? A moi de retenir les offsets de ci ou ça ?

Pen^2 -> je peux retenir sans risque les SDL_Surface ? Le format est documenté, ça veut dire qu'il ne changera jamais ?
Ca serait le plus simple en effet, une fois que j'ai vu que le fichier est là, je n'ai plus rien à faire, je peux utiliser les données directement, sans plus allouer ou libérer quoi que ce soit

Si tu te lances dans des tableaux de chars, tu dois pouvoir utiliser les outils tt* de la ti chess team
Dans ce cas tu aurais un tableau par image PNG
Ça donnerait quelque chose du genre :

char image1[]= {0xCA, 0xFE, ...} ;
Il est possible que tu sois obligé d'écrire un fichier temporaire pour le charger avec libPng par contre

Perso je te déconseille de stocker les SDL_SURFACE directement : la taille occupée par une image non compressée, la compatibilité future comme tu le soulignes, etc.

Pen^2 (./124) :
Il est possible que tu sois obligé d'écrire un fichier temportaire pour le charger avec libPng par contre

Erf, remarque c'est pas bien dur mais c'est un peu con

Pen^2 (./124) :
Perso je te déconseille de stocker les SDL_SURFACE directement : la taille occupée par une non compressée, la compatibilité future comme tu le soulignes, etc.

Ok, ça me semblait merdique ça.

Folco (./125) :
Erf, remarque c'est pas bien dur mais c'est un peu con

Oui et non, pour l'utilisateur ça ne fait qu'un fichier à manipuler, il n'est pas censé connaitre les détails d'implémentation
(et puis avec un peu de chance ça ne sera pas obligatoire )

Oui. Et je le libère comment ce fichier ? Après le fclose, il sera toujours là ^^

Et sinon, question plus importante, je "repère" comment mes données dans le fichier ? Le sprite Tartampion, comment je sais qu'il est à l'offset $124365 ?

Bah, tu as ton tableau de l'image dont tu as besoin qui est défini quelque part : char imageTartampion[] = {0xCA, 0xFE, ...};Et quand tu en as besoin, tu fais (c'est un exemple, je ne sais pas du tout comment fonctionne cette librairie) : ecrireDansPngTmp(imageTartampion); typeQuiVaBien imageChargee = ceQuIlFaut; chargerImagePng(*imageChargee, FICHIER_PNG_TMP); supprimerPngTmp();
Et voilà, pas besoin de se souvenir de l'emplacement de l'image, mais seulement de son nom. Et si ça se trouve, tu n'auras même pas besoin de passer par un fichier temporaire
Tu peux avoir un fichier dans tes sources qui défini toutes les images, donc avec une suite de char imageXXX[] = {0xCA, 0xFE, ...};.

Folco (./127) :
Oui. Et je le libère comment ce fichier ? Après le fclose, il sera toujours là ^^

Et sinon, question plus importante, je "repère" comment mes données dans le fichier ? Le sprite Tartampion, comment je sais qu'il est à l'offset $124365 ?

pour ne pas répondre à coté de la plaque:
le plus simple/souple est de faire une std::map qui associe le nom du fichier à un offset:

std::map< std::string, int> offsets; //déclaration
loadImage(offsets["/data/sprites/tartampion.png"],size["/data/sprites/tartampion.png"]);

le plus rapide (à l'exécution) est de définir des constantes:

#define OFFSET_TARTAMPION 4324
#define SIZE_TARTAMPIO 312
loadImage(OFFSET_TARTAMPION, SIZE_TARTAMPIO);

Mais tu ne peux pas bêtement décompresser en mémoire ?

Le PNG? S'il faut la libpng c'est assez chiant à set-up.

GoldenCrystal (./130) :
Mais tu ne peux pas bêtement décompresser en mémoire ?

=>

Pen^2 (./126) :
(et puis avec un peu de chance ça ne sera pas obligatoire )

---

Jyaif (./129) :
le plus simple/souple est de faire une std::map qui associe le nom du fichier à un offset:

Heu, j'ai pas du comprendre ton truc, parce que, pour moi le plus simple reste de faire un tableau de char par image. Je ne vois pas le problème, en fait.
Parce que, bon, les offsets, c'est ni plus ni moins que les noms des tableaux

L'avantage des maps c'est surtout de pouvoir remplacer par des fichiers pendant le dév
Comme ça ton jeu peut fonctionner de deux manières: s'il trouve dans le code il prend là, sinon il prend le fichier externe, et tu n'as pas à toujours maintenir à jour le pack de données représentant les fichiers virtuels

Un tableau de char par image (et l'utilisations de pointeurs pour adresser les images), c'est faisable si les données sont dans l'exécutable. Là, elles sont dans un fichier externe.

Ben oui mais justement, il voulait qu'elles soient dans son exécutable si j'ai compris sa demande initiale (pas le courage de relire )
Enfin bon, comme ça il a le choix

Euh, en fait, j'ai fini par me ranger à vos arguments qui conseillaient de mettre les sprites dans un fichier externe (ce que je trouvais loin d'être bête) cf ./123

Ah, tiens, tiens

Ah, si seulement il existait la directive INCBIN en C...

Sous Windows tu peux utiliser les ressources pour inclure tes fichiers proprement et y accéder par nom ou par index, mais ce n'est pas portable, donc ça ne t'aidera pas.

Je précise un truc quand même: Si tes images sont placée dans le binaire, il vaut mieux qu'elles ne soient pas compressées, et plus exactement, qu'elles soient directement utilisables sans traitement.
Déjà, ça va augmenter la taille de ton éxécutable. Le système d'exploitation étant, on l'espère, pas trop mal foutu, il ne chargera pas directement toutes les données en mémoire, mais la mémoire virtuelle sera déjà prête malgré tout. (En fait, il va faire un mmap de l'éxécutable, mais bref).
Quand tu vas lire ton image en mémoire, le système va charger en RAM ce qui était resté sur le disque si besoin. À partir de là, tes données occuperont une place constante dans la mémoire. Dans le « meilleur des cas », elles finiront par se retrouver en swap, mais ça occupera quand même des ressources.
Donc si tu fais un traitement derrière (typiquement: décompression/placement en mémoire de texture), tu vas monopoliser deux fois plus de ressources que nécéssaire. Une fois pour l'image de l'exécutable chargée en mémoire, et une fois pour la ressource « traitée »… Méchant !
Il va de soi que cette technique est très intéressante si tu t'intéresses aux concours de « démo en 64k », mais si tes ressources sont de l'ordre du Mo, c'est à proscrire ^^

Sinon, il me semble (mais ça remonte à des années donc je peux pas garantir l'exactitude) que les ressources Windows prennent deux fois plus de mémoire que nécéssaire. (À vérifier hein, ma mémoire me dit que c'était pas juste pour le texte encodé en UTF-16 vs ANSI, mais également pour le binaire avec un truc genre <octet utile> 0 <octet utile> 0 …)

./138 sinon il y a des outils comme bin2o à inclure au makefile, j'utilisais ça sur les consoles portables
./139 ça ne sert à rien dans son cas vu qu'il utilise SDL, qui va copier les images en mémoire pour son usage

Ok, bien vu le coup de l'occupation double. Faut avouer que vu les disques modernes, mieux vaut en effet charger ce qu'on va directement utiliser, ya la place de stockage pour ça non ?

(ps -> c'est pour ça que exécution en flash sous PedroM powa, compression et *starter aux chiottes )

./139 : intéressant l'histoire des ressources, je n'en avais jamais entendu parler... faudrait vérifier ça.

GoldenCrystal (./139) :
Quand tu vas lire ton image en mémoire, le système va charger en RAM ce qui était resté sur le disque si besoin. À partir de là, tes données occuperont une place constante dans la mémoire. Dans le « meilleur des cas », elles finiront par se retrouver en swap, mais ça occupera quand même des ressources.

Non, pas en swap. C'est le fichier .exe du disque dur qui est mappé en mémoire virtuelle. Si une portion de ce fichier n'est plus nécessaire, et que l'OS a besoin de pages de RAM libres, cette portion n'est pas dégagé en swap, la mémoire est juste libérée directement sans que le système ne le sauve sur le disque dur (forcément, pour la remettre en place, il suffit d'ouvrir le fichier .exe originel).

Ah, il me semblait pourtant que c'était en swap, zut ^^
(On peut donc toujours avoir le problème de l'exécutable démarré à partir du CD ? )

Il me semble que oui, c'est pas une bonne idée d'éjecter un média qui contient un exécutable en cours d'exécution (et ça doit être pour la même raison qu'on ne peut généralement pas effacer un programme tant qu'il tourne).

Ah, et pour Folco : si jamais tu veux quand même faire un exécutable avec tout dedans, et que le résultat est trop gros à ton goût, UPX est ton ami

Zerosquare (./145) :
Il me semble que oui, c'est pas une bonne idée d'éjecter un média qui contient un exécutable en cours d'exécution (et ça doit être pour la même raison qu'on ne peut généralement pas effacer un programme tant qu'il tourne).

En tous cas je n'ai pas réussi à produire le problème sous Windows. Je retire le CD, je bourre la RAM jusqu'à ce qu'il balance presque tout en cache, mais ça continue de tourner.

Ca a l'air pas mal, mais on va tenter d'essayer de rester très simple : un simple fichier externe.

Pour retrouver mes données dedans ("à quel offset ai-je foutu le sprite machin ?"), si j'étais sur TI, j'aurais fait une dll, avec un export à chaque début de fichier :
fichier@0000 -> pointe sur le fichier 1
fichier@0001 -> pointe sur le fichier 2

Là, je vais devoir me démerder à faire un fichier binaire, avec les sprites écrits en brut, précédés par une table (typiquement : (int) Id sprite, (int) size, [...], [sprite 1], [sprite 2]

Pourquoi tu veux pas utiliser un fichier zip ?

c'est une archive compressée ? C'est simple d'utilisation avec une librairie portable ? zlib devrait faire l'affaire alors ?
Le but primordial pour moi est de faire simple.
L'idéal serait pour moi de faire :
extract(fichier zip, fichier à extraire);
SDL_FileOpen(...)

Si je trouve un truc qui fait ça, je prends de suite