Port PS1 de Super Mario 64

 (github.com/malucard)
1 points par GN⁺ 2025-12-12 | 1 commentaires | Partager sur WhatsApp
  • Basé sur le projet de décompilation Super Mario 64 pour Nintendo 64, une version a été portée exclusivement pour PlayStation (PSX)
  • Il inclut des modifications importantes adaptées au matériel PS1, notamment le support de la vibration DualShock, la conversion vers des calculs à virgule fixe et l’optimisation du rendu
  • Ajout de fonctionnalités d’optimisation des performances comme le préprocesseur graphique, la compression de textures et l’optimisation mémoire des animations
  • Plusieurs bogues connus subsistent, dont un contrôle de la caméra incomplet, des problèmes de collision et de crash et une impossibilité de générer la musique
  • Un expérimental de portage multi-plateforme de jeu classique, intéressant pour le développement de consoles legacy et la recherche en reverse engineering

Aperçu du projet

  • Ce code est un fork de la version entièrement décompilée de Super Mario 64 (J/U/E/SH), ciblant uniquement le PSX et le PC (débogage)
    • Le build Nintendo 64 n’est plus pris en charge
    • Actuellement, seul le ROM US peut être compilé
  • La compilation du jeu n’inclut pas les assets originaux, et l’extraction des assets depuis une ROM d’origine est nécessaire

Fonctionnalités principales

  • Ajout d’un graphique compatible avec la DualShock™, imitant l’affichage d’origine “Rumble Pak Compatible”
  • Prise en charge du signal de vibration analogique pour le gros moteur et du signal numérique pour le petit moteur de la DualShock
  • Mise en place d’un soft float basse précision pour PSX afin de minimiser la baisse de performance des calculs flottants
  • Remplacement du code par de la mathématique à virgule fixe, avec utilisation de vecteurs et matrices d’entiers 16 bits, norme PSX
  • Simplification et réécriture du render graph worker
  • Subdivision de polygones (jusqu’à 2x) pour atténuer les problèmes de gros polygones
  • Conversion des RSP Display Lists en format personnalisé en mode JIT, pour améliorer la vitesse de traitement
  • Préprocesseur de display list pour supprimer les instructions inutiles et optimiser les meshes
  • Compression des animations Mario (580,632 → 190,324 octets) avec placement direct en VRAM
  • Ajout d’un profiler personnalisé et d’un encodeur de texture 4bpp
  • Remplacement par des ombres hexagonales en tenant compte des limites de transparence de la PSX
  • (Prévu) Réécriture de la rotation de caméra via le stick analogique droit et du système de sous-composants Goddard

Problèmes connus

  • Arbres flottants, certaines animations qui ne fonctionnent pas ou provoquent un crash
  • Impossible de générer la musique, effets sonores manquants ou déformés
  • Contrôle de caméra incomplet, crash en entrant dans certains niveaux
  • Échec du chargement de la séquence de fin, Lakitu n’apparaît pas, Pol ne fonctionne pas
  • Temps de chargement élevé à cause du chargement individuel des textures, distorsion des textures due aux limites de la PSX
  • Préprocesseur graphique à améliorer, erreurs de rendu sur certaines textures, écran titre incomplet, menu pause ne répond pas

Méthode de compilation

Linux

  • Installez la chaîne d’outils mipsel-none-elf-gcc, puis clonez le dépôt
  • Placez le fichier baserom.us.z64 à la racine du dépôt
  • (Optionnel) Ajoutez les fichiers de bande-son .wav (0~37) dans le dossier .local
  • Exécutez make pour générer l’image ISO (build/us_psx/sm64.us.iso)
  • La version benchmark (make BENCH=1) génère uniquement des ELF/EXE sans ISO et nécessite une PSX 8 Mo de RAM

Windows (non vérifié)

  • Installez MSYS2 puis configurez le paquet mingw-w64
  • Installez mipsel-none-elf-gcc et clonez le dépôt sm64-psx
  • Déposez le fichier baserom.us.z64 puis exécutez make
  • Les résultats de build sont générés aux mêmes emplacements que sous Linux

Dépannage

  • Si gcc n’est pas reconnu, vérifiez que vous n’avez pas lancé un environnement MSYS2 incorrect
  • Si baserom.us.z64 est manquant, vérifiez l’emplacement du fichier
  • Si le Makefile n’est pas trouvé, vérifiez le chemin du répertoire
  • En cas d’erreur de paquets, exécutez pacman -Syu puis pacman -Su pour mettre à jour
  • Vérifiez le fonctionnement de mipsel gcc via la commande mipsel-none-elf-gcc -v
  • Lors d’un changement de plateforme, make -C tools clean est nécessaire pour recompiler les outils

Structure du projet

  • actors : comportement des objets, géolayout, display lists
  • assets : animations et données de démo
  • src : sources C du cœur du jeu (audio, moteur, jeu, menus, portage, etc.)
  • textures, text, levels : données graphiques et niveaux
  • tools : outils de build
  • lib : contient le code SDK N64

