• # objcopy est ton ami (ou pas)

    Posté par . En réponse au message les formats d'images. É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