tikilou

Et oui à un moment faut que ça s'arrête les projets passions... Bonne continuation à lui pour la suite et merci pour tout son travail open-sources, je ne sais pas qui va être capable de reprendre ses travaux vu le niveau de malade qu'il a, ils ne sont pas nombreux les développeurs ayant autant de talents que lui et surtout ayant cette volonté de partage, on verra bien.

Si seulement les gens qui profitent du boulot des gens comme lui étaient prêts ne serait ce qu'à donner 1€/mois, il y aura des talents qui pourraient faire de cette passion leur travail, ce qui poserait moins de questionnements.

Bel outil, ils ont bien du se casser le cul pour faire ça, bravo à eux et merci pour la new.

C'est moi qui ait bossé dessus, le dépôt github est à mon pseudo

2. Normalisation des ressources (qualité musée)
Graphismes (pixel-perfect) ?
 

ce programme utilise donc des dépendances spécifiques à debian trixie
Et oui...un AppImage englobe l'application pour fonctionner sur toute distribution linux

Merci Tikilou pour la news 

La normalisation des ressources "qualitée musée" consiste à pouvoir conserver et pérenniser les fichiers sources (généralement le contenu des *.app dans le dossier "titles") dans un format standard. 
Pixel perfect signifie que la conversion est 100% identique au rendu d'origine au pixel près. Nombre d'images/sprites dépendent d'une palletisation, Nintendo joue beaucoup avec ça depuis la Nes par économie de ressources.
En la matière, après extraction des assets, j'ai pu voir qu'ils sont à fond dans l'optimisation, même les coins de la grille des chaînes, sont en fait non pas une grille unique, mais la répétition de la même texture bien placée 4 fois différemment pour chaque coin.
Tout est tourné vers l'optimisation et l'économie de mémoire pour des performances maximales.

Et concernant l'AppImage, pour faire clair, je l'ai construite sur Debian 13 Trixie, donc compilé depuis la version de Rust fournie par ladite distribution.

Ceci dit, autant je sais qu'executer des appimage est compliqué sur d'anciennes distributions quand c'est du C/c++ parce que chaque nouvelle version du compilateur gcc supporte les précédentes librairies MAIS que les anciennes librairies ne peuvent pas prendre en charge les binaires compilés avec une version plus récente, autant pour le Rust, je ne sais pas. Je doute que ça puisse tourner sur d'anciennes versions d'ubuntu, debian, fedora, mais je n'ai pas testé.
Mais à minima, ça fonctionnera normalement sur toutes les distributions récentes à jour, et le suivantes.

Hello
Le lien de l'app image est cassé

Merci pour la news

Le lien est réparé. Pensez à clique sur le petit icône de téléchargement sur github, tout à droite.  
 

Tikilou, je te laisse la remettre en forme ?

Tikilou, je te laisse la remettre en forme ?

Les liens sont tout en bas, avec le dépôt Github et l'AppImage à télécharger !

Il n'y a pas de capture d'écran en tant que tel, c'est un outil sans interface graphique, prévu pour le terminal, utilisable aussi sans interface graphique ou appelé depuis un script/outil tiers.
Si lancé depuis le terminal, on voit juste défiler l'extraction des fichiers, si on le lance sans terminal, tout le contenu du dossier où est présent l'appimage, est extrait.

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.

Oui ça on le savait. Depuis le temps que les bidouilleurs font mumuse avec la console on n'a absolument rien vu de concret.
L'époque où une simple puce suffisait pour jouer à tous les jeux gravés est finie depuis longtemps.
Sony a mis le paquet et je ne parle pas de Nintendo avec sa switch 2.