Contributions

  • Pull Request les bienvenues
  • Avant les changements majeurs, il est recommandé de créer une Issue puis d’en discuter

À lire aussi

1 commentaires

 
GN⁺ 2025-12-12
Réactions sur Hacker News

  • Si vous aimez ce port, le projet qui réimplémente entièrement SM64 sur GBA devrait aussi vous intéresser
    Voir la vidéo YouTube

    • Puisqu’on est sur HN, il faut le préciser : ce port GBA est écrit en Rust
      Article connexe : The Impossible Port – Super Mario 64 on the Game Boy Advance
    • Intéressant. Je me demande si la GBA pourrait faire tourner une version allégée façon Minecraft
      Ça irait probablement assez bien aussi sur N64, et j’aimerais essayer un jour quand j’aurai mis la main sur une SummerCart64
    • Quelqu’un connaît-il le code source de ce projet ? Il semble avoir été supprimé
    • C’est impressionnant, mais personnellement je trouve ça un peu difficile à regarder
      Cela dit, le simple fait d’avoir mené ça à terme est vraiment remarquable

  • C’est vraiment une prouesse étonnante
    J’ai eu les deux consoles à l’époque, et ce port me rappelle à quel point la N64 incarnait bien en 1996 cette ambiance “SGI à la maison”
    Je me souviens encore très bien du choc ressenti la première fois que j’ai vu Mario 64 sur une N64 japonaise importée
    Ça me rappelle aussi la diversité du paysage vidéoludique de l’époque, où des jeux comme Wipeout sur PSX exploraient une toute autre direction

  • On dit que la « tessellation (jusqu’à x2) » réduit le problème des gros polygones, mais dans la vidéo on voit encore beaucoup de distorsion de texture
    x2 ne suffit sans doute pas, ou alors il faudra refaire la géométrie des niveaux

    • Je vois aussi la distorsion de texture, mais pas le tremblement géométrique typique des jeux PS1
      J’imagine que comme les calculs en virgule flottante sont gérés en logiciel, le perspective-correct mapping pèserait trop lourd sur le framerate
    • Pour l’instant, il n’y a presque aucun prétraitement sur les polygones des niveaux
      Quand ce sera implémenté plus tard, les gros polygones seront subdivisés, ce qui devrait aussi résoudre le problème des limites sur les coordonnées de texture
    • C’est d’ailleurs indiqué dans les problèmes connus : « la tessellation n’est pas suffisante »
      On retrouve encore ce grain brut de la 3D des débuts propre à l’ère PS1

  • Je me demande s’il existe une vidéo de fonctionnement ou des captures d’écran. Je comprends pourquoi il n’y a rien sur GitHub

  • Beaucoup se plaignent de la distorsion de texture, mais ça reste quand même un travail vraiment impressionnant

  • Impossible de ne pas mentionner Kaze
    Cela fait des années qu’il optimise Mario 64 de multiples façons, et si le croisement entre rétro-gaming et programmation vous intéresse, sa chaîne vaut vraiment le détour
    Chaîne YouTube de Kaze

    • Dans une vidéo publiée en août, il analysait à quel point Mario 64 gaspille de la RAM, et c’est là qu’il a évoqué pour la première fois la possibilité d’un port PS1
      Je ne pensais pas que ça se concrétiserait aussi vite
      Voir la vidéo associée
    • Il est vraiment incroyable (et très musclé)
      S’il existait sur PS1 quelqu’un avec le niveau de connaissance de Kaze, un projet comme Mario 32 serait sans doute possible

  • On voit récemment une explosion des projets de décompilation, et je me demande d’où ça vient

    • La raison principale, c’est l’amélioration des outils prenant en charge la décompilation avec correspondance binaire 1:1
      decomp.me en est un bon exemple
      Ce type d’outil permet de reconstruire du code correspondant exactement au binaire d’origine, ce qui facilite le lancement rapide de nouveaux projets
      L’apparition de couches de portage qui imitent les API des SDK console a aussi joué un rôle
      Mais cela demande un travail énorme, notamment pour reproduire les comportements anormaux d’anciens toolchains afin d’obtenir une correspondance parfaite
    • C’est peut-être aussi parce que l’IA a rendu la décompilation plus facile
    • C’est peut-être juste à cause de l’IA
    • Le fait que davantage de gens utilisent Ghidra a aussi eu un impact

  • Il y a eu récemment un port Dreamcast, et Star Fox 64 comme Mario Kart 64 ont aussi été portés sur plusieurs plateformes
    Liste connexe : awesome-game-decompilations

    • Le port de Star Fox 64 vient lui aussi d’être terminé

  • Dommage qu’il n’y ait pas de captures d’écran

  • « Enfin, Super Mario 32 »