Cette liseuse e-ink fait tourner la Game Boy à 60 FPS
Je vous parlais de ces écrans e-ink hier qui sont capables de se rafraichir beaucoup plus rapidement que les écrans tout pâle de nos liseuses. Et v'la ti pas que je tombe sur ce projet de Wenting Channel où le gars a décidé de faire tourner un Pokemon Bleu en 60 fps sur un écran e-ink.
Avant j'aurais pensé que c'était impossible mais avec un M5Stack PapierS3 qui est un petit kit de dev à base d'ESP32-S3 et d'un écran e-ink tactile de 4,7 pouces en 960×540, il est parvenu !
Maintenant, si vous voulez tester chez vous, le firmware est dispo directement via M5 Burner, l'outil de flashage de M5Stack. Vous flashez, vous chargez une ROM, et hop, vous avez une Game Boy dans la poche qui se lit même en plein cagnard.
Pour bien comprendre l'exploit, il faut comprendre comment fonctionne ce type d'écran à encre électronique. Les écrans e-ink sont lents par nature et chaque "pixel" qui le compose prend plusieurs centaines de millisecondes à se rafraichir grâce à des séquences de tensions (les waveforms) qui viennent modifier son état. Sauf que l'écran du PaperS3 dispose d'une interface parallèle ligne/colonne qui permet de piloter la dalle en contournant la méthode waveform classique
Wenting attaque donc les pixels directement, en pipeline, ce qui rend possible un rafraîchissement allant jusqu'à 60-70 FPS. Et surtout sur la GameBoy, il n'a pas besoin de traiter tout l'écran car c'est du 160×144 pixels, et il ne faut que trois pixels pour représenter les quatre nuances de gris d'origine. En triplant l'image tramée, il obtient alors un agrandissement pixel-perfect ×3 tout en ne calculant qu'une fraction de la dalle.
Pour l'émulation elle-même, il n'a pas réinventé la roue. Faire émuler une Game Boy par un microcontrôleur, ça a été fait mille fois. Il s'st contenté de tester les émulateurs PeanutGB, WanaCGB et Crankboy et a gardé ce dernier qui est le plus rapide. La Game Boy Color, par contre, on oublie puisque son CPU tourne deux fois plus vite et le PaperS3 n'a pas les reins pour ça.
Concernant le son, une Game Boy crache quatre canaux audio, deux ondes carrées, un canal d'échantillons et un canal de bruit. Le PaperS3, lui, n'a qu'un buzzer, capable de pondre une seule note à la fois. Game over ? Pas du tout. Wenting a simplement repris la même technique qu'on utilisait sur les vieux PC sans carte son grâce aux canaux de la carte pour simuler une polyphonie.
Ensuite, les contrôles c'est du joypad tactile à l'écran et il a même ajouté le support des manettes bluetooth (encore bien bien expérimental). Sans oublier la sauvegarde rapide qui fige l'état de la console à l'extinction, pour reprendre le jeu là où vous en étiez par la suite.
Notez aussi que le PaperS3 est déjà en fin de vie, remplacé par le PaperColor sorti en mai mais j'imagine que Wenting fera une upgrade à un moment... on verra bien.
Si le hacking de microcontrôleurs rétro vous parle, jetez un œil à cette mini-borne d'arcade qui tourne aussi sur ESP32 , ou à GB Recompiled qui traduit vos ROMs Game Boy en C natif .
Source : PC Gamer
WSL Containers - des conteneurs Linux sans Docker Desktop
Microsoft vient de lâcher un truc qui va faire plaisir à tous ceux qui bidouillent fort des conteneurs Linux depuis leur machine Windows. Ça s'appelle WSL Containers (WSLC pour les intimes, et pas WSL 3) et l'objectif c'est de faire tourner des conteneurs Linux nativement sous Windows sans avoir à passer par des outils tiers du genre Docker.
Pour en profiter, tapez la commande suivante :
wsl --update --pre-release
Cela mettra à jour votre WSL en version 2.9.3 ou supérieure et vous obtiendrez alors une toute nouvelle commande : wslc.
WSLC est un alias qui lance en réalité container.exe et qui permet de gérer tout le cycle de vie d'un conteneur Linux avec des commandes très classiques : run, stop, build, tag, push, pull, prune. Voici un vrai exemple tiré de la doc de Microsoft :
wslc run -d --name=webtop -e PUID=1000 -e PGID=1000 -e TZ=Etc/UTC -p 3000:3000 -p 3001:3001 lscr.io/linuxserver/webtop:ubuntu-kde
Ce qu'on lance là c'est bien une image en provenance de LinuxServer dont je vous ai déjà parlé, et comme vous pouvez le voir, vous ne serez pas dépaysé si vous connaissez déjà un peu Docker.
Et la cerise sur le gâteau, c'est le support GPU. Vous collez --gpus all sur un conteneur PyTorch et CUDA répond présent, sans config tordue. C'est énorme pour ceux qui font du dev IA localement sous Windows. Vous allez enfin pouvoir entrainer ou inférer dans un conteneur propre sans avoir à vous taper avec les drivers.
Microsoft pousse aussi des SDK (packages NuGet pour C, C++ et C#) histoire de piloter tout ça depuis vos applis si ça vous amuse.
Maintenant, vous vous interrogez sûrement sur les perfs de WSLC et c'est bien normal. De ce que j'ai lu, comme WSLC passe par VirtioFS pour son système de fichiers par défaut, les accès seraient 2 fois plus rapide. J'emploie le conditionnel car personne n'a encore réalisé de benchmark indé mais si ça se vérifie, ça va être énorme tant le partage de fichiers entre Windows et un conteneur Linux c'était la misère. Là vos builds vont respiiiiirer !!!
Et pour calmer les inquiets : Docker Desktop, Podman et Rancher Desktop ne disparaissent pas, rassurez-vous. Microsoft précise même que ces outils profiteront de changements de bas niveau apportés par WSLC. C'est donc une fondation, et absolument pas une déclaration de guerre.
C'est pour le moment dispo en public preview, donc attendez-vous à quelques bugs, et la mise à dispo pour tous, ce sera normalement pour cet automne. En tout cas, je suis content de voir cette évolution. Ça arrive pile au moment où Apple fait pareil de son côté , ce qui en dit long sur où va le vent. Donc, si vous aviez décroché de WSL, c'est peut-être le moment de remettre le nez dedans .
À tester sur une machine de dev, pas en prod, hein ! Et vous me direz si le VirtioFS tient ses promesses.
Un bateau à ballon à imprimer en 3D
Alors cette imprimante 3D ? Vous en êtes content ?
Non, ne me mentez pas ! Je sais que comme 90% des gens qui en ont une, elle prend grave la poussière !! Mais voici que voilà de quoi la remettre au boulot pour les vacances !
En effet, le designer jp.studio a partagé sur MakerWorld un petit modèle gratuit baptisé Balloon Boat, un bateau-jouet qui se propulse tout seul avec, tout simplement, un ballon de baudruche.
Le modèle Balloon Boat de jp.studio en cours d'impression
On gonfle le ballon, on le fixe à l'arrière du bateau, et l'air qui s'échappe en se dégonflant pousse la coque sur l'eau. Oui c'est vieux comme le monde mais c'est trop rigolo ! Les enfants vont adorer !
Les gens d'Adafruit l'ont imprimé pour leur série hebdo #3DThursday, sur Bambu X1C avec du PLA PolyMaker, et il faut compter à peine deux heures et une quarantaine de grammes de filament.
Par contre, s'il vous plait faites moi plaisir : Ne laissez jamais le ballon finir sa vie dans un ruisseau, un étang ou la mer. Un ballon en latex ou un bout de plastique coloré qui flotte, c'est un appât mortel pour un poisson, un oiseau ou une tortue marine. Ce plastique mettra des dizaines d'années à disparaître donc récupérez moi tout ça, séchez-le et rangez-le, vous le réutiliserez la prochaine fois et tout le monde sera content !
Ce modèle est en téléchargement libre sur la page MakerWorld de jp.studio. Et si vous cherchez d'autres idées pour votre imprimante, j'ai un top des sites où trouver des modèles 3D à imprimer, ainsi qu'un outil pour ajouter de la texture à vos impressions .
SB-mini-II - Il reconstruit un Apple II Plus de zéro
L'Apple II, ce vieux bouzin de 1977, n'a jamais eu le moindre secret pour personne. C'est d'autant plus vrai qu'Apple livrait carrément les schémas électronique de sa machine dans le manuel d'origine et à l'époque, des bouquins entier décortiquant chaque circuit étaient vendus dans le commerce.
C'était fou et ça a bien changé depuis ! Mais surtout c'est grâce à ça que Simon Boak s'est dit qu'il pouvait en refaire un de zéro !
Son projet s'appelle le SB-mini-II , et c'est un clone maison de l'Apple II Plus assemblé avec des puces qu'on trouve encore aujourd'hui. Le 65C02 (la version CMOS du fameux 6502) tourne à 1,024 MHz, à un cheveu de l'original qui carburait à 1,023 MHz et au lieu de la DRAM capricieuse d'époque, il lui a collé de la SRAM statique (48 Ko sur une puce et demie de 32 Ko, le surplus part à la poubelle, tant pis).
Et pour atteindre les 64 Ko complets, il enfiche à l'intérieur une carte Saturn 128K dans le slot 0, comme ça c'est réglé.
Mais le plus gros morceau, ça a été la vidéo. Boak a viré toute la "circuiterie" composite de l'Apple II, un vrai sac de nœuds bien connu des anciens, pour la remplacer par une carte Apple II VGA (un projet open source de markadev).
Celui lui a permis d'obtenir une image VGA bien nette sur un écran moderne. Autrement, sans cette carte, y'aurait rien eu à l'écran, malheureusmeent.
Et le clavier suit le même mouvement grâce à un Raspberry Pi Pico qui lui sert d'interface entre un clavier USB et la machine, en générant les mêmes signaux parallèles que le clavier ASCII d'origine. Bonus, Control + Print Screen redémarre le CPU comme aux temps jadis ! Et comme le Pico crache du 3,3V, il cause directement avec la logique 74HC en CMOS, sans le moindre convertisseur de niveau.
Côté fabrication, c'est son premier PCB en 4 couches, avec des plans internes dédiés à l'alimentation. Une entrée 12V passe par un régulateur Pololu pour sortir du 5V, et le tout rentre dans un boîtier imprimé en 3D, vaguement inspiré du vieux disque dur ProFile d'Apple. Les fichiers (schémas, nomenclature, CAO) sont sur GitHub sous licence MIT, si jamais vous voulez vous lancer.
Et ça tourne pour de vrai !! Boak a même posté une capture d'un vrai logiciel Apple II qui démarre dessus.
Je suis nul en soudure, mais si je savais souder, ça me donnerait envie de m'y coller, je pense. D'ailleurs, si le rétro vous chatouille, allez voir aussi ce malade qui fait tourner MS-DOS sur un Apple IIe , ou ce Pico qui émule un Z80 .
Bref, le SB-mini-II, c'est par ici, et c'est entièrement libre.
La fin de l'encoche ? Des chercheurs suisses ont créé un pixel qui voit et qui s'affiche
Depuis dix ans, toute l'industrie du smartphone se galère avec le même problème, à savoir caser la caméra frontale sans bouffer de la place sur l'écran, ce qui nous a valu la tristement célèbre encoche, puis le poinçon, puis ces capteurs cachés sous la dalle qui rendent les selfies un peu flous. Une équipe de l'ETH Zurich, la grande école polytechnique suisse, vient de proposer une sortie de route radicale en concevant un pixel unique qui sait à la fois émettre et capter la lumière.
L'écran lui-même deviendrait alors sa propre caméra, sans objectif rapporté, sans trou dans l'image.
Les travaux ont été publiés dans la revue Nature sous le titre "Fourier pixels for bidirectional light control", et ils sortent du laboratoire d'ingénierie des matériaux optiques dirigé par le professeur David Norris.
Le principe met un peu à mal une vieille évidence de l'électronique : jusqu'ici un pixel affichait et un capteur enregistrait, chacun sur son composant, sans jamais se mélanger.
L'astuce ici c'est le "pixel de Fourier", du nom de l'analyse mathématique qui décompose un signal en une somme d'ondes simples. Sur une mince couche de métal, la lumière entrante se mue en onde de surface, un plasmon, c'est-à-dire une vibration d'électrons qui court le long de la puce, avant d'être réémise sous forme lumineuse.
En jouant sur les interférences de ces ondes, un seul pixel parvient du coup à contrôler et à mesurer l'intensité, mais aussi la phase et la polarisation de la lumière, trois propriétés que nos écrans actuels ignorent.
Pour démontrer le truc, l'équipe de Yannik Glauser et Sander Vonk a gravé ses motifs à quelques nanomètres près et reconstitué un "E" d'environ un millimètre de haut, lu directement par le dispositif. Les chercheurs ont même façonné des faisceaux en forme de beignet, percés en leur centre, histoire de prouver leur maîtrise sur la forme de l'onde.
L'idée de fusionner émission et détection n'est pas tout à fait neuve en fait, des équipes américaines avaient déjà mis au point des nanobâtonnets capables d'afficher et de détecter, sauf qu'elles s'en tenaient à l'intensité. Là, c'est un pixel qui pilote le front d'onde entier, ce qui rend possibles des images bien plus fines qu'un simple capteur de luminosité.
Norris évoque déjà des écrans-caméras filmant et affichant en même temps, des hologrammes, de la communication par la lumière et jusqu'au calcul quantique. Vaste programme donc.
Sauf que bon attention quand même, on parle d'un unique pixel posé sur une paillasse, là où une dalle de smartphone en aligne plusieurs millions, et le chercheur reconnaît que l'étape suivante, les assembler en matrice, est loin d'être gagnée. Mais bon, au moins on avance !
Source : Nature , The Register
Alexandria - Vos ebooks en livres audio multi-voix, en local
Je ne suis pas très client des livres audio parce que mon cerveau, en général, part faire des trucs dans son coin et je me retrouve à rien écouter du tout. Je préfère un petit podcast où ça rigole qu'une œuvre littéraire qui demande de la concentration.
Mais je sais que vous appréciez beaucoup les livres audio et il arrive très souvent qu'un bouquin n'ait pas sa version audio. Un vieux roman qui n'est plus édité, un PDF technique, une fanfiction de 800 pages, un article de korben.info ou juste un truc que personne chez Audible ne prendra le temps d'enregistrer parce que ça n'intéresse que vous.
Mais youpi, Finrandojin, un internaute, en a eu marre d'attendre l'audiobook de ses rêves et a codé Alexandria, un générateur de livre audio qui tourne 100% en local sur votre ordi.
Vous balancez un fichier .txt, .md ou .epub, dans l'appli, puis un LLM découpe le texte et annote chaque ligne avec le personnage qui parle et la manière dont il le dit, puis le moteur Qwen3-TTS joue le tout en local comme une vraie troupe de doubleurs professionnels. Et le résultat est assez propre, même si ça ne vaut pas encore un vrai enregistrement fait par un vrai humain. M'enfin, faute de mieux, pourquoi pas !
Et surtout, ce LLM qui fait le découpage, vous le branchez où vous voulez. En local via LM Studio ou Ollama, ou dans le cloud avec OpenAI ou n'importe quelle API compatible. Ensuite, une fois le script annoté, Alexandria vous propose 9 voix pré-entraînées avec contrôle de l'émotion et du ton.
Vous pouvez aussi cloner une voix à partir de 5 à 15 secondes d'échantillon, ou carrément en fabriquer une à partir d'une simple description écrite. Vous tapez par exemple "Une voix masculine chaude et grave, au ton calme et posé" (c'est ma voix quoi...lol) et hop, il vous la fabrique.
La fonctionnalité de génération de personnas fait également gagner un temps de dingue puisqu'en un clic, le LLM analyse le bouquin, invente une description de voix pour chaque personnage, génère l'audio de référence et assigne tout automatiquement.
Et pour les obsédés du détail, il y a même un éditeur web où vous regénérez n'importe quelle ligne individuellement, du training LoRA pour vous fabriquer des voix persistantes, et un export en MP3 en pistes séparées pour bidouiller ça ensuite dans Audacity, ou en M4B chapitré qui rentre direct dans Audiobookshelf, Apple Books ou VLC. Et tout ça bien sûr, dans une dizaine de langues, français compris.
Alexandria exigera par contre une carte graphique avec 8 Go de VRAM au minimum, 16 et plus si vous voulez du débit correct. Et si vous êtes sur Mac, mauvaise nouvelle, l'accélération MPS d'Apple Silicon n'est pas encore supportée, donc ça tournera en mode CPU, donc ce sera lent. Mais c'est pas très grave, vous lancez la génération, et vous retournez lire d'autres articles sur mon site pour passer le temps.
Même galère aussi pour les gens qui ont de l'AMD sous Windows. Les chanceux par contre, ce sont les possesseurs de NVIDIA sous Windows ou Linux et les AMD sous Linux. Maintenant si vous tenez juste à faire parler votre Mac sans y passer trois heures par chapitre , vous serez mieux servi ailleurs qu'avec Alexandria.
Pour l'installation, le plus simple passe par Pinokio en deux clics, et si vous n'avez pas le GPU qui va bien, il y a un notebook Google Colab pour tourner sur un T4 gratuit dans le navigateur. Comptez quand même un téléchargement de 3,5 Go pour les modèles TTS à la première utilisation, ils ne sont pas inclus dans l'install.
Vous l'aurez compris, c'est du DIY un peu gourmand en GPU, mais pour tous vos ebooks à écouter qui n'auront jamais de narrateur, ça ouvre les perspectives ! Le code est sous licence MIT et je vous invite quand même à tester avec un chapitre avant de vous lancer dans un roman entier.
Un développeur a fait tourner Swift sur un Apple II de 1977
Swift, le langage maison qu'Apple a sorti en 2014 pour remplacer le vieillissant Objective-C, vient de débarquer sur une machine qui a quarante-neuf ans de plus que lui. Yeo Kheng Meng, un bidouilleur basé à Singapour, a restauré un Apple II Plus puis s'est demandé jusqu'où il pouvait pousser ce vieux tromblon, ce qui a donné SwiftII, un petit environnement Swift qui tourne aussi bien sur l'Apple II d'origine de 1977 que sur les IIe qui ont suivi.
Le défi donne le vertige quand on connaît la bête. L'Apple II carburait à un processeur 6502 cadencé à 1 MHz avec 4 Ko de mémoire à sa sortie, là où Swift a été pensé pour des machines des milliards de fois plus puissantes, et il a fallu pousser la RAM à 48 Ko pour espérer y faire tenir quoi que ce soit.
Plutôt que de traduire directement le code en instructions 6502, Yeo a repris une idée qu'Apple avait déjà eue en 1979 avec son Apple Pascal, qui consistait à compiler le programme en bytecode, c'est-à-dire un code intermédiaire générique, avant de l'exécuter dans une machine virtuelle, une sorte de processeur simulé en logiciel par-dessus le vrai. Presque un demi-siècle d'écart, et la même astuce pour contourner les limites du 6502.
Le pipeline reste volontairement minimaliste pour grappiller chaque octet, puisque le code source passe dans un analyseur, puis un parser qui crache directement le bytecode sans construire d'arbre intermédiaire, le tout avalé par une petite machine virtuelle à pile largement inspirée du livre Crafting Interpreters de Robert Nystrom.
Forcément, ce Swift-là est une version croupion. Il n'existe qu'un seul type de nombre, l'entier signé sur 16 bits, donc rien au-delà de -32 768 à 32 767, et surtout aucun nombre à virgule vu que le 6502 n'a pas de quoi calculer ça. Les chaînes de caractères sont du pur ASCII, les noms de variables plafonnent à onze caractères, et exit les closures, dictionnaires, gestion d'erreurs et autres async/await.
Côté ce qui marche quand même, on récupère les let et var avec inférence de type, les conditions, les boucles, les fonctions, les optionnels, les tableaux et même l'interpolation de chaînes, de quoi écrire de vrais petits programmes. Le projet embarque d'ailleurs un jeu de motos lumineuses et quelques démos graphiques qui tournent pour de bon sur le matériel d'époque.
La contrainte la plus délicate reste la mémoire, parce qu'une fois ProDOS chargé il ne reste qu'environ 40 000 octets pour votre programme, et comme le 6502 ne sait pas adresser davantage, il faut jongler avec des banques de mémoire commutées comme à la grande époque.
Le tout est écrit en C90, compilé avec cc65, et distribué en neuf images disque différentes selon les machines visées. Détail savoureux, Yeo a bouclé ce chantier en deux mois avec l'aide de Claude Opus 4.8 et de Codex, là où il estime que seul, ça lui aurait coûté deux à trois ans de travail.
Du coup, on a un langage de 2014 qui cause à une puce de 1977 grâce à une recette de 1979. C'est parfaitement inutile, et c'est exactement pour ça que c'est chouette.
Source : Hackaday
LinuxMD - du Linux sur la Sega Megadrive
Une Megadrive qui fait tourner du bon gros Linux qui tâche, vous en avez rêvé ? Hé bien Daniel Palmer l'a fait !!
Le souci, c'est que le processeur 68000 de la console n'a pas de MMU, ce petit composant que Linux réclame normalement pour gérer la mémoire. Du coup Daniel a compilé le kernel dans un mode spécial qui s'en passe, ce qui est déjà un joli exploit.
Autre problème, une Megadrive toute seule n'a pas assez de mémoire pour un kernel. L'astuce, c'est donc de passer par une cartouche. Un Mega EverDrive de chez Krikzz vient glisser 4 Mo de RAM dans la console, et hop, comme ça elle se transforme en mini-ordinateur le temps d'un boot. Welcome LinuxMD !!
Le menu de la cartouche Mega EverDrive, par lequel on lance le démarrage.
Vous branchez ensuite la cartouche à votre PC en USB, et là, le kernel se met à cracher du log sur votre terminal, comme une vraie machine !
Et il y a même un mode qui affiche le shell directement sur la télé, avec un petit carré vert qui clignote pour dire que le kernel tourne, et un rouge pour l'activité du disque. Plutôt classe !
Le shell Linux affiché sur la télé via la puce graphique de la Megadrive. Le carré vert qui clignote = le kernel tourne.
Après c'est lent. Daniel le dit lui-même, y'a de quoi vous faire un café entre deux commandes. Et si vous n'avez pas de Megadrive sous la main parce que les brocantes de geeks c'est pas votre truc, c'est pas grave, il a prévu un émulateur pour jouer avec sans avoir le matos.
Bref, c'est pas très praticable, vous ne pourrez pas vous en servir comme d'un PC au quotidien mais c'est beau quand même !
Source : Hackaday
True First Person Camera 2.0 - Votre vrai corps en vue FPS sur Cyberpunk
Alors oui, je sais, Cyberpunk 2077 vous montre déjà votre corps quand vous baissez les yeux en plein Night City, jambes comprises. C'est d'ailleurs suffisamment rare en vue FPS pour être souligné.
Sauf que cette caméra à la première personne reste raide comme un piquet. La tête de votre personnage ne tourne pas toute seule, les reflets sont absents, les armes passent à travers le décor et la moto ne se penche jamais dans les virages. Ce sont tous ces petits détails qui chiffonnaient DigitalVixen depuis des années, et après plusieurs réécritures complètes, ce moddeur vient enfin de sortir True First Person Camera 2.0 sur Nexus Mods pour rendre cette vue à la première personne beaucoup plus réaliste.
Le principe utilisé par son mod, c'est de reconstruire entièrement la caméra FPS du jeu. Vous réglez la hauteur et la profondeur de la vue pour la poser exactement où vous voulez, et si vous jouez avec le ray tracing ou le path tracing + les reflets de joueur activés, votre tête apparaît enfin dans les miroirs et les vitres, ce que le jeu de base ne fait pas. Et surtout le mod sait doser automatiquement quand vous dégainez une arme ou quand vous regardez trop vers le bas, histoire d'éviter ce clipping cauchemardesque où vous voyez l'intérieur de votre propre mâchoire.
Et ça ne s'arrête pas au corps. Il y a un mode head look qui laisse votre tête tourner toute seule pendant que vous marchez, un système IK qui replace correctement vos armes par rapport à la nouvelle position de caméra, une cam de rechargement qui incline légèrement la vue façon ciné, et une animation de première prise en main pour bien admirer vos Mantis Blades la première fois que vous les sortez. Et sur la moto, la caméra se penche dans les virages quand vous allez à fond, et en bagnole vous avez de l'inertie qui fait tanguer la vue au freinage.
Et ces profils de caméra sont réglables par véhicule et sauvegardés en JSON. Cela vous permet donc de peaufiner les sensations, caisse par caisse.
Et la grosse nouveauté de cette v2.0 c'est surtout la configuration in-game qui permet de paramétrer des raccourcis directement pendant le jeu. Suffit de mettre en pause et vous pouvez régler chaque valeur du mod comme bon vous semble. Plus besoin de quitter le jeu donc comme c'était le cas avant.
L'autre bonne idée de DigitalVixen, ça a été aussi d'exposer tous les effets de caméra (le shake, le battement de cœur quand vous êtes à l'agonie, la vue bourrée, le tremblement de froid) au travers de l'API que n'importe quel autre mod peut piloter.
Cela veut dire que si vous branchez une météo ou un mode drogue, vous pouvez faire trembler votre caméra, en réglant évidemment tous les curseurs d'intensité comme bon vous semble. C'est cool hein ?
Certains joueurs ont fait remarquer que pencher la tête fait aussi pencher tout l'horizon du jeu et que du coup, c'était un non-sens optique parce que dans la vraie vie, ça ne fait pas ça. Mais rassurez-vous, comme tout se paramètre, ça peut se régler.
Si ça vous dit de tester ce mod sur votre install de Cyberpunk, c'est dispo sur Nexus Mods . Vous devrez juste installer une palanquée de dépendances.
C'est quand même très cool de voir que + de 5 ans après sa sortie chaotique, Cyberpunk continue de vivre aussi grâce aux moddeurs. Et si vous voulez voir d'autres trucs nés autour du jeu, allez mater la veste à écran de Cyberpunk ou le film monté par un fan .
Modos Flow - L'écran e-ink open source qui pousse le refresh à fond
Wenting Zhang, le développeur derrière Modos Labs, s'est attaqué depuis des années à un truc qui faisait rire tout le monde, jusqu'à ce qu'il y parvienne. Son but dans la vie c'était de faire tourner un écran e-ink assez vite pour s'en servir comme écran de PC. Un vrai moniteur, branché en USB-C, sur lequel vous codez, écrivez et naviguez.
Son projet est open source, s'appelle Glider , et le produit grand public qui en découle, le Modos Flow, est actuellement en pleine campagne de crowdfunding avec la promesse folle de pousser le refresh rate de l'encre électronique bien au-delà du standard.
Le Glider, c'est un design matériel ouvert : PCB dessiné sous KiCad, un FPGA Xilinx Spartan-6 qui fait tourner Caster (le contrôleur e-ink maison, lui aussi open source), de la DDR3 pour le framebuffer, et des entrées USB-C DisplayPort Alt-Mode + DVI. Vous le branchez sur Mac, Windows ou Linux, et il affiche vos trucs comme un écran tout à fait normal.
Une latence de traitement annoncée sous les 20 microsecondes, du dithering matériel pour gratter des niveaux de gris, et un rail d'alim à ±15 V pour faire bouger les particules assez vite sur les grandes dalles.
Parce que le gros du travail, c'est bien de forcer l'e-ink à aller plus vite que ce pour quoi il est fait. Les écrans à encre électronique, c'est en général de l'ordre de 150 ms de temps de réponse contre 10 ms pour un LCD, et un contraste de 17:1 contre 1000:1. Mais côté Modos Flow, on est dans du 60 Hz, ce qui est déjà incroyable en soi.
Et le vrai intérêt de tout ça, c'est que pour la lecture, l'écriture, le code, vous n'avez pas besoin de 10 ms de réponse. Vous avez besoin d'un écran qui ne vous crève pas les yeux au bout de huit heures. Et sur ce terrain-là, l'e-ink reste imbattable : pas de rétroéclairage, ça ne scintille pas, c'est lisible en plein soleil... Bref, c'est que du bonheur. Le Modos Flow dispose même du tactile, d'un stylet, ainsi que d'un éclairage frontal, un support VESA, et différents modes d'affichage suivant ce que vous faites. Bref, c'est l'écran idéal pour celles et ceux qui, comme moi, passent leur vie dans du texte, à écrire, coder, dévorer des docs.
Côté tarif, le Modos Flow démarre à 619 $ sur Crowd Supply , et la campagne est déjà largement financée, plus de 540 000 $ récoltés pour 175 000 espérés, soit 308 %, avec une clôture prévue le 9 juillet 2026. Reste que c'est du crowdfunding, avec tout ce que ça implique de délais glissants et d'objectifs qui partent parfois en vrille. Mais si l'idée d'un écran reposant vous tente, c'est le moment de regarder ça de près.
En plus, le hardware, lui, reste ouvert alors c'est tout à fait possible de vous lancer de votre côté avec un FPGA et un fer à souder, et les plans du Glider dispos sur GitHub. C'est aussi ouvert que cette app de lecture libre dont je parlais il y a quelques jours.
On parlait déjà d' ebooks capables de lire de la vidéo il y a plus de dix ans, et l' e-ink couleur peine encore à percer mais là, j'avoue que Modos pousse le bouchon plus loin que personne. À voir maintenant si le Flow tient ses promesses à la livraison.
Merci à Maitretofu pour le lien.