tikilou

Wii System Menu Extractor & Normalizer
 
Un outil avancé de reverse engineering, écrit en Rust, conçu pour extraire, décompresser et normaliser autant de ressources que possible du Menu Système de la Wii vers des formats standards et ouverts (glTF, PNG, JSON, WAV).
Il peut également — bien que ce ne soit pas son objectif principal — extraire et convertir des fichiers de certains jeux Wii.
 

1. Accès aux données (moteurs d’extraction)
- ASH (.ash) : Machine virtuelle Huffman/LZ77 personnalisée et intégrée, permettant une décompression bit-par-bit exacte.
- LZ77 (.LZ, .lz7) : Prise en charge complète des variantes 0x10, avec détection robuste.
- Yaz0 (.szs) : Décompresseur LZSS haute performance pour les archives de chaînes.
- Archives standards (.app, .arc, .zip) : Extraction complète des arborescences U8 et ZIP.
- Conteneurs NW4R (.brres, .breft) : Extraction des sous-fichiers par scan heuristique de signatures.

2. Normalisation des ressources (qualité musée)
Graphismes (pixel-perfect)
- TEX0 / TPL / BTI → PNG : Décodage GX complet.
- Amélioration unique : stratégie « White-Alpha » pour la gestion des formats à intensité (I4, IA4), garantissant des éléments d’interface sans artefacts noirs.
Prise en charge complète de RGBA8 (planaire) et CMPR (Wii BC1/DXT1).
- Gestion des palettes (PLT0) : Application automatique aux textures indexées (CI4 / CI8).
 
Interface (dépendante de l’UI)
- BRLYT → JSON : Reconstruction de l’arbre de scène hiérarchique complexe.
- BRLAN → JSON : Extraction des courbes d’animation.
 
Modèles 3D
- MDL0 → glTF 2.0 : Export de la géométrie complète (versions v1 à v11).
 
Typographie
- BRFNT → JSON & PNG : Décodage bit-par-bit exact, incluant le tuilage spécifique Wii 8×4 utilisé par les polices (Rodin).
Extraction des métriques de glyphes (CWDH) et des tables Unicode (CMAP).
 
Audio & musique
- BWAV → WAV : Prise en charge des fichiers du Menu Système.
- RWAV / RWSD / RBNK → WAV : Décodage DSP-ADPCM matériel 16 bits.
- BRSEQ → MIDI & JSON : Séquences musicales (travail encore en cours).
 
Reverse engineering
- SEL → JSON : Prise en charge des fichiers binaires (Static Executable Linker).
Récupération du chemin de build d’origine (.elf) et de la table complète des symboles (noms internes des fonctions).

UTILISATION

Build

cargo build --release

Exécution

./target/release/wii_system_menu_extractor <CHEMIN_DU_DOSSIER_OU_FICHIER_TITLE>

Le programme traite les fichiers de manière idempotente : il détecte les extractions déjà effectuées et ne traite que les nouveaux fichiers ou ceux modifiés.
Lancer le programme directement (sans terminal) dans le répertoire courant produit le même effet sur son contenu, même sans sortie graphique.

Il n’existe pas encore de version officielle ni de numéro de version. Le programme est toujours en développement, mais il est fonctionnel et suffisamment efficace pour la majorité des usages.

APPIMAGE

Un script de build AppImage est fourni dans le dossier scripts.
Une AppImage prête à l’emploi est également disponible dans le dossier packages.

Le programme a été compilé sous Debian 13 et nécessite au minimum les versions de certaines bibliothèques incluses dans cette distribution de référence.
En conséquence, cette AppImage devrait fonctionner sur toutes les distributions Linux à jour.

ETAT DU SUPPORT (CIBLES)

Format : TEX0 / TPL
Normalisation : PNG
Statut : Ultra-fidélité (White-Alpha)

Format : BRLYT / BRLAN
Normalisation : JSON
Statut : 100 % (structure arborescente)

Format : BRFNT
Normalisation : PNG + JSON
Statut : Pixel-perfect (Rodin tuilé)

Format : SEL
Normalisation : JSON
Statut : Symboles et chemin ELF

Format : BWAV / RWAV
Normalisation : WAV
Statut : Bit-perfect

Format : MDL0
Normalisation : glTF 2.0
Statut : Géométrie et UV

Format : BMG
Normalisation : JSON
Statut : Multilingue

GLOSSAIRE DES FORMATS ET JSON NORMALISES

Archives et compression

ASH / LZ77 / Yaz0
Formats de compression propriétaires.
Normalisation : décompression vers les fichiers originaux (.arc, .brres).

