Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

DOOM tourne aussi dans ChatGPT et Claude (évidemment)

Par : Korben ✨
29 avril 2026 à 09:31

DOOM a déjà été porté sur des thermostats, des tests de grossesse, et même un piano ! Manquait donc plus que les chatbots IA !

Et voilà que c'est fait puisque Chris Nager vient de faire tourner DOOM dans ChatGPT et Claude, jouable directement dans la fenêtre du chat.

Le truc tient en deux outils MCP. Pour rappel, MCP (Model Context Protocol), c'est le protocole standard qui permet à une IA d'appeler des outils externes.

Ici donc, create_doom_session lance le jeu inline dans l'application, et get_doom_launch_url renvoie une URL de fallback pour les clients qui ne savent pas afficher d'UI inline.

Sous le capot, c'est cloudflare/doom-wasm qui tourne, avec les assets libres de Freedoom Phase 1, le tout écrit en TypeScript et hébergé sur Netlify. Vous tapez "lance DOOM" dans Claude, ça démarre le rendu canvas directement dans la fenêtre de chat, et hop, les démons sont là !

Pour ceux qui débarquent, DOOM est sorti en décembre 1993, et le running gag "can it run DOOM?" remonte à la fin des années 90, quand id Software a libéré le code source du jeu en 1997. Et depuis 30 ans, DOOM tourne déjà sur tout un tas de matos comme des distributeurs de billets, des oscilloscopes, des frigos, ou même des satellites en orbite... la liste est sans fin !

Y'a même un type qui avait fait tourner DOOM avec du CSS dans un navigateur le mois dernier. Alors c'est sûr que ChatGPT et Claude étaient déjà sur la liste des prochaines cibles évidentes.

Alors pourquoi ça devient possible maintenant ? Hé bien parce que la spécification MCP Apps est passée en stable fin janvier. C'est donc l'extension du Model Context Protocol qui permet à un serveur MCP de retourner une UI interactive (HTML, canvas, dashboards) directement intégrée dans la conversation.

Tout ça est sandboxé dans une iframe, ça communique via postMessage, et c'est aussi supporté côté VS Code. On est totalement dans la lignée de ces outils MCP qu'on commence à voir partout.

Comme MCP donne déjà à l'app une zone d'affichage dans la conversation (une iframe hôte), le réflexe naturel, c'est d'y caler une page web qui contiendrait elle-même DOOM.

Sauf que ça fait deux fenêtres imbriquées qui se battent avec les règles de sécurité du navigateur (CSP, frame-src, tout ça). Du coup, Chris a eu une idée de génie et a viré la couche du milieu et posé l'écran du jeu directement dans la zone fournie par MCP. Une couche en moins, et tout marche nickel !

Côté limites, faut savoir que c'est une version vraiment épurée. Pas de sauvegarde ni de chargement de partie, pas de screenshots, pas d'état persistant entre les sessions. Tout ça a été coupé volontairement pour gagner en stabilité.

Pour tester chez vous, les amis, le code est dispo sur GitHub via la PR #54 du repo de Chris, prête à être ajoutée à votre config Claude Desktop ou ChatGPT. Y a de quoi s'amuser.

Bref, DOOM tourne désormais directement dans la fenêtre de chat de votre IA préférée. La question n'est plus "qu'est-ce qui peut faire tourner DOOM ?" mais "qu'est-ce qui ne le fait PAS encore ?".

Source : Chris Nager

Un développeur fait tourner Doom dans un navigateur, avec du CSS et rien d'autre

Par : Korben
31 mars 2026 à 08:24

Niels Leenheer a porté le mythique Doom de 1993 dans un navigateur web, mais sans WebGL ni Canvas. Tout le rendu 3D repose sur des div et des transformations CSS. Le résultat est jouable, open source, et un brin absurde. On adore.

Doom en div

Le principe est aussi fou qu'il en a l'air. Chaque mur, chaque sol, chaque tonneau et chaque ennemi est une balise div, positionnée dans l'espace 3D grâce aux transformations CSS. Le jeu lit les données du fichier WAD original de 1993, celui-là même qui contenait les niveaux du Doom d'id Software, et en extrait les coordonnées des murs, des secteurs et des textures.

La logique du jeu, elle, tourne en JavaScript. Mais côté affichage, c'est 100 % CSS : pas de Canvas, pas de WebGL, pas de bibliothèque graphique. Juste des div, des calculs trigonométriques en CSS et des propriétés personnalisées.

Pour simuler une caméra, le développeur a trouvé une astuce assez maline : plutôt que de déplacer le joueur dans la scène, c'est la scène entière qui bouge dans le sens inverse. Le CSS ne gère pas nativement la notion de caméra, du coup Leenheer a tout simplement inversé le problème.

Des fonctions CSS qu'on ne soupçonnait pas

Le projet exploite des fonctions CSS relativement récentes : hypot() pour le théorème de Pythagore, atan2() pour les angles de rotation, clip-path pour découper les sols en polygones complexes, et @property pour animer des propriétés personnalisées qui servent à gérer les portes, les ascenseurs et même la chute du joueur.