Pas grave. Valve nous offre tout ça sur un plateau. SteamOS étant basé sur Linux, il est très facile de lancer n'importe quel homebrew/émulateur sur SteamDeck et Steam Machine, et même les copies de jeux fonctionnent pour ceux qui veulent tester avant d'acheter (ou une promo), via "Heroic"...
Pas besoin de puce, un peu de bidouille logicielle comme on peut parfois le faire sur consoles (c'est juste différent), et ça roule.

Pour moi, en ce qui concerne tous les bidouilleurs que nous sommes, les consoles de jeu n'ont plus d'intérêt, face à une plateforme optimisée comme une console, ouverte, et basée sur un système ouvert, Valve ayant rendu l'impossible possible.

L'argument du prix pouvait aller à l'avantage des consoles avant à la limite, mais désormais elles sont aussi chères qu'un PC...

En plus la Rog Ally a de bien meilleures performances sous Linux : https://korben.info/...erformance.html

Donc bon...

Je ne trouve pas ça “cher” pour une machine FPGA open-source qui refait une PS1 au niveau matériel. Un FPGA, ce n’est pas un mini-PC qui émule : tu retrouves la latence au plancher, des timings fidèles (bus, IRQ, DMA), une compatibilité profonde avec les comportements d’époque, et des sorties vidéo propres (idéal CRT/HDMI) sans dépendre d’un OS capricieux.

L’intérêt, c’est aussi la pérennité : appareil dédié, ouvert, qui progresse avec les cœurs. Et comme c’est annoncé compatible MiSTer, on ne parle pas d’un boîtier “PS1 only”, mais d’une plateforme qui peut accueillir d’autres systèmes (8/16-bit, micros, arcade… selon maturité des cœurs).

Côté prix, il faut être honnête : un bon FPGA + petites séries + R&D, tests, châssis et I/O, ça coûte. On ne paie pas juste du plastique, on paie la précision, la stabilité et l’évolutivité. Les boîtiers d’émulation logicielle, c’est très bien pour le confort/rapport prix, mais ici le but est différent : retrouver le comportement de la machine d’origine, proprement, pour longtemps.

Et si, en plus, il y a la patte de Taki Udon derrière, on sait que l’exécution et le suivi seront au rendez-vous. Bref : pour qui connaît le potentiel des FPGA, le tarif est cohérent — et l’objet a du sens pour la préservation comme pour le plaisir de jeu sans compromis.

Tu devrais nettoyer les "—" lors de la rédaction assistée par l'IA, ces derniers sont assez symptomatiques de GPT, qui n'utilise quasiment jamais des "-".

Franchement, on est combien à avoir lâché les consoles pour passer sur PC ?...

Pareil que toi. Je ne les supporte plus leurs pubs de merde... Facebook et insta pareil.... C'est pas un petit truc mais 3 pubs par vidéo....insupportable

Sur pc : Adguard + SponsorBlock sur firefox (sur chrome c'est mort, ils ont tout bridé), l'ensemble est toujours à jour, les tentatives de Youtube de bloquer sont contournées en moins d'une heure souvent, les listes étant mises à jour automatiquement.
Sur Smartphone et tablettes :  Youtube Revanced + MicroG

Avec ça, vous serez peinards. À vous les joies de retrouve un Youtube pré-2015

Bonjour, pour info cet amulateur est dispo sur le playstore pour le moment mais pas sur IOS

Et ça n'arrivera probablement jamais. iOS est une plateforme ultra fermée, à l'image d'Apple.

Désolé de le redire mais au lieu de s’attaquer à un jeu vidéo : en l’occurrence un anneau dans le nez d’une vache fictive modéliser en 3D (dans le jeu rien ne torture ou fait acte de cruauté sur la dite vache numérique) l’organisme ou Asso ferait mieux de s’occuper des vrai animaux qui sont maltraités physiquement dans les laboratoires….
Voilà c’est tout.

L'un n'empêche pas l'autre. Il n'y a pas qu'une seule personne chez PETA, loin de là.

Ce que certains font semblant de ne pas voir ici sous couvert de végéphobie, c'est qu'ici ils s'attaquent en fait à la cause en amont, la correction des comportements à la racine avant qu'une normalité ne sois ancrée dans les jeunes esprits.
N'importe qui ayant un tant soi peu travaillé sur lui même, ou élevé des enfants ici, sais et connaît la force du mimétisme social, et l'influence qu'elle a sur le développement et les automatismes, y compris ce qui doit être considéré normal ou pas.

Et ça, ça vaut pour n'importe quoi d'autre en relation avec les mauvais traitements et la cruauté, que ce soit sur les animaux ou non.

Qu'on le veuille ou non, les jeux-vidéos sont devenus des produits de masse faisant en partie l'éducation culturelle de tout un chacun, d'où la nécessité d'être un tant sois peu responsable sur la banalisation de certaines choses. La cruauté gratuite (sous couvert de rendre ça mignon), en est un exemple.

A peine sorti que les bidouilleurs sont dessus ! Bravo !

Et le plus beau, c'est que l'outil sera par extension, universel. S'il fonctionne sur switch, il fonctionnera aussi sur d'autres choses avec un port sd express. :-)

Certains ont tendance à oublier le trauma que Nintendo a subit avec le piratage de masse sur DS et 3DS... Il est clair qu'ils ne veulent pas retomber là-dedans...
Il y a quelques années, il aurait impensable que des logiciels et homebrews soient d'emblée fournis avec des clés privées, mais comme Nintendo ne réagissait pas, chacun s'est cru libre de faire ce que bon lui semble... Et bien non.
Voilà ce qui arrive lorsque l'on mélange les genre, la mise en avant du piratage n'a pas sa place au sein d'une communauté visant à déverrouiller une console pour y executer des homebrews.
Les générations précédentes qui ne passaient pas leur temps à vouloir se faire mousser, s'avaient qu'une part légale pouvait prendre la lumière, et que d'autres teams, en underground, prendre le relai, il y a avait un équilibre, que certains ont rompus en se croyant tout permis.
Il suffit de voir ce que logic-sunrise est devenu pour le comprendre, du temps de gx-mod et metagames, il aurait été impensable que des modérateurs laissent des gens ouvertement dire que ce qui les intéresse, ce sont des jeux gratuits. À l'époque l'on parlait tout au plus, de faire ses backups, des homebrews, et chez ceux qui pirataient, ils étaient malin, se couvraient.

Vous pensiez vraiment que dans le système légal, les violations de copyright affichées ouvertement allaient pouvoir continuer bon train ? Au final à force de mélanger les genre, tout va finir par se casser la gueule, il y a eu trop d'abus, ayant donné une bonne excuse que Nintendo attendait pour essayer de faire tomber plein de projets open-source et remettre en question l'émulation, au risque qu'un jour une décision de justice fasse jurisprudence et que ce qui avait été gagné lors du procès concernant Bleem, soit perdu, ou extrêmement limité !