U8 / ARC / APP
Archives de fichiers non compressées.
Normalisation : extraction dans des sous-dossiers _extracted.

Graphismes et typographie

TPL / TEX0 / BTI (textures Wii) vers PNG.
Stockage tuilé GX. Les formats IA4 et IA8 sont normalisés via la stratégie White-Alpha pour l’interface.

BRFNT (police binaire) vers atlas PNG et JSON.
Le JSON contient les métriques (hauteur, ligne de base) et le mapping Unicode (code vers index de glyphe).
Champs JSON : ascent (hauteur au-dessus de la ligne de base), widths (largeur par glyphe).

Interface et animation

BRLYT (layout) vers JSON.
Stocke l’arbre hiérarchique de l’interface (panes).
Le champ root contient la pile de panes avec le nom, les positions x/y/z, l’échelle, la rotation et les enfants hiérarchiques.

BRLAN (animation de layout) vers JSON.
Contient les séquences d’animation appliquées aux panes BRLYT.
Champs JSON : animations (cibles), keyframes avec time (frame) et property (valeur).

Audio

RWAV / BWAV vers WAV.
Fichiers audio bruts, souvent en DSP-ADPCM (compression matérielle 4 bits) ou PCM16.

BRSAR / RWSD vers WAV et JSON.
Le JSON liste les sons et leurs propriétés (volume, pitch).

Reverse engineering

SEL (table des symboles) vers JSON.
Contient les métadonnées de linkage du code Wii, souvent présentes dans les fichiers .app.
Champs JSON : internal_path (chemin d’origine sur le PC du développeur Nintendo), symbols (liste complète des noms de fonctions C++ récupérées).

BMG (Message Group) vers JSON.
Table de textes localisés.
Champ JSON : messages associe un identifiant numérique à la chaîne traduite.

LICENCE

GNU General Public License version 3 (GPL 3) – Tikilou

LIENS

AppImage :
https://github.com/T...x86_64.AppImage
 

Dépôt GitHub :
https://github.com/T...ctor-Normalizer

PS: Ce projet fait partie d’un projet “Museum” beaucoup plus vaste.

C’est encore en développement.
L’approche est volontairement alignée avec celle de Valve sur la préservation et l’accès aux contenus.

Wii System Menu Extractor & Normalizer


Je vous présente un outil d'ingénierie inverse avancé écrit en Rust, conçu pour extraire, décompresser et normaliser autant d'assets du System Menu de la Wii que possible, vers des formats standards et ouverts (glTF, PNG, JSON, WAV).

(edit RomAnOCrY : oups... validé un peu vite, Tikilou, tu peux faire quelque modif ? (lien/capture...etc) )

Animal Crossing : quand la décompilation et l’IA donnent une nouvelle voix aux habitants

Il y a des hacks qui se contentent de changer quelques textures ou d’ajouter une option de confort. Et puis il y a ceux qui repoussent les limites de ce qu’on croyait possible. C’est le cas du travail de Josh Fonseca, qui a réussi à relier Animal Crossing sur GameCube à une intelligence artificielle moderne. Résultat : Tom Nook, Kéké et les autres villageois ne sont plus condamnés à répéter des dialogues écrits il y a plus de vingt ans. Ils sont désormais capables d’improviser, de réagir et de tenir des conversations inédites.

Ce qui rend ce projet fascinant, c’est qu’il ne repose pas sur un mod classique, mais sur un mélange de reverse engineering mémoire et de décompilation du jeu.

La décompilation, un préalable indispensable :

Pour comprendre comment fonctionne un programme sans avoir accès à son code source, il faut remonter à partir du binaire. Sur GameCube, les jeux sont écrits en C puis compilés en instructions PowerPC. Décompiler, c’est traduire ce code machine en un C reconstruit, lisible par un humain.

Dans le cas d’Animal Crossing, la communauté de passionnés a déjà réussi à isoler des fichiers entiers comme m_message.c, qui gère l’affichage des dialogues. Ce fichier est une mine d’or : on y découvre que le moteur du jeu ne se contente pas d’afficher du texte brut, mais qu’il interprète une suite de caractères spéciaux et de codes de contrôle (pauses, émotions, couleurs, fins de message).

Sans cette étape de décompilation, il aurait fallu des mois d’essais-erreurs dans la mémoire pour comprendre pourquoi certaines injections plantaient le jeu. Là, la documentation existe déjà : on connaît la “grammaire” attendue par le moteur.

Le cœur de la bidouille : détourner la RAM :

Au lieu de patcher le binaire, Josh a choisi une voie plus élégante : intercepter les dialogues directement en mémoire vive.

