Aller au contenu
Le Bien Heureux · Belgique
L’essentiel geek, le temps d’une pause.
Jeudi 8 octobre 2026 Édition du matin N° 43
Actualités · Après le souper · ≈ 3 min de lecture

Doom tourne maintenant dans une base de données SQL, et son auteur admet que c’est une mauvaise idée

SQLDoom fait tourner le Doom de 1993 dans une base de données : 1 300 lignes de SQL calculent chaque image, pixel par pixel. On peut même y jouer en ligne.

Écran de Doom avec, en bas, la requête SQL qui produit l'image et, à droite, des statistiques de performance
SQLDoom en action : sous l'image du jeu, la requête SQL qui la produit. © cedardb.com

Doom a déjà tourné sur des tests de grossesse, des tracteurs et des calculatrices. Il lui manquait le logiciel qui gère d’ordinaire les factures et les fiches clients. C’est fait : Lukas Vogel, ingénieur chez l’éditeur de bases de données CedarDB, a porté le jeu de 1993 entièrement en SQL, le langage qui sert à interroger des tableaux de données.

Un écran calculé par une requête

Le principe paraît absurde, et il l’est. L’état de la partie vit dans des tables : murs, monstres, munitions. À chaque image, une requête d’environ 1 300 lignes, découpée en 89 sous-requêtes enchaînées, calcule la couleur des 64 000 pixels d’un écran de 320 sur 200 et renvoie le tout sous forme d’un bloc d’octets.

Un petit script Python se contente de lire le clavier, de battre la mesure 35 fois par seconde et d’afficher l’image reçue. L’auteur s’est interdit de lui confier autre chose. Sur son ordinateur portable à processeur Ryzen 7 7840U, il annonce un affichage jusqu’à 60 images par seconde.

Les niveaux étaient déjà des tableaux

Vogel note un détail qui fait sourire les informaticiens : le format des niveaux de Doom est presque relationnel d’origine. Des sommets, reliés par des lignes, qui bordent des secteurs, qui contiennent des objets. Les verser dans une base a demandé un millier de lignes de Python, et l’import du premier Doom prend 18 secondes.

Il s’agit d’une récidive. En 2025, le même auteur avait publié DOOMQL, un jeu de tir affiché en caractères ASCII. Des lecteurs lui avaient fait remarquer que cela ressemblait plus à Wolfenstein 3D qu’à Doom. Il écrit n’avoir pas pu en rester là, et avoir profité, une fois encore, d’un congé parental.

« Évidemment une mauvaise idée »

La phrase est de lui : faire le rendu de Doom dans une base de données est « évidemment une mauvaise idée ». Il défend pourtant un point : pour le multijoueur, une base apporte gratuitement ce que les serveurs de jeu peinent à garantir, un état unique et cohérent. Pas de désaccord pour savoir si la roquette a touché.

Le billet est aussi une vitrine pour CedarDB, qui vend la base en question, et il ne s’en cache pas. On peut d’ailleurs y jouer en ligne, en match à mort à quatre, sur l’épisode gratuit du jeu. Quand toutes les places sont prises, il reste la file d’attente, d’où l’on peut interroger la partie en cours en SQL. Ars Technica, qui a essayé la démonstration, y a trouvé des performances médiocres.

Quelque part, un administrateur de bases de données vient d’obtenir une excuse recevable pour lancer Doom sur le serveur de production.

En bref

  • SQLDoom porte le Doom de 1993 en SQL : environ 1 300 lignes et 89 sous-requêtes calculent chaque image.
  • Python ne gère que le clavier, le rythme et l’affichage ; le jeu tourne à 35 cycles par seconde, l’affichage jusqu’à 60 images par seconde selon l’auteur.
  • Démonstration multijoueur en ligne ; le projet sert aussi de vitrine à l’éditeur CedarDB.

Sources : CedarDB, billet de Lukas Vogel ; Ars Technica (2 octobre 2026)