Table des matières

retroarch-web-games : Préparer un émulateur pour un serveur web statique

retroarch-web-games est une ancienne configuration conteneur autour de RetroArch web. Le dépôt réunit des fichiers d’exécution navigateur, des scripts et une image conteneur. Héberger le lecteur et fournir les jeux sont deux responsabilités distinctes.

Application et outils Archivé Docker

Mis à jour 2026-10-23
59
HTML · 46.67%
MIT

Code source README Markdown

Langages: 5Répartition du code
Composants documentés: 2Explorer les modules
Documents source: 1Lire les instructions

Langages du dépôtHTML 46.67%5

Parts calculées à partir des octets GitHub Linguist.

HTML46.67%

46.67%19 054 octets

JavaScript23.61%

23.61%9 638 octets

Python13.72%

13.72%5 600 octets

Shell11.62%

11.62%4 742 octets

Langage	%	Octets
HTML	46.67%	19 054
JavaScript	23.61%	9 638
Python	13.72%	5 600
Shell	11.62%	4 742
Dockerfile	4.38%	1 789

GitHub README Statistiques de langages

1. Aperçu

1.1. Pourquoi il existe

Émulateur RetroArch conteneurisé en WebAssembly exécutable dans tout navigateur moderne.

1.2. Cas d’usage

Émulation de jeux rétro dans le navigateur sans installation.

2. Cas d’utilisation

Image Docker qui héberge le lecteur web RetroArch derrière nginx, avec des dossiers de jeux récupérés à la construction.

Acteurs à gauche (personnes) et à droite (systèmes externes) ; chaque ovale est un cas d’utilisation appuyé par les fichiers cités ci-dessous.

Installer RetroArch web: Auto-hébergeurSources de fichiers
setup_retroarch.sh télécharge la version emscripten de la veille sur buildbot.libretro.com, l’extrait dans /var/www/html et décompresse le bundle du frontend.
Télécharger les jeux: Auto-hébergeurSources de fichiers
InternetArchive.py (typer, rich, requests) parcourt en parallèle les pages d’archives listées pour les fichiers .zip et .7z et les range sous downloads/<nom du système>.
Trier les jeux par lettre: Auto-hébergeur
sort_mkdir.sh déplace chaque fichier dans un sous-dossier 0-9 ou A-Z ; le Dockerfile l’exécute pour chaque dossier de système Nintendo.
Lancer le conteneur: Auto-hébergeur
docker-compose up -d construit l’image et relie le port 8080 à nginx ; entrypoint.sh régénère les listes .index-xhr avant de lancer nginx.
Jouer dans le navigateur: Joueur web
Le joueur ouvre http://localhost:8080, choisit un cœur et charge un jeu dans la page RetroArch Web Player fournie par la version nightly (le dépôt en garde une copie, index.html, que le Dockerfile ne copie pas).
Publier l’image multi-arch: Auto-hébergeur
.github/workflows/retroarch-web-games.yaml construit avec Docker Buildx pour amd64, arm64 et arm/v7 et pousse antoinebou12/retroarch-web-games sur Docker Hub.

2.1. Scénario : Héberger un lecteur rétro sur un serveur maison

Cloner le dépôt et prévoir la place pour une image d’environ 10 Go, comme le prévient le README.
Lancer docker-compose up -d ; la construction exécute setup_retroarch.sh, InternetArchive.py et sort_mkdir.sh.
Au démarrage du conteneur, entrypoint.sh indexe les cœurs et le bundle, puis nginx sert le site.
Ouvrir http://localhost:8080 et charger un jeu depuis les dossiers downloads triés.

Fichiers consultésREADME.mdDockerfiledocker-compose.ymlentrypoint.shsetup_retroarch.shInternetArchive.pyInternetArchive.shsort_mkdir.sh.github/workflows/retroarch-web-games.yaml

3. Démarrage

Ces commandes viennent de la documentation du dépôt. Elles n’ont pas été exécutées pendant cette revue.

README.md · Warning

docker-compose up -d

4. Références du dépôt

Extraits des guides du dépôt, dans leur langue d’origine. Les liens ouvrent la version du code consultée.

Prérequis et premier essai

4.1. Retroarch Web with Installed Games

README.md

This repository provides a self-hosted RetroArch web player with a collection of games for NES, SNES, Genesis, and Gameboy. Run the Docker image to quickly set up and host your own RetroArch web player and enjoy classic games on your browser.

Lire les instructions complètes ↗

Documentation source

README.md

1 documents lus parmi 1 candidats.

5. Fonctions et composants 2