Les ennemis utilisent des spritesheets classiques avec un effet de billboard, c'est-à-dire qu'ils font toujours face à la caméra. Les effets de lumière passent par un filtre brightness sur chaque secteur, et le fameux ennemi invisible Spectre utilise un filtre SVG pour reproduire l'effet de distorsion du jeu original.

Leenheer a même ajouté un mode spectateur avec caméra libre, absent du Doom de 1993, et les calculs de positionnement de cette caméra reposent eux aussi sur les fonctions trigonométriques du CSS.

Les limites du CSS poussé à fond

Le jeu est jouable sur cssdoom.wtf, et le code source est disponible sur GitHub sous licence GPL 2. Par contre, les performances restent limitées. Sur Safari iOS, le jeu peut planter au bout de quelques minutes, et les gros niveaux font souffrir le navigateur.

Leenheer le reconnaît lui-même : le projet ne remplacera jamais WebGL ou WebGPU pour du rendu 3D sérieux. Le but était avant tout de montrer jusqu'où le CSS moderne peut aller, et sur ce point, la démonstration est plutôt convaincante.

C'est le genre de projet complètement absurde qui force le respect. Doom a déjà été porté sur à peu près tout ce qui contient un processeur, des calculatrices aux tests de grossesse, et voilà qu'il tourne maintenant dans une feuille de style.

L'air de rien, ça montre que le CSS de 2026 n'a plus grand-chose à voir avec celui qu'on utilisait pour centrer un div il y a dix ans.

Source : Huckster.io

DOOM over DNS - 2000 records TXT pour buter des démons

Par : Korben
24 mars 2026 à 08:57

« Can it run DOOM ? » Vous connaissez tous la question je pense. En effet, depuis 1993, le FPS d'id Software a tourné sur à peu près tout ce qui contient un processeur, des calculatrices aux écouteurs en passant par des tests de grossesse. Et là, Adam Rice vient de pousser le délire encore plus loin en stockant et en lançant le jeu entier... via des enregistrements DNS.

Oui, ce bon vieux protocole de plus de 40 ans, conçu à la base pour traduire des noms de domaine en adresses IP (RFC 1035, tout ça). En fait, la magie tient dans le fait que les enregistrements TXT n'ont aucune validation de contenu. Du coup, rien n'empêche d'y coller du texte arbitraire... genre un FPS complet converti en texte via base64. En gros, le DNS devient un stockage clé-valeur distribué mondialement et mis en cache un peu partout. Pas mal comme CDN du pauvre !

Le fichier WAD (les niveaux et assets du jeu, 4 Mo) passe à 1,7 Mo après compression, les DLLs du moteur de 4,4 Mo à 1,2 Mo, et le tout est découpé en 1 966 enregistrements TXT sur une seule zone CloudFlare Pro. Un record spécial contient également les métadonnées de réassemblage (nombre de chunks, hash de vérification).

Ensuite, côté joueur, un script PowerShell de 250 lignes résout les 2 000 requêtes, reconstruit le binaire en mémoire et hop, ça tourne. Les données du jeu ne touchent ainsi jamais le disque, puisque tout reste en mémoire. Le tout chargé en 10 à 20 secondes (PowerShell 7 requis) !

Le truc rigolo, c'est que l'auteur ne connaît pas le C#. C'est Claude (oui, encore cette fichue IA, ahaha) qui s'est tapé le portage en modifiant managed-doom, un port C# du moteur original, pour remplacer les lectures fichier par des flux mémoire et virer toutes les dépendances natives au profit d'appels Win32 directs. L'audio a été sacrifié pour réduire le nombre de records mais bon, on va pas chipoter. Après si vous voulez tester, sachez que ça ne fonctionne que sous Windows car ça repose sur PowerShell, donc pas de version Linux pour l'instant.

D'ailleurs, si le concept vous rappelle quelque chose, c'est normal. Planquer des données dans les enregistrements TXT, c'est en fait une technique bien connue en sécu. J'en parlais déjà avec DNSteal pour exfiltrer des fichiers via DNS , ou avec ces malwares carrément stockés dans les records DNS . Adam Rice le dit lui-même, son projet est parti de l'exploration de techniques d'implants (staging de shellcode via TXT records) sauf qu'au lieu de planquer un trojan, il y a planqué ce FPS de +33 ans. C'est quand même plus sympa !

À vrai dire, avant d'en arriver là, il a d'abord fait un proof of concept avec une image de canard (va savoir pourquoi). Encoder la photo en base64, découper en chunks, uploader via l'API CloudFlare, reconstruire de l'autre côté avec un hash identique et ça a marché du premier coup. Par contre pour la vidéo, oubliez, un MP4 de 1 Go ferait 670 000 enregistrements.

Voilà et tout ça pour 20 dollars par mois (le prix de la zone CloudFlare Pro). Donc si DOOM sur des écouteurs vous avait déjà fait sourire, attendez qu'un taré le fasse tourner avec que des paquets ICMP. Bah quoi ??

Bref, le code est dispo sur GitHub et le DNS a clairement pas fini de nous surprendre.

Source

❌
❌