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.
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.
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.
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
« 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.
Randal Linden est le développeur qui avait réussi l'exploit de faire tourner DOOM sur la Super Nintendo en 1995. Trente ans plus tard, il s’est associé à Limited Run Games pour ressortir une version améliorée sur cartouche, avec un processeur Raspberry Pi caché à l'intérieur.
Dans un long échange accordé à Kotaku, il revient sur ce projet un peu fou et sur les coulisses techniques du portage.
À l'époque, Linden bossait chez Sculptured Software, un studio basé à Salt Lake City. L'idée de départ était assez artisanale : acheter des cartouches Star Fox en magasin, les ouvrir, et remplacer la ROM par de la RAM pour tester les capacités de la puce Super FX. Le prototype a suffisamment impressionné ses supérieurs pour qu'ils aillent le présenter directement à id Software au Texas. Le feu vert a suivi.
Le portage de 1995, c'était un moteur entièrement reconstruit de zéro, sans une seule ligne de code d'id Software. Linden avait créé son propre assembleur, son propre linker et son propre débogueur. Mais les contraintes hardware de la SNES avaient imposé des sacrifices : un framerate poussif, pas de textures au sol et au plafond, des niveaux modifiés, et le quatrième épisode supprimé.
Quand Audi Sorlie, de Limited Run Games, lui a posé la question de savoir s'il referait les choses différemment, Linden a répondu qu'il avait « plein d'idées » mais que personne ne lui avait jamais demandé d'y retoucher. Jusqu'à maintenant.
La solution technique est plutôt marrante. La cartouche embarque un Raspberry Pi RP2350 qui émule le processeur Super FX. Comme l'explique Linden à Kotaku, « la Super Nintendo ne sait pas qu'elle ne parle pas à un vrai Super FX ».
Le code est quasiment identique à ce qu'il écrirait pour la puce d'origine, mais avec des performances largement supérieures.
Le résultat : circle strafing, framerate amélioré, support du rumble, et les quatre épisodes complets enfin disponibles sur SNES. Linden admet aussi avoir dû reverse-engineerer son propre code vieux de trente ans. « C'était assez compliqué, une partie du code. Je me suis dit : wow, j'étais vraiment intelligent à l'époque. »
Côté droits, il fallait quand même convaincre Bethesda, propriétaire de la licence DOOM. Selon Sorlie, la réaction initiale a été plutôt incrédule : « Vous voulez retourner développer pour la Super Nintendo ? Genre, pour de vrai ? »
Mais le retour de Linden sur le projet et les premiers prototypes ont suffi à convaincre. « Ils étaient aussi enthousiastes que nous. »
C'est le genre d'histoire qui rappelle que derrière les jeux vidéo, il y a parfois des parcours assez improbables. Linden n'avait pas pu appeler id Software pour pitcher son idée en 1995, il avait dû bricoler un prototype avec des cartouches Star Fox achetées en magasin, et trente ans plus tard il se retrouve à relire du code assembleur qu'il ne comprend plus lui-même.
Le projet a un côté un peu absurde, mais c'est aussi ce qui le rend attachant. Reste à voir si les fans de retrogaming seront au rendez-vous, mais vu que l'édition collector limitée à 666 exemplaires s'est déjà envolée, on a un début de réponse.
Source : Kotaku
Rosamund Pike revient avec franchise sur une expérience cinématographique qu’elle qualifie aujourd’hui de désastreuse. L’interprète de Miranda Frost dans Die Another Day a récemment confié, lors d’une interview pour le podcast How to Fail d’Elizabeth Day, que le long-métrage Doom, sorti en 2005, aurait pu mettre un terme définitif à sa trajectoire professionnelle. Cette adaptation ... Lire plus
L'article Rosamund Pike : le film Doom a failli anéantir sa carrière, selon l’actrice est apparu en premier sur Fredzone.
Connexion