Assemblage du conteneur: Le Dockerfile prépare l’environnement web et les éléments d’installation. entrypoint.sh pilote le démarrage du conteneur, tandis qu’index.html et libretro.js appartiennent au parcours navigateur.
Exécution et contenu: Le navigateur charge l’émulateur et ses ressources. Les jeux doivent correspondre au cœur et au format attendus. Les scripts de téléchargement constituent un parcours d’acquisition séparé de l’interface web.

6. Architecture

Ouvrez un composant pour suivre ses connexions, ou explorez le diagramme complet.

Composants du système Contexte

Compilation Docker
- Vers Fichiers du serveur statique
Fichiers du serveur statique
- Depuis Compilation Docker
- Vers Émulateur dans le navigateur
Émulateur dans le navigateur
- Depuis Fichiers du serveur statique
- Depuis Jeu fourni par l’utilisateur
Jeu fourni par l’utilisateur
- Vers Émulateur dans le navigateur

Mermaid Diagramme interactif

Vue générale des composants et des échanges vérifiés dans le dépôt.

Vue statique de l’architecture de retroarch-web-games — Aperçu statique. Le diagramme interactif le remplace après le chargement de Mermaid.

flowchart LR
  n0["Compilation Docker"]
  n1["Fichiers du serveur statique"]
  n2["Émulateur dans le navigateur"]
  n3["Jeu fourni par l’utilisateur"]
  n0 --> n1
  n1 --> n2
  n3 --> n2

Version texte du diagramme

Compilation Docker → Fichiers du serveur statique
Fichiers du serveur statique → Émulateur dans le navigateur
Jeu fourni par l’utilisateur → Émulateur dans le navigateur

Suivre un parcours dans le code

Lisez Dockerfile avec entrypoint.sh pour distinguer les téléchargements de compilation du service à l’exécution. Une image compilée peut encore manquer du cœur ou des ressources nécessaires au jeu choisi.

7. Dossier technique

Établi à partir du code au commit 71b41f9 (11 fichiers). Chaque élément vient d’une correspondance de motif dans le code: ouvrez le fichier lié avant de vous y fier.

7.1. Couches et modules

Les dossiers sont classés par couche selon leur nom, de l’interface utilisateur jusqu’à l’accès aux données. Comme le classement repose sur les noms seulement, le diagramme ne dit rien des appels entre couches.

Mermaid Vue en couches

flowchart TB
  subgraph L_presentation["Présentation"]
    direction TB
    presentation_0["(root)<br/>1 fichier"]
  end
  subgraph L_core["Source principale"]
    direction TB
    core_0["(root)<br/>6 fichiers"]
  end
  subgraph L_hosting["Build, CI et hébergement"]
    direction TB
    hosting_0["(root)<br/>2 fichiers"]
    hosting_1[".github<br/>2 fichiers"]
  end
  L_presentation ~~~ L_core
  L_core ~~~ L_hosting

Modules et couche principale
Module	Couche	Fichiers	Types	Extensions
`(root)`	Source principale	7	0	.sh .py .html

7.2. Modèle C4

Du contexte du système aux déclarations du code. Chaque niveau conserve les limites des sources disponibles.

UML 1 · Contexte du système

La vue C4 la plus large : qui utilise le projet et sur quels systèmes et stockages externes il s’appuie. Rendu avec uml-mcp.

Source PlantUML

@startuml
!include <C4/C4_Context>
LAYOUT_LEFT_RIGHT()
Person(P_cli, "Utilisateur CLI")
System(SYS, "retroarch-web-games", "retroarch-web-games est une ancienne configuration conteneur autour d…")
Rel(P_cli, SYS, "Utilise")
@enduml

UML 2 · Conteneurs

Un niveau plus près : les parties qui s’exécutent séparément dans le projet, leur langage principal et le chemin des appels entre elles. Rendu avec uml-mcp.

Source PlantUML

@startuml
!include <C4/C4_Container>
LAYOUT_LEFT_RIGHT()
Person(P_cli, "Utilisateur CLI")
System_Boundary(SYS, "retroarch-web-games") {
  Container(APP, "retroarch-web-games", "HTML")
}
Rel(P_cli, APP, "Utilise")
@enduml

UML 3 · Composants et couches

Modules regroupés par couche du code. Les limites indiquent l’organisation, sans affirmer une isolation à l’exécution ni des appels. Rendu avec uml-mcp.

Source PlantUML

