Forum Programmation.autre les formats d'images

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
2
24
déc.
2013

Bonjour rum.

Écrire son jeu vidéo, c'est à la mode en ce moment, et c'est vrai que c'est une activité rigolote.
En regardant les fichiers installés dans le cas de jeux vidéos pas libres et vieux (j'aime dosbox), une question m'est venue à l’esprit. Il n'y a pas de fichier image, des .png, .bmp, etc.
Il y a bien un dossier data avec un tas de fichiers dans un format étrange, d'où ma question: pourquoi et comment ?

J'ai plusieurs pistes:
- les images sont mises dans des formats bizarres pour ne pas pouvoir être réutilisées
- le format étrange sert à ajouter dans l'image des infos (point de chaleur par exemple), existe-il quelque part une explication sur ce genre de format ?
- ça a été fait comme ça car les développeurs voulaient impressionner les filles de l'équipe marketing (j'ai de gros doutes sur le taux de réussite de l'opération)
- les images sont directement intégrées au binaire, et dans ce cas comment fait-on (et pourquoi) ?

Si vous avez des réponses à mes questions, je serais ravi de vous lire.
Merci.

  • # sprites et animations

    Posté par  . Évalué à 5.

    toi, tu as raté le journal sur nanim!

    devnewton utilise au moins une des astuces des jeux d’époque pour stocker et utiliser les images: la décomposition du mouvement en plusieurs images rassemblées en une seule. certains jeux mixaient aussi les textures de terrain.

    bref, un journal à lire.

  • # structure data, compression, etc

    Posté par  . Évalué à 3.

    il fut un temps ou les machines n'avaient pas un core i3 et 2Go de RAM
    du coup pour stocker les images il fallait les compresser

    et pour les utiliser dans un jeu on gagnait des etapes processeurs/disques en stockant dans un fichier data l'image compressée deja structurée pour la mapper en memoire
    plutot que d'avoir des fichiers bmp non compressé, en vrac sur le disque a devoir preparer et mapper en memoire.

    • [^] # Re: structure data, compression, etc

      Posté par  . Évalué à 2.

      C'est exactement ce que je cherche (en vain) comme type de documentation. Je vais essayer avec les mots en plus que tu m'as donné.

      • [^] # Re: structure data, compression, etc

        Posté par  . Évalué à 2.

        bah le but à l'epoque c'etait d'eviter que n'importe qui reutilise les datas,
        donc à part decompiler le moteur pour savoir comment il accede aux datas, je ne vois pas trop.

        sauf si le createur du jeu a ouvert et documenté son moteur.

        • [^] # Re: structure data, compression, etc

          Posté par  . Évalué à 2.

          Bah et l'histoire de mapping mémoire ?
          Après je cherche pas un exemple précis, ma recherche n'a absolument aucun but pratique, je me demandais simplement comment/pourquoi. J'ai maintenant le pourquoi.

          • [^] # Re: structure data, compression, etc

            Posté par  . Évalué à 2.

            et pour le comment,
            bah chaque moteur a ses specificités,
            ca peut etre un tableau, une liste chainée, un arbre

            • [^] # Re: structure data, compression, etc

              Posté par  . Évalué à 2.

              Hm.
              Je crois que je sais ce qu'il me manque: je ne sais pas comment fonctionne un moteur 2D au niveau du chargement des images, je vais regarder pour SDL, la doc manque pas dessus. Merci.

              • [^] # Re: structure data, compression, etc

                Posté par  . Évalué à 2.

                bah SDL aura sa logique,
                QtQuick2 aura la sienne,

                maintenant faire un gros blob de data, c'etait valable dans le monde proprio pour des questions de performance ou d'algo proprio.

                mais avec nos machines à 4Go, carte 3D, gros processeurs, un acces aux images stockées dans de simple dossier/sous dossier, ca doit le faire aussi.

                • [^] # Re: structure data, compression, etc

                  Posté par  . Évalué à 2.

                  Bah j'en aurai vu une.

                  Comme je t'ai dit, ça n'a en aucun cas une utilité pratique, quand je bidouille avec SDL bien sûr que je laisse des gros bitmap en clair.

  • # objcopy est ton ami (ou pas)

    Posté par  . Évalué à 2.

    • les images sont directement intégrées au binaire, et dans ce cas comment fait-on (et pourquoi) ?

    objcopy permet de générer un fichier objet (foo.o) a partir d'un fichier "binaire" (foo.bin, foo.bmp, foo.txt,…)

    dans le Makefile :

    %.o: %.bin
    objcopy -B i386 -I binary -O elf32-i386 $^ $@

    dans les sources C ou C++

    // defining variable contained in font.bin
// symbols created by linker, unusable as it is
// main program should only use their address
extern unsigned char _binary____src_font_bin_start;
extern unsigned char _binary____src_font_bin_end;
extern unsigned char _binary____src_font_bin_size;

    Ces symboles doivent être exploités en tant que pointeur, donc par exemple dans le main on trouvera :

    const unsigned char * DefaultFontArray = &_binary____src_font_bin_start;
const unsigned long DefaultFontArraySize = (unsigned long) &_binary____src_font_bin_size;

    Par contre il y a quelques gros soucis de portabilité :
    - le Makefile contient l'architecture visé, donc ce programme qui compilait (et fonctionnait) très bien sur une distribution 32bits ne compile plus sur n'importe quelle distrib 64 bit (en tout cas plus sur la mienne)
    - sous windows mingw32 fait sauter la première underscore du symbole (à vérifier à coup de nm)

    La plupart des libraries (que j'ai utilisé) ne permettent pas de lire un fichier depuis la RAM. Par exemple, les routines d'ouverture d'image de SDL_image prennent un nom de fichier en paramètre. L'intérêt est donc limité.

    Les vrais naviguent en -42

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.