Un moteur modulaire de rendu et d'interface terminal — widgets dynamiques, animations fluides, langage .widg
01 / Présentation
Terminal-Renderer est une bibliothèque C++ visant à fournir une infrastructure complète de rendu et d'interaction dans le terminal — widgets textuels dynamiques, animations fluides, langage XML propriétaire, sans dépendances graphiques externes.
Tous les objets sont hiérarchisés selon du polymorphisme partant de trObject, avec la recréation de weak pointers custom pour une gestion mémoire précise et sans dépendance externe.
L'objectif de performance est constant : faire tourner le moteur même sur un grille-pain. Chaque optimisation compte.
Rafraîchissement partiel des zones modifiées — aucun redessin complet inutile. Pipeline optimisé pour tourner même sur matériel limité.
Animations et transitions synchronisées indépendamment du framerate. Déplacements fluides et effets de surbrillance dynamiques.
Format XML propriétaire pour décrire, charger et prévisualiser des widgets en live sans recompilation.
Détecte automatiquement les classes héritant de trActor et insère les macros REGISTER_TYPE sans intervention manuelle.
02 / Architecture
trPair, trMulti, trMap…hide/show)03 / Langage .widg
Chaque widget peut être décrit via un fichier .widg utilisant un XML personnalisé avec des balises avancées. Ces balises permettent de définir les propriétés, la position, le contenu et les couleurs d'un widget.
L'un des atouts majeurs du format : la modification en direct. En appuyant sur F5/F6/F8/F9/F10 dans l'aperçu, les changements effectués dans le fichier XML apparaissent immédiatement — sans recompiler.
Ouvrir et visualiser n'importe quel fichier .widg seul avec toutes ses animations et couleurs, en isolation complète.
Modifier le XML et voir les changements instantanément — idéal pour les widgets animés complexes.
Chaque widget trText supporte des conteneurs d'animations avec frames horodatées et transitions automatiques.
| Élément XML | Attribut(s) | Type C++ | Description |
|---|---|---|---|
| trObject | type | trObject* | Définit le type de l'objet à créer via trObjectFactory |
| trObject | name | trActor* | Nom de l'objet (s'applique si c'est un acteur/pawn) |
| trPawn | — | trPawn* | Objet de type Pawn, utilisé pour la position et le type de position relative |
| Position | x, y | int | Position du pawn à l'écran en colonnes / lignes |
| RelativePositionType | RpType | enum | Ancrage relatif : TopLeft, MiddleCenter, BottomRight… |
| trWidget | — | trWidget* | Widget pouvant contenir du texte ou des couleurs |
| Size | height, width | int | Taille du widget en colonnes / lignes |
| Color | foreground, background | uint8_t R,G,B,A | Couleur globale du texte et/ou du fond du widget (#RRGGBBAA) |
| CaseColor | — | unordered_map | Définition de couleurs ANSI sur des intervalles de caractères — permet de colorier des portions distinctes du texte |
| Case | Start, End, foreground, background | int / uint8_t | Intervalle [Start, End] avec couleur fg/bg indépendante. Préfixer l'attribut par _ pour le désactiver (ex. _background) |
| Content | — | std::wstring | Contenu textuel du widget (peut être multi-lignes) |
| Line | Content | std::wstring | Ligne de texte normale (UTF-8) |
| LineRaw | Content | std::wstring | Ligne avec séquences d'échappement (\n, \t, \b…) |
| trText | — | trText* | Texte animé ou statique, supporte Animation, RawFrame et FrameAdd |
| Animation | — | vector<trPair> | Conteneur de frames animées horodatées |
| RawFrame | number, time | int | Frame brute avec durée en millisecondes — peut contenir Content + CaseColor |
| FrameAdd | number, time, onLastFrame | int / bool | Ajout de frame sur le texte existant ou en fin d'animation |
| OldContent | — | std::wstring | Texte existant avant ajout ou effacement |
| Add | position | int | Position où insérer du texte dans OldContent |
| Erase | Start, End | int | Supprime un intervalle de texte dans OldContent |
04 / Caractères spéciaux
Le moteur gère nativement un ensemble de séquences d'échappement et de caractères spéciaux. Chacun peut avoir des effets visuels imprévisibles selon le terminal cible — leur comportement est documenté et maîtrisé dans le pipeline de rendu.
La gestion de ces cas est particulièrement critique dans le mode RENDER_SYSTEM où tout le rendu passe par un buffer complet avant affichage — les séquences sont résolues en pré-affichage.
05 / Moteur de rendu
Chaque caractère écrit directement sur le terminal. Simple mais très lent — provoque lag et bugs visuels à grande échelle.
Tout est écrit dans un ostringstream tampon avant affichage. Fluide pour peu d'actions, instable avec de nombreux changements simultanés.
Buffer complet sans toucher directement au terminal. Le plus performant — gestion complète des positions, superpositions et modifications pré-affichage.
Le moteur supporte un système de couleurs ANSI complet — foreground, background, surbrillance, transitions dynamiques — sur tous les widgets.
Un précompilateur Python parcourt automatiquement les fichiers .h/.cpp pour détecter les classes héritant de trActor et insérer les macros REGISTER_TYPE sans intervention manuelle. Il évite les duplications et signale les erreurs de configuration.
Le système de collision entre widgets permet de récupérer les intersections et de définir les réactions souhaitées — overlap, rebond, masquage prioritaire.
06 / Roadmap
Détection des positions, clics et événements hover directement dans le terminal.
Effets sonores et notifications audio intégrés au moteur de widgets via AudioModule.
Simulation de fractales, jeu T-Rex, mini UI complète avec widgets interactifs.
Repo clé en main pour démarrer son propre projet Terminal-Renderer en quelques minutes.
Documentation interne complète Doxygen + Markdown détaillé pour chaque module et balise .widg.
Système de profilage mémoire et CPU intégré pour diagnostiquer les points chauds en production.
La vision long terme est de devenir un moteur complet de rendu console open-source, modulable et extensible — inspiré des architectures d'Unreal Engine mais conçu pour un environnement purement texte.
L'objectif de performance reste constant : faire tourner le moteur même sur un grille-pain. Chaque optimisation compte, chaque allocation est mesurée.
Le module ContentReorganisation() est en cours d'optimisation pour réduire les recalculs inutiles lors de mises à jour partielles du buffer.