chargement des fichier e3d

[XlurP]

en étudiant le code du client je suis tombé sur ça dans le fichier io/e3d_io.c :

Code : Tout sélectionner

    if (indicies_size == 2)
    {
        short_list = (unsigned short*)cur_object->indicies;
        for (i = 0; i < cur_object->index_no; i++)
            short_list[i] = SDL_SwapLE32(index_buffer[i]);
    }
    else
    {
        if (indicies_size == 4)
        {
            int_list = (unsigned int*)cur_object->indicies;
            for (i = 0; i < cur_object->index_no; i++)
                int_list[i] = SDL_SwapLE32(index_buffer[i]);
        }
        else
        {
            LOG_ERROR("This should never happen!");
            free_e3d_pointer(cur_object);
#ifdef    ZLIB
            gzclose(file);
#else    //ZLIB
            fclose(file);
#endif    //ZLIB
            return NULL;
        }
    }

a la ligne 269 :

Code : Tout sélectionner

short_list[i] = SDL_SwapLE32(index_buffer[i]);

je pense que cela devrait etre :

Code : Tout sélectionner

short_list[i] = SDL_SwapLE16(index_buffer[i]);

la taille des indicies etant alors codé sur un short

comme d'après des constatations rapides et un minimum de logique, je pense qu'actuellement le client n'utilise pas de fichiers e3d avec des listes d'indices sur 16 bits je doute que le probleme soit visible mais bon ...

[Hermitek]

En fait, chez moi, après quelques voyages en Séridia, il semble n'utiliser que des 16 bits et jamais de 32 bits, ce qui signifierait (d'après le code un peu au-dessus dans e3d_io.c) que tous les objets sont "petits" et ont moins de 65536 indices (donc "éléments"?).

Comme je suis en little endian (PC), remplacer SDL_SwapLE32(index_buffer) par SDL_SwapLE16(index_buffer) ne change rien : tout continue de marcher.

Mais comme index_buffer est un int et pas un short, et qu'il doit être stocké tel quel dans le fichier e3d (si j'ai bien compris), alors je dirais que c'est bien SDL_SwapLE32() qu'il faut utiliser.

Si un utilisateur de Mac (à condition que les Mac soient toujours big endian) faisait le test de remplacer SDL_SwapLE32() par SDL_SwapLE16() à cet endroit, peut-être confirmerait-t-il que ça ne marche plus, à moins qu'un autre phénomène qui échappe à ma maigre compréhension ne remettre tout en ordre

[XlurP]

en fait si tu regardes le code, au chargement du fichier e3d il indique si il utilise un short ou un int (indicies_size) en contenant le nombre d'octet, 2 ou 4

en plus comme tu le fais remarquer ce genre de pb n'apparait que les ordinateurs avec processeur big endian (quelque soit l'os) donc les ppc (anciens macs) les ultra sparc (sun) et les cell (ps3, pouvant tourner sous linux) principalement

Trinita il me semble que tu as un powerpc tournant sous mac os x 10.3 ou 10.4 a coté de ton cher, magnifique et indestructible linux