GTA San Andreas tourne en 3D sur une vraie Nintendo DS dotée de seulement 4 Mo de RAM grâce à un portage C++ inédit
À quelques jours de l’arrivée de Grand Theft Auto VI, le développeur indépendant et moddeur Sammwy vient de réaliser un tour de force matériel que beaucoup jugeaient impossible. Son projet open-source gtasands sur GitHub fait tourner Grand Theft Auto : San Andreas directement en 3D sur une véritable Nintendo DS équipée de seulement 4 Mo de RAM.
Jusqu’ici, la portable à double écran de Nintendo n’avait accueilli qu’un seul épisode officiel conçu sur mesure en vue de dessus, Grand Theft Auto : Chinatown Wars, en 2009. Faire entrer l’immense monde ouvert 3D de Los Santos dans une console huit fois moins puissante que la PlayStation 2 exigeait de réécrire intégralement le moteur du jeu en C++17.
67 MHz sans unité flottante et 4 Mo de RAM : le mur matériel de la Nintendo DS
À sa sortie en octobre 2004 sur PlayStation 2 (dont la version originale s’échange aujourd’hui autour de 9,20 € en loose et 15,29 € complète en boîte PAL selon la cote argus de GTA San Andreas sur Retrocharting), le chef-d’œuvre de Rockstar North s’appuyait sur un processeur Emotion Engine à 294 MHz et 32 Mo de mémoire RDRAM. En face, la Nintendo DS standard oppose un processeur ARM946E-S cadencé à 67 MHz, dépourvu de la moindre unité de calcul en virgule flottante (FPU), et un plafond strict de 4 Mo de mémoire vive (porté à 16 Mo et 134 MHz en mode Nintendo DSi).
Encore plus contraignant, la mémoire vidéo dédiée aux textures (VRAM banques A et B) se limite à 256 Ko, tandis que le moteur géométrique matériel GX de la portable sature au-delà de 2 048 polygones et 6 144 sommets par image. Comme les coordonnées géographiques de San Andreas dépassent la limite signée 20.12 du GPU de la console, le moteur calcule et émet chaque polygone relativement à la position actuelle de Carl « CJ » Johnson et de la caméra.
Pour contourner l’absence de FPU sur la puce ARM9, Sammwy a banni les calculs flottants lourds au profit d’une arithmétique en virgule fixe dans la physique, les animations et la détection des zones (converties en entiers d’un seizième de mètre). Si vous souhaitez redécouvrir l’épisode original sur des machines actuelles sans sortir le fer à souder, vous pouvez consulter notre guide complet pour jouer légalement aux 16 épisodes de Grand Theft Auto en 2026.
Un vrai moteur C++17 propulsé par gta-reversed et un streaming en survie
Contrairement aux montages vidéo factices ou aux simples flux vidéo diffusés depuis un PC qui circulent parfois en ligne, la démonstration publiée sur la chaîne YouTube de Sammwy exécute bel et bien le code nativement sur le matériel portable et sous l’émulateur melonDS. Le développeur s’est appuyé sur la base documentaire du projet communautaire gta-reversed comme référence comportementale, tout en remplaçant intégralement l’ancien middleware RenderWare par un pipeline 3D GX maison.
Un script de conversion en Python (tools/assets.py) extrait les fichiers d’une installation PC officielle de San Andreas pour les recompiler dans des formats binaires allégés taillés pour la DS : archives DSPK indexées en FNV-1a, modèles DMDL, textures compressées DTEX, maillages de collision DCOL et animations streamées DANM. Le tout génère quatre variantes de ROMs (.nds et .dsi) capables de fonctionner soit via le système de fichiers embarqué NitroFS (environ 387 Mo pour l’ensemble du monde découpé en secteurs), soit depuis une carte SD.
Sur les 4 Mo de mémoire vive de la console, le tampon de streaming (STREAM) ne dispose que de 2,5 Mo. Lorsqu’un véhicule comme la Greenwood ou un groupe de piétons doit apparaître alors que le cache de la carte occupe déjà 2,4 Mo, l’allocateur mémoire TLSF déclenche la fonction world::releaseRam pour purger instantanément les bâtiments non affichés lors des deux dernières images (algorithme LRU).
De même, au lieu de figer CJ pendant 300 images (soit 15 secondes d’attente) le temps de charger tout un quartier après une téléportation, le système world::nearSectorsPending() ne verrouille désormais que la grille immédiate de 3×3 secteurs autour du joueur. CJ peut ainsi marcher, courir, tirer, conduire, croiser des gangs régis par l’IA d’origine (CPedIntelligence) et même visionner les cinématiques d’introduction (PROLOG1 et PROLOG3) avec l’officier Tenpenny.
De 8,7 ms à 0,1 ms sur le second écran : l’optimisation qui change tout à Grove Street
Toute l’ingéniosité de ce portage réside également dans l’exploitation du double écran de la Nintendo DS, à contre-courant d’initiatives récentes comme le projet Pokémon Fulldex qui fusionne les deux écrans des classiques Nintendo DS en 16:9. Ici, l’écran supérieur est entièrement consacré au rendu 3D du quartier de Grove Street, du ciel dynamique et de la météo, tandis que l’écran tactile inférieur loge l’interface dans un framebuffer RAM de 96 Ko.
D’une simple pression sur le bouton SELECT, le joueur bascule l’écran du bas entre le HUD officiel de GTA (radar rotatif avec tuiles streamées, jauge de vie, argent, heure) et une console de débogage tactile permettant d’activer des codes de triche ou de faire apparaître des voitures devant CJ. Lors des derniers correctifs publiés le 8 novembre 2026, Sammwy s’est aperçu que le redessin systématique du disque radar et le transfert DMA de 96 Ko vers la banque VRAM C à chaque balayage vertical engloutissaient 8,7 millisecondes par image et parasitaient les canaux audio.
En ajoutant une signature quantifiée qui ne rafraîchit le radar et le tampon texte que lorsqu’un élément bouge réellement à l’écran, le temps de calcul du second affichage a chuté de 8,7 ms à seulement 0,1 ms par image. Résultat immédiat au point d’apparition de Grove Street : le framerate bondit de 19 à 25 images par seconde sur ce matériel de 2004, tandis que le menu pause tourne désormais à 60 FPS constants (2,7 ms par frame) sans le moindre grésillement radio.
Mon carnet de veille
Quel tour de force déniché cette nuit sur GitHub ! À l’heure où les blockbusters modernes réclament 16 Go de VRAM et plus de 200 Go de stockage SSD sans même garantir une fluidité exemplaire, voir le quartier de Grove Street, ses véhicules et ses cinématiques tenir dans les 4 petits mégaoctets d’une Nintendo DS de 2004 force l’admiration. Ce n’est pas une simple curiosité visuelle : la rigueur de l’architecture mémoire de Sammwy rappelle l’époque héroïque où chaque octets de cache sur cartouche devait être gagné à la sueur du code.
En parcourant les derniers commits C++17 du dépôt avec notre développeuse Chaya « Chayane », un détail nous a tout particulièrement bluffés : l’optimisation du transfert DMA sur l’écran tactile inférieur. Récupérer 8,6 millisecondes de temps processeur par frame simplement en évitant de copier un tampon de 96 Ko quand le radar ne bouge pas, et remplacer les calculs flottants de zones par des entiers d’un seizième de mètre sur un vieux cœur ARM9 sans FPU, c’est du grand art logiciel. Il ne reste plus que la machine virtuelle de scripts SCM et le système de sauvegarde à boucler avant qu’une première version publique compilée ne vienne faire chauffer nos vieilles DS Lite et DSi.
Retrouvez Pro-Gamer en priorité sur Google
Ajoutez pro-gamer.fr à vos sources préférées pour retrouver nos guides et actus directement dans votre flux Google Discover et vos résultats de recherche.
Journaliste et joueur français originaire de Lyon, Bastien « Orion » s'est expatrié il y a près de dix ans dans la ville de Québec, au cœur du quartier Saint-Roch où évoluent plusieurs grands studios canadiens. Avant de traverser l'Atlantique, il a forgé sa plume touche-à-tout au sein de rédactions web et télévisées françaises spécialisées des années 2000 et 2010, notamment sur JeuxVideo.fr et JeuxNews. Passionné aussi bien par les blockbusters AAA et les coulisses de l'industrie nord-américaine que par le rétrogaming, la scène modding et les curiosités techniques, il assure sur Pro-Gamer la veille transatlantique et le suivi en direct des annonces américaines et japonaises.