@startuml
!include <C4/C4_Component>
LAYOUT_TOP_DOWN()
System_Boundary(SYS, "retroarch-web-games") {
Boundary(L0, "Présentation", "layer") {
Component(M0_0, "(root)", "HTML", "1 fichiers")
}
Boundary(L1, "Source principale", "layer") {
Component(M1_0, "(root)", ".sh, Python, JavaScript", "6 fichiers")
}
Boundary(L2, "Build, CI et hébergement", "layer") {
Component(M2_0, "(root)", "Dockerfile, .yml", "2 fichiers")
Component(M2_1, ".github", ".yml, .yaml", "2 fichiers")
}
}
@enduml

UML 4 · Code

Déclarations, champs et méthodes sélectionnés, regroupés par fichier source. Aucun héritage ni appel n’est déduit. Rendu avec uml-mcp.

Source PlantUML

@startuml
skinparam backgroundColor transparent
skinparam shadowing false
skinparam roundCorner 10
skinparam defaultFontName Arial
skinparam defaultFontSize 13
skinparam ArrowColor #4e6070
skinparam ArrowFontColor #3d4f5f
skinparam titleFontSize 14
skinparam actorBorderColor #006a62
skinparam actorBackgroundColor #e9f3f4
skinparam usecaseBorderColor #006a62
skinparam usecaseBackgroundColor #e9f3f4
skinparam componentBorderColor #006a62
skinparam componentBackgroundColor #e9f3f4
skinparam interfaceBorderColor #006a62
skinparam interfaceBackgroundColor #ffffff
skinparam nodeBorderColor #4e6070
skinparam nodeBackgroundColor #f4f8fb
skinparam databaseBorderColor #006a62
skinparam databaseBackgroundColor #ffffff
skinparam cloudBorderColor #4e6070
skinparam cloudBackgroundColor #f0f5fa
skinparam artifactBorderColor #006a62
skinparam artifactBackgroundColor #ffffff
skinparam rectangleBorderColor #b0c2d3
skinparam activityBorderColor #006a62
skinparam activityBackgroundColor #e9f3f4
skinparam partitionBorderColor #b0c2d3
skinparam stereotypeCBackgroundColor #ffffff
top to bottom direction
hide empty members
package "retroarch-web-games" {
object "libretro.js" as FN0 {
  cleanupStorage()
  idbfsInit()
  idbfsSyncComplete()
  appInitialized()
  preLoadingComplete()
  setupFileSystem()
}
object "InternetArchive.py" as FN1 {
  simplify_filename()
  download_file()
  download_files()
  download()
}
object "InternetArchive.sh" as FN2 {
  download_7z_files()
  download_zip_files()
}
}
@enduml

7.3. Interface publique

Du code extérieur peut utiliser tout ce qui est listé ici. Le projet déclare aussi 0 types publics.

Ligne de commande 1

download

7.4. Logique métier

Aucune classe n’a été extraite. Voici les plus gros fichiers source et leurs fonctions.

libretro.js: cleanupStorage, idbfsInit, idbfsSyncComplete, appInitialized, preLoadingComplete, setupFileSystem
InternetArchive.py: simplify_filename, download_file, download_files, download
setup_retroarch.sh: Aucune fonction nommée.
InternetArchive.sh: download_7z_files, download_zip_files
sort_mkdir.sh: Aucune fonction nommée.
entrypoint.sh: Aucune fonction nommée.

7.5. Base de données et persistance

7.6. Intégrations externes

Clients HTTP

requests

Hôtes nommés dans le code

archive.org 2 fichiers InternetArchive.py:86
myrient.erista.me 2 fichiers InternetArchive.py:104
buildbot.libretro.com 1 fichiers setup_retroarch.sh:16

7.7. Pipeline CI/CD

1 workflow GitHub Actions, 1 tâche. Chaque boîte est une tâche ; les boîtes à double bord publient ou déploient, et les flèches suivent les dépendances needs.

Mermaid Déroulement du pipeline

flowchart LR
  subgraph wf0["Build and Push RetroArch Web Games"]
    direction LR
    wf0_build_and_push[["build-and-push<br/>ubuntu-latest"]]
  end
  t0(["push · demande de fusion"])
  t0 --> wf0_build_and_push

Workflows, déclencheurs, tâches et cibles
Workflow	Déclencheurs	Tâches	Publie vers
Build and Push RetroArch Web Games `.github/workflows/retroarch-web-games.yaml`	push, demande de fusion	build-and-push `ubuntu-latest` Checkout repository · Setup QEMU and Docker Buildx · Setup Docker Buildx · Login to Docker Hub · Build and Push Docker Image	—

7.8. Déploiement

Mermaid Schéma de déploiement

flowchart LR
  repo[("Dépôt GitHub")]
  ci[["GitHub Actions<br/>1 workflow"]]
  image["Image Docker<br/>FROM debian:bullseye"]
  repo -->|"push ou demande de fusion"| ci
  ci -->|"docker build"| image

