Silnik Doom (id Tech 1) — budowa, działanie i najważniejsze porty

Silnik Doom (id Tech 1) — szczegółowy przewodnik: budowa, działanie, format WAD, techniki BSP oraz najważniejsze porty źródłowe (Boom, PrBoom, ZDoom, Chocolate Doom).

Silnik Doom, czasami nazywany id Tech 1, to kod komputerowy stojący za grą wideo Doom. Jest on również używany przez kilka innych gier, w tym Doom 2 (ale nie Doom 3, która ma swój własny silnik). Mocno zmodyfikowane wersje silnika Doom zostały użyte w grach takich jak Heretic, Hexen i Strife. Dzięki udostępnieniu kodu źródłowego i otwartej strukturze danych powstała ogromna społeczność tworząca mody, nowe mapy i liczne porty źródłowe.

Podstawy architektury

Silnik wykorzystuje technikę zwaną binarnym podziałem przestrzeni (BSP, ang. Binary Space Partitioning), aby reprezentować poziomy i szybko wyznaczać widoczne fragmenty sceny. Mapa jest zapisana w specjalnym formacie WAD i wewnętrznie przedstawiana za pomocą struktur takich jak linedefs, sidedefs, sektory, wertykali (vertices) oraz rzeczy (ang. things — potwory, przedmioty, dekoracje itp.). Silnik odczytuje poziomy i inne zasoby właśnie z plików WAD.

Reprezentacja świata — „2.5D”

Chociaż Doom sprawia wrażenie trójwymiarowego, technicznie jest to silnik 2.5D (planarny): każdy sektor ma jedną wysokość podłogi i jedną wysokość sufitu, nie występują prawdziwe „pokoje nad pokojami” (bez trików i hacków). Ściany są definiowane przez linie (linedefs) łączące wierzchołki, a tekstury i wygląd sektorów przypisuje się per-sidedef / sector. Potwory i przedmioty są reprezentowane jako sprite’y (dwuwymiarowe bitmapy), które zawsze zwracają się do kamery (tzw. billboarding).

Renderowanie i optymalizacje

Renderowanie sceny odbywa się całkowicie na CPU, a nie na karcie graficznej, ponieważ w czasie powstania gry (wczesne lata 90.) dostępne karty rzadko wspierały akcelerację 3D. To wymusiło zastosowanie wielu wydajnych trików i struktur danych:

• BSP: drzewo podziału przestrzeni jest używane do szybkiego odrzucania fragmentów mapy niewidocznych z pozycji gracza i do ustalania kolejności rysowania.
• Column-based rendering: ściany są rysowane kolumna po kolumnie (pionowe paski tekstury), co pozwala zmniejszyć liczbę operacji per-piksel.
• Visplanes: podłogi i sufity są renderowane jako spójne obszary (visplanes), co optymalizuje rysowanie dużych płaszczyzn.
• Fixed-point arithmetic i tablice trygonometryczne: zamiast wolnych obliczeń zmiennoprzecinkowych używano operacji na liczbach stałoprzecinkowych i precomputed lookup tables.
• Bloking / blockmap: struktura przyspieszająca wykrywanie kolizji i przeszukiwanie obiektów na mapie.
• Ograniczone oświetlenie: oświetlenie jest przypisane per-sector i symulowane przez kolormapę (paletę), a nie przez globalne obliczenia źródeł światła.

Format WAD i dane map

Pliki WAD zawierają „lumps” — bloki danych takie jak grafika (textures, flats), dźwięki, definicje map i tablice. Mapy zawierają listy wierzchołków, linedefs, sidedefs, sektory, segs, subsektory, nodes (BSP) i things. W praktyce funkcjonalność map i zachowanie obiektów można modyfikować, tworząc własne PWADy (dodatkowe WADy) i udostępniając je innym graczom.

Ograniczenia oryginalnego silnika

• Brak pełnej trójwymiarowości: nie ma natywnego wsparcia dla nakładających się przestrzeni (rooms-over-rooms).
• Każdy sektor ma pojedynczą wysokość podłogi i sufitu — brak stromych zboczy bez dodatkowych tricków (większość „pochyleń” i „slope’ów” dodano później w portach).
• Sprite’y są zawsze płaskie i zawsze zwrócone do kamery; brak meshowania modeli 3D w oryginalnej wersji.
• Ograniczone pole patrzenia w pionie w oryginalnych buildach — patrzenie w górę/dół było symulowane, a jego obsługa została rozszerzona w portach.

Porty źródłowe i modyfikacje

Kod źródłowy silnika został potem udostępniony na zasadach wolnej licencji (GNU GPL), co pozwoliło społeczności na tworzenie licznych portów źródłowych, które dodają funkcje, poprawiają zgodność i umożliwiają uruchamianie gry na nowych platformach. Wielu fanów Dooma stworzyło swoje własne zmodyfikowane wersje zwane portami źródłowymi. Porty źródłowe często dodają nowe funkcje i naprawiają problemy w oryginalnym silniku. Popularne porty źródłowe to Boom, PrBoom, PrBoom+, Zdoom i Chocolate Doom.

Dodatkowo warto wymienić nowsze i popularne projekty takie jak GZDoom (rozszerzony renderer OpenGL z shaderami i bogatą obsługą modów), Doomsday Engine (3D-accelerated renderer), Odamex (sieciowy port), Freedoom (wolne zasoby zastępujące oryginalne WADy) oraz liczne przeniesienia na konsole, telefony komórkowe i urządzenia embedded. Różne porty kładą nacisk na: wierne odwzorowanie oryginału (Chocolate Doom), zgodność z demo i replayami (PrBoom), rozbudowane możliwości modowania i nowe efekty (Z/GZDoom) czy poprawki gameplayowe (Boom).

Funkcje sieciowe i narzędzia

Oryginalny Doom wspierał rozgrywkę wieloosobową (tzw. netplay) oraz nagrywanie i odtwarzanie demo. Społeczność stworzyła też szereg narzędzi ułatwiających tworzenie zawartości: edytory map (np. DoomEd, DEU, SLADE), narzędzia do edycji zachowania i animacji (DeHackEd) oraz programy do konwersji i analizy WAD-ów.

Dziedzictwo i znaczenie

Silnik Doom miał wielki wpływ na rozwój gier FPS: przyczynił się do popularyzacji modyfikowalnych gier, rozwoju technik renderowania w oprogramowaniu oraz powstania wielu komercyjnych i niekomercyjnych projektów opartych na jego kodzie. Jego lekkość, czytelna architektura i otwartość źródeł sprawiły, że był i jest portowany na setki platform — od klasycznych komputerów po urządzenia wbudowane i smartfony — i nadal jest przedmiotem aktywnego rozwoju ze strony społeczności.

Pytania i odpowiedzi

P: Co to jest silnik Dooma?

P: W jaki sposób silnik Dooma przedstawia poziomy 3D?

P: W jakim języku napisany jest silnik Doom?

P: Czy jest dostępna wersja open source silnika Doom?

P: Jakie są popularne porty źródłowe oryginalnego silnika doom?

P: Jakich struktur używa silnik doom do reprezentacji poziomów?

P: Jak odczytuje dane z plików?

Szukaj według litery