Les "nouvelles" plateformes 64 bits commencent doucement à s’imposer, en particulier l’amd64, et comme Linux se porte pas trop mal sur ces procs, les premières demandes sont arrivées : "Raydium et le 64 bits : ça marche ?"
Première pensée : la galère. L’histoire de Raydium à fait qu’on a rarement regardé plus loin que le matos qu’on avait sous la main, c’est à dire le combo intel-amd-nvidia-ati-linux-windows, le tout en 32 bits. Les plateformes type PPC ("Mac"), par exemple, nous sont complétements inconnues.
Premier impact de cette horrible facon de faire : une probable incompatibilité en réseau entre les versions "PC" et "Mac" des jeux (Little Endian / Big Endian). Le plus amusant dans l’histoire, c’est que rien n’est fait dans Raydium pour pouvoir contrer ce problème facilement, ce qui promet de joyeuses heures de développement en plus.
Dès lors, imaginez l’ampleur du problème sur les amd64, puisqu’il ne s’agit plus ici de se mettre d’accord sur l’ordre de lecture des octets, mais aussi sur la taille des variables.
Un "int" (type natif par défaut du langage C), par exemple, fait en conséquence 32 ou 64 bits en fonction de la machine sur laquelle on compile le code.
Ça semble peut être n’être qu’un problème léger, vu de loin, mais c’est en fait un sombre calvaire à partir du moment ou cette situation n’a pas été envisagée dès la première ligne de code (ps: on approche des 50 000 lignes pour Raydium …).

RyLe, autre codeur du groupe, possède le matos nécessaire au test (amd64 + mandrake 64), ce qui nous a offert la possibilité de tenter l’aventure.
Première étape, réussir à trouver et compiler les dépendances de Raydium sur ce proc :
– OpenGL : NVidia livre des pilote compilés pour amd64, pas de problème.
– Glut/GLU ("surcouches" GL) : Mesa est livrée de base dans la Mandrake amd64.
– OpenAL (son): la version CVS se compile sans problème, seule une légère modification dans la Makefile a été nécessaire.
– PHP (scripting): Le monstre se compile à merveille (étonnant, non ?)
– ODE (physique): C’était trop beau : des morceaux d’ODE sont codés en assembleur (timers), et Opcode (sous-librairie d’ODE) abuse d’astuces mémoire qui ne passent plus du tout sur les amd64 ( qui organisent leurs pages mémoires d’une manière très différente des procs intel32).
Après quelques messages sur la mailing list d’ODE, un type (Tanguy Fautre) dit être lui aussi en galère pour les mêmes raisons, et se porte volontaire pour tenter un portage d’Opcode en 64 bits. Quelques semaines plus tard et après quelques échanges, miracle : un patch pour Opcode semble émerger ! (c’est pas génial le logiciel libre ?)

Quelques ajustements plus tard, on passe à la compilation de Raydium : pas le moindre warning, pas la moindre modif à appliquer. (wtf ?! on fait du code propre maintenant ?)
Plus fort encore, notre test6 (mini FPS, application "témoin") semble tourner, même si des tests un peu plus poussés montrent qu’ODE semble péter un cable de temps en temps (souvent lors d’un lancement de roquette, a priori), et explose la scène.
On va organiser un bonne vieille soirée débug pour tenter de trouver la source de cette instabilité (Raydium ? ODE ? Opcode ?), pour passer ensuite aux "fameux" tests de la couche réseau.

Pour le reste, réunion ce soir pour monter l’association CQFD (plus de galères pour les assurances lors des salons et festivals), et feuille de style pour le blog qui singe celle du site de Raydium (qui essaye, en fait), et préparation pour la Linux Party de la semaine prochaine. (ManiaDrive, le "clone" de Trackmania a pas mal avancé cette semaine : sons, scores sur le net, mode réseau correct, …).