Quand un personnage parle, le texte est copié en RAM dans une zone bien précise avant d’être affiché. C’est cette zone que le script va surveiller en permanence. Dès qu’une chaîne apparaît, elle est capturée, envoyée à un modèle de langage moderne, puis remplacée par la réponse générée.

Pour la console, rien n’a changé : elle continue de lire dans sa mémoire et d’afficher le contenu qu’elle y trouve. Mais ce contenu, lui, ne vient plus du script original : il sort tout droit d’une IA.

Le pipeline IA ↔ GameCube :

Lecture mémoire : un script Python lit la RAM via l’émulateur Dolphin.
Envoi au LLM : le texte intercepté est transmis à une IA hébergée sur une machine externe.
Post-traitement : la sortie de l’IA est traduite en “langage Animal Crossing” (codes spéciaux : \p pause, \e émotion, etc.).
Réinjection : la chaîne convertie est replacée dans le tampon mémoire.

Le système n’est pas limité à l’émulation. Il fonctionne sur Dolphin, mais aussi sur une GameCube réelle avec BroadBand Adapter, en exploitant la mémoire via le réseau.

Le projet est compatible avec différentes API (OpenAI, Google Gemini…), mais il est aussi possible d’utiliser son propre LLM en local. Avec une RTX 3090 (24 Go de VRAM) considérée comme un minimum confortable, on peut générer les dialogues depuis chez soi sans dépendre de services tiers.

Pourquoi ce n’est pas si simple:

Alignement mémoire : les dialogues sont dans des structures binaires précises.
Encodage : le jeu utilise un format proche du Shift-JIS.
Concurrence : plusieurs PNJ parlant en même temps posent problème.
Latence : les appels à l’IA prennent 1–2 secondes → solution : pauses simulées.

La décompilation a permis de comprendre et respecter toutes ces contraintes.


Des habitants qui parlent “vraiment” :
Grâce à ce système, les PNJ ne sont plus limités aux scripts Nintendo. Ils peuvent commenter l’actualité, improviser, ou se moquer du joueur. On redécouvre le jeu sous un nouveau jour.


Une porte ouverte sur le rétro-gaming augmenté :
Ce projet prouve que la combinaison décompilation + injection mémoire + IA peut donner une nouvelle vie à des jeux anciens. Demain, d’autres classiques pourraient être augmentés de la même façon.


Comment ça se fait, en pratique ? :

-Dumper la RAM sous Dolphin.
-Repérer une phrase connue.
-Vérifier la stabilité de l’adresse.
-Injecter un test (“TEST”).
-Automatiser la capture.
-Nettoyer la sortie IA.
-Réinjecter proprement.

Exemple concret : Tom Nook et l’IA

Sans hack :
"Bonjour ! Bienvenue chez Nook !"

Avec hack :
Le script intercepte la phrase.
Contexte envoyé à l’IA (PNJ = Tom Nook).
Réponse générée : "Ah, te voilà enfin ! J’espérais que tu viendrais dépenser quelques clochettes…"
Ajout des codes de pause et d’émotion, puis réinjection.
À l’écran : Tom Nook fait une pause et affiche ce nouveau dialogue, parfaitement intégré.

Pour aller plus loin : 
Code source : GitHub
– animal-crossing-llm-mod

