DOOM'un her karesi bir SQL sorgusunun çıktısı: 89 CTE'lik boru hattı

Bu neden ilgi çekici? Çünkü SQL'i çoğumuz "veriyi süzen dil" diye biliriz: tabloyu sorgularsınız, satır döner. Üç boyutlu bir çizim hattının, canavar davranışlarının ve saniyede 35 kez dönen bir oyun döngüsünün aynı dille yazılabilmesi, bu tanımın ne kadar dar kaldığını gösteriyor.

WAD dosyası zaten bir veritabanıydı

Vogel'in çıkış noktası şu: doom.wad dosyası hâlihazırda fazlasıyla ilişkisel. Bir Doom haritası özünde numaralanmış köşe noktalarından, bu noktalar arasına çekilmiş çizgilerden, çizgilerin doku bilgisi taşıyan yüzlerinden, zemin ve tavan yüksekliğiyle tanımlı odalardan ve haritaya serpiştirilmiş nesnelerden oluşur. Bu liste, neredeyse birebir bir tablo şemasıdır.

Yaklaşık 1000 satırlık Python kodu WAD biçimini VERTEXES, LINEDEF, SIDEDEF, SECTOR ve THINGS tablolarına çeviriyor. Vogel, Doom 1'in tamamını içe aktarmanın dizüstü bilgisayarında yaklaşık 18 saniye sürdüğünü yazıyor. Bundan sonrası tamamen sorgu: yaklaşık 110 tablo ve 100'ün üzerinde fonksiyon.

Kare, 89 halkalı bir zincirin sonucu

Çizim hattı, yorum satırları hariç yaklaşık 1300 satır SQL ve 89 ortak tablo ifadesinden (CTE) oluşuyor. CTE, bir sorgunun içinde WITH anahtar kelimesiyle tanımladığınız ara sonuçtur; yalnızca o sorgu çalıştığı sürece var olan, adı olan geçici bir tablo gibi düşünebilirsiniz. 89 tanesini arka arkaya dizince ortaya bir işleme hattı çıkıyor: biri görünür duvar parçalarını üretiyor, biri zemin ve tavan yüzeylerini, biri hareketli nesneleri, sonuncusu pikselleri.

Hattın son adımı tek bir birleştirme işlemi: 64.000 piksel (320x200) satır ve sütun sırasına göre üst üste eklenip tek bir ikili değere paketleniyor. Python'un rolü burada başlayıp burada bitiyor — klavyeyi dinlemek, zamanlayıcıyı çevirmek, gelen bitmap'i ekrana basmak. Oyun mantığının tek satırı bile Python'da değil; o kısım yaklaşık 5900 satır SQL.

Bu mantığın ne kadar ileri gittiğini gösteren küçük bir ayrıntı: canavarların durum makinesi de tabloda duruyor. Vogel, bir canavarın canı kendi azami canının eksi değerinin altına düştüğünde durumunun "xdeath"e geçtiğini söyleyen tek bir CASE ifadesini örnek gösteriyor. Doom oynayanların bildiği o dağılarak yok olma animasyonu, SQL tarafında tek bir koşul.

Özyinelemesiz BSP: sıralama, ağaçta gezinmenin yerine geçiyor

İşin en öğretici kısmı burası. Doom'un çizim sırası BSP (ikili uzay bölmesi) ağacına dayanır: harita önceden yinelemeli biçimde ikiye ayrılarak dışbükey parçalara bölünür, sonra oyuncunun konumuna göre ağaçta gezilip yüzeyler doğru sırada çizilir. C'de bu klasik bir özyinelemeli iniştir; fonksiyon kendini çağırır, doğru sırayla ekrana yazar.

SQL'de "kendini çağır, sonra ekrana yaz" diye bir kalıp yok. Vogel bunun yerine ağaçtaki bütün yolları önceden hesaplayıp her yolu tek bir tam sayıya kodluyor: d derinliğindeki "arka" dal için (40 - d) numaralı bit 1, "ön" dal için 0. Böylece ağaçta gezmek yerine bu tam sayıya göre sıralamak yetiyor; ORDER BY, özyinelemeli inişin tamamının yerine geçiyor. 40 bitlik alan, orijinal oyunun en derin haritası olan E4M8 dahil 32 seviyeye kadar yetiyor.

