1.300 satırlık SQL sorgusu, Cehennem'in doğru bitmap görüntülerini saniyede 35 kare (fps) hızında oluşturuyor.
Lukas Vogel, bir SQL veritabanı kullanarak Doom'u tam olarak nasıl oluşturduğunu anlattığı uzun bir blog yazısında, "Doom'u bir veritabanında oluşturmak elbette kötü bir fikir," diye yazıyor.
Bazı performans istatistiklerini ve SQLDoom'a ait işleme hattı (rendering pipeline) ayrıntılarını gösteren bir hata ayıklama görünümü. Görsel: Lukas Vogel
Tam olarak öyle sayılmaz. SQLDoom projesi; girdi ve çıktı işlemlerini yönetmek, oyunun zamanlamasını kontrol etmek ve her kareyi ekrana yansıtmak için küçük bir Python istemcisi kullanıyor. Bunun arka planında, bir dizi CedarDB tablosu oyun geometrisini ve durumunu takip ederken; 89 adet "ortak tablo ifadesine" (CTE) yayılmış yaklaşık 1.300 satırlık SQL sorgusu, oyun mantığını uyguluyor ve saniyede 35 bitmap kare arabelleği (framebuffer) üretiyor.
Bu yönüyle SQLDoom, Vogel'in geçen yıl "tamamen SQL içinde, çok oyunculu ve Doom benzeri bir nişancı oyunu" oluşturmayı amaçlayan önceki DoomQL projesine kıyasla büyük bir ilerleme kaydediyor. Ne yazık ki o girişim, Wolfenstein 3D'nin basit, 90 derecelik açılara sahip haritalarını andıran, ışın dökümü (raycasting) tabanlı ve gri tonlamalı ASCII grafiklerle sonuçlanmıştı. Öte yandan daha yeni olan SQLDoom, orijinal Doom çalıştırılabilir dosyasından çıkmış gibi görünen, tam renkli 640×480 çözünürlüğünde kareler üretiyor.
Sonuçta her şey sadece veriden ibaret
Vogel, Doom'un klasik WAD dosyalarını ilişkisel bir veritabanına dönüştürmenin nispeten basit ve anlaşılır olduğunu belirtiyor; çünkü orijinal oyun, bölümleri köşe noktaları (vertices), çizgiler, sektörler ve benzeri bileşenlere ayırarak kurgulamıştı. Doom'un meşhur ikili uzay bölme (BSP) ağaçları bile, yükleme sırasında her konum için önceden hesaplanan bir sıralama anahtarı (sort_key) kullanılarak SQL yapısına dökülebiliyor. Tablonuzda bu anahtarın yer alması sayesinde, basit bir "ORDER BY" ifadesiyle her karede duvarların hangi kısımlarının gösterileceği ve hangilerinin göz ardı edileceği belirlenebiliyor; bu da performansı büyük ölçüde artırıyor.
Ancak, SQL tablosundan birinci şahıs bakış açısıyla oluşturulmuş (render edilmiş) karelere geçiş sürecinde bazı zorluklar yaşandı. Bunların başında, zemin ve tavanların çizilmesi için gereken algoritma geliyordu; zira bu işlem, orijinal oyunda sütun bazlı bir yaklaşımla zarif "visplane" (görünür düzlem) yöntemleri ve durum değişiklikleri (state mutations) kullanılarak hallediliyordu. SQLDoom için Vogel, panellerden oluşan sıralı bir liste üzerinde döngü kurmayı içeren ve kendisinin de "oldukça 'hack' işi" (geçici/pratik çözüm) olarak nitelendirdiği bir yöntem kullanıyor.
Her işlem için SQL tablolarına veri yazıp okumanın getirdiği ciddi ek yüke rağmen Vogel, DoomSQL'i Ryzen 7 işlemcili bir dizüstü bilgisayarda yaklaşık 60 fps hızında çalıştırmayı başardığını; yalnızca yoğun sahnelerde hızın zaman zaman 35 fps'ye düştüğünü belirtti. Doom'u SQL'e uyarlamanın getirdiği zorluklara karşın Vogel, veritabanının sunduğu istikrarlı oyun durumu "referans anlık görüntüsü" (snapshot) ile doğal eşzamanlılık ve erişim yönetimi özelliklerinin, çok oyunculu bir sunucu çalıştırma konusunda önemli avantajlar sağladığına dikkat çekiyor. Vogel, bir veritabanı kullanıldığında "kısmen uygulanmış güncellemeler, fizik hataları veya roketin gerçekten isabet edip etmediğine dair anlaşmazlıklar" gibi sorunların yaşanmadığını ifade ediyor.
Eğer Doomtabase'i kendi yerel bilgisayarınızda çalıştırmak isterseniz; GitHub'daki kod, bir CedarDB kopyası ve bir Doom WAD dosyası ile bunu kolayca yapabilirsiniz. Ya da tüm kurulum süreçleriyle uğraşmadan, ücretsiz olarak çevrimiçi barındırılan bir demo maça katılarak sistemi deneyebilirsiniz (gerçi ben bu seçeneği kullandığımda oldukça düşük bir performansla karşılaşmıştım).
Kaynak: Someone got Doom in an SQL database - Kyle Orland / Ars Technica
.