| ID Tech 1 | |
|---|---|
| Típusú | Játékmotor ( Lista ) |
| Fejlesztő | ID szoftver |
| Kulcs programozó | John Carmack |
| Egy motorsorozat része | ID Tech |
| A sorozat előző motorja | Wolfenstein 3D motor |
| A sorozat következő motorja | Quake motor |
| Kiadási dátum | 1993. december 10 |
| Hardver platformok | PC , Macintosh , Amiga , SNES , Sega 32X , Sega Saturn , 3DO , PlayStation , Game Boy Advance , Atari Jaguar és mások |
| Támogatott operációs rendszer | DOS , Linux , FreeBSD , egyéb UNIX - szerű |
| Nyelvvel írva | C , assembly nyelv |
| Engedély |
1997 előtt - Kereskedelmi szoftver 1997 után - Ingyenes szoftver : GNU GPL licenc |
| Első játék a motoron | Doom / 1993. december 10 |
| Utolsó játék a motoron | Viszály / 1996. május 31 |
A Doom engine („ Doom engine ”), más néven id Tech 1 , egy pszeudo -3D-s játékmotor , amelyet az amerikai id Software cég fejlesztett ki, és számítógépes játékokban használt Doom , Heretic , HeXen , Strife , HacX és más, licenc alapján készült játékokban. . John Carmack készítette , a segítőket Michael Abrash , John Romero , Dave Taylor és Paul Radek írta . _ _ _ _ Eredetileg NeXT számítógépeken írták , majd az első kiadáshoz a Doomot DOS - ra , majd később több játékkonzolra és operációs rendszerre is portolták .
A motort C nyelven írták a NeXT munkaállomásokon a NEXTSTEP operációs rendszeren . Kezdetben az Intel C fordítót használták, de később a Watcom C -t használták . A segédprogramokat a NeXT alatt írták az Objective -C- ben . A Doom motor a maga idejében progresszív volt. Annak ellenére, hogy a C egy procedurális programozási nyelv, a Doom motor explicit objektumstílusban íródott.
A Doom minden szintje valójában 2D, ami jelzi a motor egyik korlátját: lehetetlen, hogy egy szoba (szektor) legyen egy másik szoba felett. Másrészt azonban lehetővé teszi, hogy probléma nélkül rajzoljon egy szinttérképet, amelyen minden fal és tárgy megjelenik, ellentétben a többi ilyen műfajú játékkal.
A szint tíz blokkból áll .WAD-fájl; ezek közül ötöt ( VERTEXES, LINEDEFS, SIDEDEFS, SECTORSés THINGS) közvetlenül a felhasználó szerkeszt, további ötöt ( SEGS, SSECTORS, NODES, REJECTés BLOCKMAP) a BSP-készítő számít ki.
A szintek kivonási elv szerint épülnek fel: minden teret áthatolhatatlan anyag tölt meg, és a szint szerzője alagutakat „vág át” ebben az anyagban. A szint alapja a csúcsok ( angol vertices ) - pontok a kétdimenziós térben. A csúcsok közé szegmenseket rajzolnak ( eng. linedefs ). Egy szegmensnek lehet egy vagy két oldala ( angolul sidedefs ). A textúrák nem szegmensekre vannak beállítva, hanem oldalakra, így egy szegmens különböző oldalról különböző textúrákkal fedhető le.
A csúcsok és a szakaszok síkgráfot alkotnak ; mindegyik lapja lehet áthatolhatatlan tér (például oszlop), vagy szektor ( angol szektor ). Néha szándékosan megsértik a szektorok szerkezetét – a speciális effektusok, például a láthatatlan hidak ezen alapulnak. Minden szektornak tetszőleges alakja van a tervben (nem feltétlenül konvex vagy egyszerűen összefüggő ). A szektornak mindig vízszintes padlója van mennyezettel és állandó megvilágítással. Az egyoldalas szakaszok üres falak, a kétoldalasak átmenetet képeznek a szektorok között.
Az akkori legmagasabb interaktivitás biztosítása érdekében az úgynevezett címkéket használták . A szegmensnek és szektornak van egy speciális egész mezője - "tag". A liftet leengedő kapcsoló létrehozásához a kapcsolószegmens egy műveleti kódot kap: „kapcsoló, amely leengedi a liftet” és néhány címkét (például 5). Ugyanez a címke van hozzárendelve a szektor-lifthez is. Ha aktiválva van, a szegmens végrehajtja a megadott műveletet az összes, ezzel a címkével rendelkező szektorban.
Végül a tárgyak ( dolgok ) kerülnek a szintre. Ugyanakkor a Doomban a tárgyjellemzők halmaza meglehetősen szegényesnek bizonyult: például nem volt Z koordináta, a játék elején mindig a földön állt egy földi tárgy, és egy levegő tárgy lógott le róla. A mennyezeti. Lehetetlen, hogy az objektum csak egyjátékosban , vagy csak deathmatchben , vagy csak kooperációban legyen (csak "csak online játékokban" volt jelző).
Minden számítás 35 ciklus/másodperc gyakorisággal, 16,16-os fix pontban történik, egy texelnek megfelelő gépegységgel (a játékos magassága 56 texel [2] [3] – tehát 1 texel megközelítőleg 4 cm) . Szögértékeknél fix pontot használunk, amelyben 2 32 = 360° [2] . A legtöbb szögszámítás azonban durvább volt - például a játékos fordulatait 360° = 2 16 = 65536 pontossággal számítják ki, és a trigonometrikus táblázat csak 8192 (2 13 ) értékből állt [2] .
A demók rögzítése és az online lejátszás azon alapul, hogy digitális számítógépen ugyanaz a kód ugyanazokkal az adatokkal vezet ugyanarra az eredményre, és az egész számok viselkedése szigorúan meghatározott, és nem függ a processzor modelljétől. A játék a demóban rögzíti (és továbbítja a hálózaton) vezérlőparancsokat [2] [4] [5] ; ha nincsenek durva hibák a játékban, a különböző gépek ugyanazokat a vezérlőparancsokat értelmezve ugyanazt az eredményt kapják. A játékban azonban továbbra is vannak olyan hibák, amelyek deszinkronizáláshoz vezetnek: különösen, ha egyjátékos játékban belép a menübe, a játék leáll, de a videó írása tovább folytatódik [6] . Ennek a megközelítésnek a hátránya, hogy nem lehet visszatekerni a videót; csak az elejétől játszható.
Demo felvétel módban az elforgatási pontosság 256 x 360 fokkal csökkent [2] [7] ; Egy figyelmes játékos észreveheti, hogy a demó módban a hangfelvétel durvább lesz. Ez kizárólag a demók memóriájának megtakarítását szolgálja, és számos porton javították az eredeti játékkal való kompatibilitás elvesztése árán.
Minden játékcikluson (1/35 másodperc) a játék végighalad az egyes szörnyek vezérlésén. A processzorciklusok mentésére van egy bitmátrix REJECT[8] : bármely két szektorra, ha az A szektor egyetlen pontjáról sem látható a B szektor pontja, akkor a mátrixban ezen a helyen van beállítva egy. Ha a játékos szektorának megfelelő sor és a szörny szektorának megfelelő oszlop metszéspontja 0, akkor ellenőrizni kell, hogy a szörny látja-e a játékost; ha 1, akkor a szörny garantáltan nem látja a játékost. A mátrixot REJECTnagyon nehéz felépíteni, és a legtöbb egyéni szerkesztő nullákkal töltötte ki (nagyon kevés segédprogram építette; a főbbek a RMBés ZENNODE).
A szerkezetet BLOCKMAPa fizikai motor alkalmazza, hogy felgyorsítsa az objektumok szegmensekkel való ütközésének ellenőrzését.
A megjelenítés felgyorsítására egy BSP fát [9] használnak (ellentétben a Duke Nukem 3D portáljaival ). Az objektumok spriteként vannak megrajzolva , ellentétben a Quake -kel .
A motor rekurzívan áthalad a BSP fán, falakat rajzolva a legközelebbitől a legtávolabbi felé [10] :
treewalk(node) függvény ha az EnclosingRectangle(node) nincs a nézetkúpban majd kilép ha a csomópont egy villa akkor // a csomópont egy villa - rekurzív traver ha a kamera a vágási síktól balra van majd Tree Pass(node.left); Fa átjáró (jobbra lévő csomópont) egyébként Tree Pass(node.right); Tree Pass (csomópont balra) egyébként // a csomópont egy alszektor húz (csomó)A maradék három blokk itt érintett. A szektorokat szekánsokkal konvex elemekre, alszektorokra ( SSECTORS), a szegmenseket szegmensekre ( SEGS) osztjuk. Maga a fastruktúra (amely téglalapokat, szekánsokat, "fiúkra" mutató mutatókat foglal magában) egy blokkban van tárolva NODES. Ez a ciklus csak tömör falakat rajzol (azaz közepes textúrákat az egyoldalas falakhoz, és felső és alsó textúrákat a kétoldalasokhoz). Az objektumok, emeletek és rácsok külön tömbökbe íródnak, és egy későbbi szakaszban rajzolódnak meg. A padlókat tartó tömb meglehetősen kicsi, és elég gyakori, hogy az amatőr konstruktőrök túlcsordulnak és kilépnek a " No more visplanes!" ".
A falak megrajzolása után a padlókat soronként megrajzolják, visplanokkal írva .
Minden szektor tartalmaz egy linkelt listát a benne lévő objektumokról. A falak rajzolásának szakaszában a látható objektumok a levágási pontokkal együtt egy tömbbe kerülnek. Miután a motor megrajzolta a padlót és a mennyezetet, a tömb rendezése megtörténik, és a legközelebbi 128 objektumot a legtávolabbiaktól a legközelebbiekig megrajzolja a falak rajzolásához használt eljárásokkal. Ugyanebben a szakaszban a rácsokat is rajzolják ("közepes" textúrák a kétoldalas falakon).
A faltextúrákat és a sprite-eket a rendszer egy .WAD fájlban tárolja oszloponként, a padló- és mennyezettextúrák pedig egy egyszerű 64x64-es tömb.
A Doom for DOS VGA 320×200 [11] módban futott hármas puffereléssel , Linuxon normál VGA 13h módot használt . Ebben az esetben a felbontás értéket az assembler eljárásokban két helyen kódolták; a játék változó felbontású változatai vagy több funkcióval rendelkeztek a különböző felbontásokhoz [12] , vagy dinamikusan módosították a kódot , hogy megfeleljen a szükséges felbontásnak [13] . Azonban a játék azon részein, amelyek nem tartoznak a motorhoz, rengeteg mágikus szám társult a képernyőfelbontáshoz és a különböző objektumok képernyőkoordinátáihoz, így a Doom első portjai megszenvedték az SVGA-ban „terjedő” menügrafikát. módok [14] .
A Doom hírhedt hosszú betöltési idejéről (a korabeli számítógépeken több mint egy perc). Az idő nagy részét a "Doom refresh démon " ( eng. Init Doom refresh démon ) inicializálása töltötte .
A Doom -ot hajlékonylemezeken és BBS -en keresztül terjesztették , minden bájt fontos volt. A méret csökkentése érdekében készítettek egy ilyen mechanizmust. A falak minden textúrája töredékekből állt ( angol foltok ): például egy kapcsolóval ellátott fal állhat egy fal képéből és egy kapcsoló képéből, vagy egy csempézett falból - három vagy négy véletlenszerűen elszórt csempéből. egy nagy textúra felett. A textúrák, mint fentebb említettük, oszlopokba vannak rajzolva. A Doom végigjárta az összes textúra összes oszlopát, és ellenőrizte, hogy mely töredékek takarnak egy adott oszlopot; megépült a megfelelő adatstruktúra. Ez a struktúra gyorsítótárazható , vagy a szint betöltésekor megépíthető, szükség szerint dinamikusan építve – ebben az esetben a Doom sokkal gyorsabban tölt be [15] .
Ezenkívül a Doom rendelkezett egy speciális adatgyorsítótárazási módszerrel , amelyet "zónás memóriának" neveztek. Az utasítás a lemezgyorsítótárak (például a SmartDrive ) letiltását javasolta – a Doomnak hatékonyabb gyorsítótára van.
A Doom a peer-to-peer modellen alapul . Mint fentebb említettük, a játék szinkronizálását minden gépen az biztosítja, hogy ugyanaz a kód ugyanazokkal az adatokkal ugyanazt az eredményt adja vissza. Minden csomaghoz egy "szinkronizációs konvolúció" kerül továbbításra - általában az egyik játékos koordinátája; Ha a csomaggal együtt kapott konvolúció nem egyezik a helyileg számított konvolúcióval, a játék leáll egy out of sync üzenettel. Nincs mód az átviteli késések ellensúlyozására; ha az átlagos ping meghaladja a másodperc 1/35-ét, a játék vezérlőelemekre adott válasza lelassul. A játék lekérheti az elveszett csomagokat, és megkettőzheti azokat, így a lehető legritkábbak az újraküldési kérések. A megkezdett játékba belépő nincs.
Egy adott hálózati protokoll támogatását a Doom nem tartalmazza . A játék hálózaton keresztüli futtatásához a játékosok meghívnak egy külső programot – egy hálózati illesztőprogramot , amely kommunikációt hoz létre a gépek között, és meghívja a Doom .EXE fájlt . Ez a kialakítás lehetővé teszi, hogy külső meghajtókat írjon más hálózati protokollokhoz – vagy a Doom hálózati indítóprogramokhoz, amelyek kényelmesebbek a rendelkezésre állóknál.
Mindegyik játékosnak más a színe: az első zöld, a második szürke, a harmadik barna, a negyedik piros. A játékosok számát (és így a színeket) a hálózati illesztőprogram osztja ki, nem a játék. A programon keresztül IPX -en keresztüli játékban a játékosoknak adott színek a hálózati kártyák MAC-címétől , a játékban modemen vagy kábelen keresztül - véletlenszerű tényezőktől IPXSETUPfüggenek . SERSETUP
Az 1.0-s és az 1.1-es verziók érdekes, nem dokumentált jellemzője az egyjátékos játék volt három monitoros rendszeren: az egyik azt mutatja, ami a játékos előtt van, a második, ami a bal oldalon, a harmadik pedig a jobb oldalon. Mivel ekkoriban még nem léteztek ennyi monitoros videokártyák, három hálózatra kapcsolt számítógép kellett egy ilyen játékhoz. Ez a funkció azonban csak gyerekcipőben létezett: a mentésből való betöltéshez mindhárom számítógépen újra kellett indítani a játékot.
A Doom motort más cégeknek adták el. Számos játék készült rajta. Közöttük:
Ezenkívül a játék rajongói egyéni módosításokat készítettek , amelyek teljesen átalakították a játékot. Közülük az első, az Alien Doom az Alien című film alapján készült . Ezt követően más filmeken is megjelentek a módosítások: „ Szellemirtók ”, „ Batman ” és „ Az X-akták ”. Lásd: Modding Doom .
1994 -ben megnyitották a hálózati illesztőprogramok forrásszövegét. A rajongók elkezdték fejleszteni saját meghajtóikat: például LPT-kábelhez ( PARSETUP), sőt COM- kábellánchoz ( HX8).
1997 decemberében a Doom for Linux teljes forráskódja nem ingyenes, ingyenes licenc alatt jelent meg (a DOS -os verzió a fizetős DMX hangkönyvtár miatt nem jelent meg). Már 1998 januárjában megjelent ennek a kódnak az első portja a DOS számára - a DosDoom . A DMX helyett nyitott Allegrot használtak .
A Doom bővítés úttörői Lee Killow ( a Boom a Doom kiterjesztett változata, amely az eredeti játék számos hibáját javította), Denis Fabrice és Boris Pereira ( nagy felbontású Doom Legacy ), valamint Bruce Lewis ( glDoom , az első OpenGL - port ) voltak. of Doom ) .
Fél év fejlesztés után Lewis számítógépének merevlemezének meghibásodása vetett véget a glDoomnak : nem volt biztonsági mentés . Emiatt a Carmack újraengedélyezte a forráskódot a GNU General Public License alatt : ha a licenc nem lenne ennyire korlátozó, valaki megtalálta volna a forráskódot [16] . A többi forrás kifizetve marad. 12 év után megtalálták a forráskódot – egy baráttól, akihez Lewis egy lemezzel ment.
Hatalmas számú hibát találtak a Doomban [17] . A fizikai motor és a renderer eltérően határozta meg, hogy a repülőgép "mennyei"-e vagy sem: egy rakéta elérheti az eget és felrobbanhat [18] , és fordítva, "elrepülhet" anélkül, hogy átrobbanna egy üres falon [19] . A szörnyek beszorultak az ajtókba [20] , és Arch-Vile egy összezúzott holttestet feltámasztva egyszerre tette sebezhetetlenné és képessé tette átjutni a falakon [21] . A portok általában a demó verzióját ellenőrizték : a hibákat bekapcsolták, ha a vágást a játék eredeti verziója rögzítette, és kikapcsolta, ha a port. Az ilyen hibák bizonyos felhasználói szinteken kritikusak voltak az áthaladáshoz – ezért a Boom és a származékos portoknál a menüből lehetett engedélyezni.
Jelenleg a Doom több tucat fejlett verziója létezik – a legegyszerűbbtől a rendkívül erősig. Lehetővé teszik, hogy nagyobb felbontásban játssz, mint az eredeti Doom , további funkciókkal rendelkeznek (felfelé mutató nézet, szálkereszt), valamint továbbfejlesztett online játék . Ezek közül a leghíresebb verziók:
A Doom Legacy , a ZDoom és a SkullTag képes botokkal játszani .
A kevésbé jelentős módosításokat röviden felsoroljuk a Doom játékok portjainak listájában.
A Doom adatfájlok a mai napig fizetve maradnak. Egy teljesen ingyenes IWAD fájl létrehozásához elindult a FreeDoom projekt .
| Doom sorozat | ||||||
|---|---|---|---|---|---|---|
| Játékok |
| |||||
| Vállalatok | ||||||
| Technológia | ||||||
| Filmek |
| |||||
| Egyéb | ||||||
| A Kategória:Doom sorozat játékainak listája | ||||||
| ID szoftver | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Játékok |
| ||||||||||||||||
| Alkalmazottak |
| ||||||||||||||||
| Vállalat | |||||||||||||||||
| Technológia | |||||||||||||||||
| Egyéb |
| ||||||||||||||||