Démo vidéo : [url=https://www.youtube.com/watch?v=7AyEzA5ziE0]YouTube


Installer son propre serveur IA/LLM : 
-Lancer un serveur local compatible OpenAI API tel que vLLM, Ollama, etc..
-Configurer l’URL et la clé d’API.
-Dolphin (ou GameCube + BBA) enverra les requêtes directement à ce serveur.


Matériel recommandé :
RTX 3090 (24 Go VRAM) = idéal pour modèles 7B.
RTX 4090 = encore plus fluide.
16-12 Go VRAM = modèles 5-7B quantifiés (Gemma, Mistral, Qwen).
8-10 Go VRAM = modèles 3-5B quantifiés.
6 Go VRAM ≈ modèles 2-3B quantifiés.

Modèles LLM adaptés selon la VRAM :
≈ 24 Go (RTX 3090) → Qwen-7B, Mistral-7B, Gemma-7B (quantifiés), confort + contexte long.
16-12 Go → 7-8B en quantification 8-bit, ou 5-6B en 16-bit.
8-10 Go → modèles ~5-6B ou plus petits (Phi-3 Mini, Gemma-4B).
6 Go → modèles 2-3B quantifiés (Qwen-2.5 2B, Phi-3 Mini).

Avec ces solutions, chacun peut adapter le projet à sa machine et profiter d’un Animal Crossing augmenté par l’IA.

Eden : de la genèse à la v0.0.3

De Yuzu à Citron, puis Eden

Après l’arrêt brutal de Yuzu en 2024, du fait de la disponibilité de son code source sous licence libre, plusieurs forks ont vu le jour pour poursuivre le travail laissé en suspens.
Parmi eux, Citron s’est imposé rapidement avec une communauté active, mais aussi ses propres polémiques.
Une partie des développeurs de Citron a fini par se détacher pour créer Eden, présenté comme un fork de Yuzu mené par un ex-développeur de Citron.
Le projet affiche clairement ses priorités et son développement est très actif : performances, stabilité et portabilité, avec un support officiel pour Linux (utile notamment pour la SteamDeck et la PS4 Pro), Android, et des travaux en cours sur macOS, Windows, BSD et Solaris.


Ce qu’est Eden aujourd’hui :

Eden propose des builds officiels multi-plateformes, avec l’idée de rapprocher l’expérience entre PC et mobile.
L’équipe de développement publie régulièrement des correctifs et met l’accent sur une communication transparente, là où d’autres forks restent plus flous.

---

Nouveautés majeures de la v0.0.3 (stable, 5 septembre 2025)

• Corrections Vulkan (stencil, semaphores, allocations mémoire), améliorations JIT et CMake : des gains sensibles sont constatés, par exemple sur Super Mario Odyssey tournant sur du matériel modeste comme la Steam Deck.
• Option de précision DMA séparée : améliore la compatibilité de certains titres, dont Ender Magnolia.
• Désactivation de la vérification NCA (optionnelle) : permet d’installer et de lancer des mises à jour de jeux qui restaient auparavant bloquées (SMO 1.4.x, Pokémon Écarlate/Violet 4.0.0).
• Améliorations UI et correctifs divers : ajustements de textes, dialogues et thèmes.
• Parité accrue entre plateformes : avancées notables pour Solaris, FreeBSD/OpenBSD, et macOS (encore expérimental).

Points connus / limitations

• Les firmwares 20+ ne sont pas encore pris en charge. L’avertissement a disparu dans la liste des jeux, mais le menu HOME bloque toujours si un firmware trop récent est utilisé.
• Certaines mises à jour récentes de jeux restent instables.
   

v0.0.2-pre-alpha

• Paramètres par défaut revus pour des valeurs plus adaptées.
• Avertissement ajouté pour les migrations depuis Citron.
• Corrections de crashs liés à Qlaunch.
• Suppression expérimentale du support firmware 20.0.0+.
   
• Android :
  - Corrections du backend shader.
  - Changements de noms selon chipset.
  - Compatibilité avec certaines “gaming hub apps”.
  - Amélioration des traductions et de la clarté des textes.
  - Correction des écrans noirs (ouverture réglages / sortie appli).
  - Correction du bouton retour matériel.
   
• Desktop/Linux :
  - Améliorations des processus de migration de données.
  - Messages d’alerte pour migrations Citron.
  - Ajustements UI et AppImage.
  
   
• v0.0.1-pre-alpha---
  
  Plateformes, téléchargement et disponibilité :---
  
  Configuration conseillée :
  • Ajout du support Extended Dynamic State.
  • Extensions Vulkan supplémentaires.
  • Passage à Qt6 pour l’interface.
  • Corrections liées au firmware 19.0.1.
  • Possibilité de sauvegarder une speed limit par jeu.
  • Corrections de crashs FMV (vidéos).
     
  • Android :
    - Nouvel onglet de configuration "Eden’s Veil".
    - Amélioration des superpositions (overlays).
    - Optimisations d’interface utilisateur.
    - Portage de fonctionnalités PC vers Android.
    - Expérimentation LAN front-end.
  • Windows : archives ZIP “in-place” (x64). Un build ARM64 est en préparation.
  • Linux : AppImage générique, avec variantes optimisées pour Steam Deck et ROG Ally X.
  • Android : trois APK proposés (Standard, Optimisé, Legacy) publiés avec la v0.0.3.
  • Google Play Store : fiche officielle disponible, mise à jour le 12 septembre 2025.
  • CPU : x86-64 avec FMA ou ARM64-v8a ; 6 threads ou plus recommandés.
  • GPU : support OpenGL 4.6 ou Vulkan 1.1 minimum.
  • Android : Snapdragon 865 ou équivalent en entrée de gamme ; les SoC récents type Snapdragon 8 Gen 3 offrent une bien meilleure expérience.

Lien de téléchargement : https://github.com/e...leases/releases