Aynı çeviri her yerde tekrarlanıyor. Orijinal kodun her ekran sütunu için tuttuğu tavan ve zemin kırpma dizileri, sıralı pencere fonksiyonlarına dönüşüyor. Derinlik testi de tersinden çözülüyor: "bu pikselin üstüne yaz" demek yerine, her aday piksel için derinlik sabit noktalı sayıya çevrilip bir tam sayı anahtarın üst bitlerine paketleniyor, sonra piksel başına en küçük anahtar alınıyor. En küçük anahtar, en yakın yüzey demek.

Yani adım adım buyuran "şuraya yaz" mantığı, küme temelli "bütün adayları üret, sonra öndekini belirle" mantığına çevriliyor. SQLDoom'un asıl fikri, bu tercümenin kendisi.

Peki ne kadar hızlı?

Oyun döngüsü orijinaldeki gibi saniyede 35 tik çalışıyor; bu da her tike 28,6 milisaniyelik bir bütçe bırakıyor. Vogel'in AMD Ryzen 7 7840U işlemcili dizüstü bilgisayarında ölçtükleri şöyle:

Bu rakamların önemli bir kaydı var. CedarDB sorguları LLVM ile makine koduna derliyor; yani buradaki hız SQL'in kendisinden çok bu derleyicinin marifeti. Vogel'in karşılaştırmasına göre nesne hareketi için orijinal linux_doom'un C kodu 48 makine komutu üretirken SQLDoom'un derlenmiş SQL'i 117 komut üretiyor; aradaki 42 komut tablo yazmalarından geliyor. Sorguyu satır satır yorumlayan bir motorda aynı sayıları beklemek gerçekçi olmaz. Depo ayrıca CedarDB'ye özgü bir betik diline dayanıyor; Vogel bunun PostgreSQL'in plpgsql'ine kolayca taşınabileceğini söylüyor, ama bunu gösteren bağımsız bir çalışma yayımlanmış değil.

Çok oyunculu kısım kendiliğinden geldi

Dört kişilik mod, veritabanının zaten yaptığı işten doğuyor. Her tik bir işlem (transaction) içinde çalışıyor: başlat, tiki çalıştır, kesinleştir. Paylaşılan durumu tutarlı tutmak, eşzamanlı yazmaları sıraya dizmek ve herkese aynı gerçeği göstermek bir veritabanı yöneticisinin asıl mesleğidir. Çok oyunculu oyun yazarken en çok emek isteyen kısım tam da budur; burada hazır geliyor.

Oyuncuların doğrudan tabloya yazmasını engellemek için girdi tek bir fonksiyondan geçiriliyor. Fonksiyon SECURITY DEFINER olarak tanımlı, yani çağıranın değil sahibinin yetkisiyle çalışıyor; oyuncunun yetkisi yalnızca o fonksiyonu çağırmaya yetiyor.

SQL nasıl "her şeyi hesaplayabilen" bir dile dönüştü

Klasik SQL'de döngü yoktur. 1992 standardındaki dil esasen ilişkisel cebirin bir yazımıdır: süz, birleştir, grupla, sırala. Kümeyle ne yapılacağını söylersiniz, nasıl dolaşılacağını değil. Bu haliyle SQL, hesaplanabilir her şeyi hesaplayamaz.

Kırılma noktası SQL:1999 ile geldi: özyinelemeli CTE, yani WITH RECURSIVE. Kalıbı basit — bir başlangıç sorgusu (çapa), bir de kendi sonucuna bakan ikinci sorgu; ikisi UNION ALL ile birleştiriliyor ve yeni satır üretilmediği ana kadar tekrarlanıyor. SQL'e döngüyü getiren şey budur. Döngü, koşul ve sınırsız durum bir araya gelince dil Turing-tamlığına geçiyor.

Databricks mühendisleri, kendi motorlarına özyinelemeli CTE eklerken bunu açıkça yazdı. Pavle Martinović ve arkadaşlarının 21 Temmuz 2025 tarihli teknik yazısındaki ifade şu: "Görünüşte küçük olan bu özellik, SQL'in ifade gücünü önemli ölçüde artırıyor ve teorik olarak onu Turing-tam yapıyor; yani bir bilgisayarın yapabildiği her hesabı yapabilir."

Buradaki "teorik olarak" kaydını ciddiye almak gerekiyor. Gerçek motorlar bu döngüye çit çekiyor: aynı yazıya göre Databricks varsayılan olarak en fazla 100 seviye derinliğe ve bir milyon satıra izin veriyor, sınırı aşan sorgu durduruluyor. Dil teoride sınırsız, kurulumlar pratikte sınırlı.