UML Déploiement

Le nœud extérieur est l’endroit où le code s’exécute. Chaque image de base pointe vers ce qu’elle construit, les flèches pleines mènent aux bases de données et les pointillées aux services externes. Rendu avec uml-mcp.

Source PlantUML

@startuml
skinparam backgroundColor transparent
skinparam shadowing false
skinparam roundCorner 10
skinparam defaultFontName Arial
skinparam defaultFontSize 13
skinparam ArrowColor #4e6070
skinparam ArrowFontColor #3d4f5f
skinparam titleFontSize 14
skinparam actorBorderColor #006a62
skinparam actorBackgroundColor #e9f3f4
skinparam usecaseBorderColor #006a62
skinparam usecaseBackgroundColor #e9f3f4
skinparam componentBorderColor #006a62
skinparam componentBackgroundColor #e9f3f4
skinparam interfaceBorderColor #006a62
skinparam interfaceBackgroundColor #ffffff
skinparam nodeBorderColor #4e6070
skinparam nodeBackgroundColor #f4f8fb
skinparam databaseBorderColor #006a62
skinparam databaseBackgroundColor #ffffff
skinparam cloudBorderColor #4e6070
skinparam cloudBackgroundColor #f0f5fa
skinparam artifactBorderColor #006a62
skinparam artifactBackgroundColor #ffffff
skinparam rectangleBorderColor #b0c2d3
skinparam activityBorderColor #006a62
skinparam activityBackgroundColor #e9f3f4
skinparam partitionBorderColor #b0c2d3
skinparam stereotypeCBackgroundColor #ffffff
node "Image Docker" as H {
  artifact "retroarch-web-games" as APP
}
artifact "FROM debian:bullseye" as IMG0
IMG0 ..> APP : construit
@enduml

Où il s’exécute

Images Docker de base

debian:bullseye

7.9. Sécurité

Chaîne d’approvisionnement

Mises à jour Renovate

Rien trouvé pour: Interface privée, Services, Entités, Stack et dépendances, Supervision, Tests automatisés.

8. Déploiement et exploitation

Les ports, le stockage et les relations de démarrage ci-dessous viennent de la configuration du dépôt. depends_on indique l’ordre de démarrage, pas la disponibilité du service.

9. Référence

8 / 8 fichiers admissibles lus (15 dans l’arbre); 0 trop volumineux, 0 échec de lecture et 0 diagnostic de syntaxe.

Ce que couvre l’analyse

Les dossiers connus de dépendances et de compilation, les fichiers d’identifiants et les binaires sont exclus. La collecte couvre les README, les manifestes reconnus et les fichiers source pris en charge.

Les statistiques Linguist couvrent l’ensemble du dépôt et peuvent inclure d’autres langages.

11. Fichiers à lire 3

12. Glossaire

Dépôt

Les fichiers source, la configuration et l’historique versionné d’un projet.

README

Le document d’entrée du dépôt, qui présente généralement son rôle et son installation.

Dépendance

Une bibliothèque, un outil ou un service nécessaire à la compilation ou à l’exécution d’un composant.

Conteneur

Un environnement de processus isolé créé à partir d’une image. Les données persistantes nécessitent un stockage hors de son système de fichiers temporaire.

Port publié

Un port de l’hôte associé au port d’un service dans un conteneur. Sa publication peut rendre le service accessible hors du réseau des conteneurs.

Interface en ligne de commande

Une interface textuelle où les commandes et arguments choisissent les opérations. Les codes de retour permettent aux scripts de détecter un succès ou un échec.

Compilation

Les étapes qui transforment les sources et dépendances en programme exécutable ou en livrable distribuable.

13. Références

antoinebou12. (2026, 5 novembre). retroarch-web-games. [Software repository] github.com.
antoinebou12. (2026, 5 novembre). retroarch-web-games: README. [Repository documentation] github.com.
antoinebou12. (2026, 5 novembre). Dockerfile. [Source file] github.com.
antoinebou12. (2026, 5 novembre). entrypoint.sh. [Source file] github.com.
antoinebou12. (2026, 5 novembre). index.html. [Source file] github.com.
Boucher, A. (2026, 23 octobre). retroarch-web-games : Préparer un émulateur pour un serveur web statique. [Project article] antoineboucher.info.
Boucher, A. (2024, 1 janvier). RetroArch Web Games. [Project article] antoineboucher.info.

Les sources sans date de publication indiquent la date de leur dernière vérification, le 5 novembre 2026. Les liens des fichiers conservent la révision inspectée lorsqu’elle est disponible.