İşin ilginç yanı, SQLDoom'un en etkileyici kısmının özyinelemeye borçlu olmaması. Vogel'in bir önceki projesi DOOMQL ışın izlemeyi özyinelemeli CTE ile yapıyordu; SQLDoom'da BSP ağacı bilerek özyinelemeden arındırılıp sıralamaya indirgendi. Çünkü veritabanları tek tek adım atmakta değil, büyük kümeleri toplu ve paralel işlemekte iyidir. Doom'u SQL'e taşımanın yolu, SQL'i başka bir programlama diline benzetmekten değil, problemi SQL'in kendi diline çevirmekten geçmiş.

"Ama Doom'u çalıştırabiliyor mu?"

Bu soru artık bir internet geleneği. id Software'in 1997'de kaynak kodu yayımlaması, oyunun taşınabilir C ile yazılmış olması, ayrı bir grafik kartı gerektirmemesi ve varlıklarının küçüklüğü Doom'u "her şeye taşınabilir" hale getirdi. Cockfield'ın Hackaday'de hatırlattığı gibi Doom, özel grafik donanımından önce yazıldı ve gerçekte üç boyutlu değil; bu da programcıları bir sürü kestirme yola zorladı. Tam da bu kestirme yollar, oyunu tuhaf ortamlara taşımayı mümkün kılıyor.

Kaynağı doğrulanabilen birkaç örnek:

• Hamilelik testi (2020). Belki de en çok paylaşılan örnek, aslında göründüğünden farklı. Foone, testin hem ekranını hem de mikrodenetleyicisini değiştirdiğini kendi sözleriyle anlatmıştı: "Burada ne yaptığımı netleştireyim: bu bir yedek ekran VE yedek mikrodenetleyici. Orijinal testten kabuğu dışında hiçbir şey kullanmıyorum." Ekran 128x32 piksel ve tek renk.
• PDF dosyası (2025). ading2210'un doompdf projesi, PDF biçiminin kendi JavaScript desteğini kullanıyor; oyun, Chromium ve Firefox'un PDF motorlarında çalışıyor. Görüntü, her piksel satırı için bir metin kutusu açılıp içi ASCII karakterlerle doldurularak çiziliyor. Sonuç altı tonlu tek renk bir ekran ve kare başına yaklaşık 80 milisaniye. Kod doomgeneric'ten türetilip eski bir Emscripten sürümüyle asm.js'e derlenmiş.
• Düzenli ifadeler (2026). Artem Lytkin'in projesinde 96,6 megabaytlık bir metin dizisi işlemci yazmaçlarını, belleği ve özel bir komut kümesini barındırıyor. C ile yazılmış bir sürücü bu metne sabit sıralı bul-değiştir kurallarını uyguluyor; on binden fazla değiştirme işleminin sonunda tek bir kare çıkıyor. Hız, saniyede yaklaşık 80.000 değiştirme.

Sırada ne var

Vogel'in kendi sonucu, projenin çıkış noktasından daha ilgi çekici. Orijinal linux_doom'un çizim motoru yorumlar hariç yaklaşık 3300 satır; SQLDoom'un karşılığı 1300 satır. Vogel, Carmack'ın bir 486 işlemciden biraz göz boyamayla ne kadar performans çıkarılabileceği üzerine çok düşündüğünü söylüyor; 1993'te kurulan mimari, otuz üç yıl sonra bambaşka bir dile aktarıldığında hâlâ tutarlı duruyor.

Pratik tarafta ise bu bir gösteri olmaktan öteye pek gitmiyor — Vogel de aksini iddia etmiyor. Yine de altında bir ölçüm fikri var: aynı ekip Nisan 2026'da DoomBench adıyla, SQL'de çalışan Doom'u veritabanı kıyaslaması olarak kullanan bir çalışma yayımladı. Oradaki sonuçlara göre PostgreSQL tek başına saniyede yaklaşık 10 tik ve 0,3 FPS'te kalıyor, Postgres'e DuckDB eklenen kurgu 10 FPS'e çıkıyor ama bir saniyelik veri gecikmesi taşıyor. Şu notu da düşmek gerekir: kıyaslamayı yapan, kendi ürünü birinci çıkan şirketin kendisi.

Açık kalan soru şu: bir çizim hattı, veritabanları için alışılmadık derecede zorlu bir yük — milisaniyelik gecikme bütçesi, her karede baştan hesap, hata toleransı sıfır. Bu yükü kaldıran bir sorgu derleyicisinin gündelik iş yüklerinde ne kadar fark yarattığını, bu tür projeler değil, bağımsız ölçümler gösterecek.

Fotoğraf: Antimundo, CC BY-SA 4.0, Wikimedia Commons