| ID Tech 1 | |
|---|---|
| Type | Spilmotor ( liste ) |
| Udvikler | ID-software |
| Nøgleprogrammør _ | John Carmack |
| Del af en serie af motorer | ID Tech |
| Tidligere motor i serien | Wolfenstein 3D-motor |
| Den næste motor i rækken | Quake motor |
| Udgivelses dato | 10. december 1993 |
| Hardware platforme | PC , Macintosh , Amiga , SNES , Sega 32X , Sega Saturn , 3DO , PlayStation , Game Boy Advance , Atari Jaguar og mere |
| Understøttet OS | DOS , Linux , FreeBSD , andet UNIX - lignende |
| Skrevet i sprog | C , samlesprog |
| Licens |
før 1997 - Kommerciel software efter 1997 - Gratis software : GNU GPL-licens |
| Første spil på motoren | Doom / 10. december 1993 |
| Sidste spil på motoren | Strife / 31. maj 1996 |
Doom engine (" Doom engine "), også kendt som id Tech 1 , er en pseudo -3D -spilmotor udviklet af det amerikanske firma id Software og brugt i computerspil Doom , Heretic , HeXen , Strife , HacX og andre spil skabt under licens . Skabt af John Carmack , hjælperne blev skrevet af Michael Abrash , John Romero , Dave Taylor og Paul Radek . _ _ Oprindeligt skrevet på NeXT -computere , så blev Doom til den første udgivelse porteret til DOS og senere til flere spilkonsoller og operativsystemer .
Motoren blev skrevet i C på NeXT - arbejdsstationer på NEXTSTEP -operativsystemet . I starten blev Intel C -kompileren brugt, men senere blev Watcom C brugt . Hjælpeprogrammerne blev skrevet under NeXT i Objective-C . Doom -motoren var progressiv for sin tid. På trods af at C er et proceduremæssigt programmeringssprog, er Doom -motoren skrevet i en eksplicit objektstil .
Alle niveauer i Doom er faktisk 2D, hvilket indikerer en af motorens begrænsninger: det er umuligt at have et rum (sektor) over et andet rum. Men på den anden side giver det dig mulighed for at tegne et niveaukort med alle vægge og objekter vist uden problemer, i modsætning til andre spil i denne genre.
Niveauet består af ti blokke .WAD-fil; fem af dem ( VERTEXES, LINEDEFS, SIDEDEFS, SECTORSog THINGS) redigeres direkte af brugeren, fem mere ( SEGS, SSECTORS, NODES, REJECTog BLOCKMAP) beregnes af BSP-builderen.
Niveauer er bygget efter det subtraktive princip: alt rum er fyldt med uigennemtrængeligt stof, og forfatteren af niveauet "skærer gennem" tunneler i denne sag. Grundlaget for niveauet er toppunkter ( engelske toppunkter ) - punkter i todimensionelt rum. Segmenter tegnes mellem hjørnerne ( eng. linedefs ). Et segment kan have en eller to sider ( engelsk sidedefs ). Teksturer indstilles ikke til segmenter, men til sider, så et segment kan dækkes fra forskellige sider med forskellige teksturer.
Hjørnerne og linjestykkerne danner en plan graf ; hver af dens ansigter kan enten være et uigennemtrængeligt rum (for eksempel en søjle) eller en sektor ( engelsk sektor ). Nogle gange er strukturen af sektorer bevidst krænket - specialeffekter som usynlige broer er baseret på dette. Hver sektor har en vilkårlig form i plan (ikke nødvendigvis konveks eller blot forbundet ). Sektoren har altid et vandret gulv med loft og konstant belysning. Ensidede sektioner er tomme vægge, tosidede danner overgange mellem sektorer.
For at sikre den højeste interaktivitet på det tidspunkt blev de såkaldte tags brugt . Segmentet og sektoren har et særligt heltalsfelt - "tag". For at lave en kontakt, der sænker elevatoren, får kontaktsegmentet en handlingskode med "kontakt, der sænker elevatoren" og et mærke (f.eks. 5). Det samme mærke er tildelt sektorelevatoren. Når det er aktiveret, vil segmentet udføre den angivne handling på alle sektorer med dette tag.
Til sidst placeres genstande ( ting ) på niveauet. Samtidig viste sættet af objektkarakteristika i Doom sig at være temmelig ringe: for eksempel var der ingen Z -koordinat, et jordobjekt stod altid på gulvet i begyndelsen af spillet, og et luftobjekt hang fra loftet. Det er umuligt at få objektet til kun at være i singleplayer , eller kun i deathmatch , eller kun i co-op (der var kun et flag "kun i onlinespil").
Alle beregninger udføres med en frekvens på 35 cyklusser i sekundet, i et fast punkt på 16,16, med en maskinenhed lig med en texel (spillerens højde er 56 texel [2] [3] - så 1 texel er omtrent lig med 4 cm) . For vinkelværdier anvendes et fast punkt, hvor 2 32 = 360° [2] . De fleste vinkelberegninger var dog mere grove - for eksempel er spillerens drejninger beregnet med en nøjagtighed på 360° = 2 16 = 65536, og den trigonometriske tabel bestod kun af 8192 (2 13 ) værdier [2] .
Optagelse af demoer og onlinespil er baseret på det faktum, at på en digital computer fører den samme kode med de samme data til det samme resultat, og heltals aritmetikkens opførsel er strengt specificeret og afhænger ikke af processormodellen. Spillet optager i demoen (og sender over netværket) kontrolkommandoer [2] [4] [5] ; hvis der ikke er nogen grove fejl i spillet, får forskellige maskiner, der fortolker de samme kontrolkommandoer, det samme resultat. Der er dog stadig fejl i spillet, der fører til desynkronisering: især, hvis du går ind i menuen i et enkeltspillerspil, stopper spillet, men videoen bliver ved med at blive skrevet [6] . Ulempen ved denne fremgangsmåde er manglende evne til at spole videoen tilbage; det kan kun spilles fra begyndelsen.
I demo-optagelsestilstand blev rotationsnøjagtigheden reduceret til 256 gange 360 grader [2] [7] ; En opmærksom spiller kan bemærke, at pickuppen bliver mere hård i demo-tilstanden. Dette tjener udelukkende til at spare hukommelse i demoerne og er blevet rettet i adskillige porte på bekostning af at miste kompatibiliteten med det originale spil.
Hver spilcyklus (1/35 af et sekund) går spillet gennem kontrollen af hvert monster. For at gemme processorcyklusser er der en bitmatrix REJECT[8] : for to vilkårlige sektorer, hvis intet punkt i sektor B er synligt fra noget punkt i sektor A, sættes et på dette sted i matricen. Hvis skæringspunktet mellem rækken, der svarer til spillerens sektor, og kolonnen, der svarer til monsterets sektor, er 0, foretages en kontrol for at se, om monsteret ser spilleren; hvis 1, er monsteret garanteret ikke at se spilleren. Matrixen REJECTer meget svær at bygge, og de fleste brugerdefinerede redaktører fyldte den med nuller (der var meget få værktøjer, der byggede den; de vigtigste er RMBog ZENNODE).
Strukturen BLOCKMAPanvendes af fysikmotoren for at fremskynde kontrollen af objektkollisioner med segmenter.
For at fremskynde visningen bruges et BSP -træ [9] (i modsætning til portaler i Duke Nukem 3D ). Objekter tegnes som sprites , i modsætning til Quake .
Motoren krydser BSP-træet rekursivt og trækker vægge fra nærmeste til fjerneste [10] :
treewalk(node) funktion hvis EnclosingRectangle (node) ikke er i view-keglen derefter afslutte hvis knudepunktet er en gaffel derefter // knudepunktet er en gaffel - rekursivt kryds hvis kameraet er til venstre for skæreplanet derefter Træpas(node.venstre); Træpas (node til højre) ellers Tree Pass(node.right); Træpas (node til venstre) ellers // er noden en undersektor tegne (knude)De resterende tre blokke er involveret her. Sektorer er opdelt af sekanter i konvekse elementer kaldet undersektorer ( SSECTORS), segmenter er opdelt i segmenter ( SEGS). Selve træstrukturen (som omfatter rektangler, sekanter, peger på "sønner") er gemt i en blok NODES. Denne cyklus tegner kun solide vægge (dvs. medium teksturer til enkeltsidede vægge og top- og bundteksturer til dobbeltsidede). Objekter, gulve og gitter er skrevet til separate arrays og tegnet på et senere tidspunkt. Arrayet, der holder gulvene, er lavet ret lille, og det er ret almindeligt, at amatørkonstruktører flyder over og går ud med beskeden " No more visplanes!" ".
Efter at væggene er tegnet, tegnes gulvene linje for linje, skrevet med visplaner .
Hver sektor har en sammenkædet liste over objekter, der er i den. På stadiet med at tegne væggene føjes de synlige objekter sammen med afskæringspunkterne til et array. Efter at motoren har tegnet gulve og lofter, sorteres arrayet, og de nærmeste 128 objekter trækkes fra den nærmeste til den nærmeste ved at bruge de samme procedurer, som bruges til at tegne vægge. På samme trin tegnes også riste ("medium" teksturer på dobbeltsidede vægge).
Vægteksturer og sprites gemmes i en .WAD -fil efter søjler, gulv- og loftteksturer er et simpelt 64x64-array.
Doom til DOS kørte i VGA 320×200 [11] -tilstand med tredobbelt buffering , til Linux brugte den normal VGA 13h-tilstand. I dette tilfælde blev opløsningsværdien indkodet i assembler-procedurer to steder; versioner af spillet, der brugte variabel opløsning, havde enten flere funktioner til forskellige opløsninger [12] eller ændrede dynamisk koden til at matche den nødvendige opløsning [13] . Men i dele af spillet, der ikke hører til motoren, var der en masse magiske tal forbundet med skærmopløsning og skærmkoordinater for forskellige objekter, så de første porte i Doom led af menugrafik, der "spredes" i SVGA tilstande [14] .
Doom er berygtet for sine lange indlæsningstider (mere end et minut på computere på sin tid). Det meste af tiden blev brugt på at initialisere " Doom refresh daemon " ( eng. Init Doom refresh daemon ) .
Doom blev distribueret på disketter og via BBS var hver byte vigtig. For at reducere størrelsen lavede de en sådan mekanisme. Hver af teksturerne til væggene bestod af fragmenter ( engelske patches ): for eksempel kan en væg med en kontakt bestå af et billede af en væg og et billede af en kontakt eller en flisebelagt væg - af tre eller fire tilfældigt spredte fliser over en stor tekstur. Teksturer, som nævnt ovenfor, er tegnet i kolonner. Doom gennemgik alle kolonnerne i alle teksturerne og kontrollerede, hvilke fragmenter der dækkede en bestemt kolonne; den tilsvarende datastruktur blev bygget. Denne struktur kunne cachelagres eller bygges, når niveauet blev indlæst, opbygget dynamisk efter behov - i dette tilfælde ville Doom indlæses meget hurtigere [15] .
Derudover havde Doom en specialiseret data- caching - metode kaldet "zoned memory". Instruktionen anbefalede at deaktivere diskcaches som SmartDrive - Doom har en mere effektiv cache.
Doom er baseret på peer-to-peer- modellen . Som nævnt ovenfor er synkroniseringen af spillet på alle maskiner sikret ved, at den samme kode med samme data returnerer det samme resultat. Med hver pakke transmitteres en "synkroniseringsfoldning" - normalt koordinaterne for en af spillerne; hvis foldningen modtaget med pakken ikke stemmer overens med den lokalt beregnede, stopper spillet med en ude af synkroniseringsmeddelelse. Der er ingen midler til at modvirke transmissionsforsinkelser; hvis det gennemsnitlige ping overstiger 1/35 af et sekund, bliver spillets reaktion på kontroller langsommere. Spillet kan anmode om tabte pakker og duplikere dem, så gentransmissionsanmodninger er så sjældne som muligt. Der er ingen adgang til det påbegyndte spil.
Understøttelse af en bestemt netværksprotokol er ikke inkluderet i Doom . For at køre spillet over et netværk kalder spillere et eksternt program - en netværksdriver , der etablerer kommunikation mellem maskiner og kalder Doom .EXE-filen . Dette design giver dig mulighed for at skrive eksterne drivere til andre netværksprotokoller - eller Doom netværksstartere, der er mere bekvemme end de tilgængelige.
Hver af spillerne har en forskellig farve: den første er grøn, den anden er grå, den tredje er brun, den fjerde er rød. Spillernumre (og derfor farver) distribueres af netværksdriveren, ikke af spillet. I spillet over IPX gennem programmet IPXSETUPafhænger farverne, der gives til spillerne, af MAC-adresserne på netværkskort , i spillet over et modem eller kabelgennemgang SERSETUP på tilfældige faktorer.
En interessant udokumenteret funktion i version 1.0 og 1.1 var et enkeltspillerspil på et system med tre skærme: den ene viser, hvad der er foran spilleren, den anden er, hvad der er til venstre, den tredje er, hvad der er til højre. Da der ikke fandtes skærmkort med så mange skærme på det tidspunkt, var der brug for tre computere forbundet med et netværk til sådan et spil. Denne funktion eksisterede dog kun i sin vorden: for at indlæse fra en lagring, var det nødvendigt at genstarte spillet på alle tre computere.
Doom -motoren blev solgt til andre virksomheder. Der er lavet en del spil på den. Blandt dem:
Også, brugerdefinerede ændringer blev skabt af fans af spillet , som fuldstændig transformerede spillet. Den første af dem - Alien Doom - blev lavet baseret på filmen " Alien ". Efterfølgende dukkede ændringer op på andre film: " Ghostbusters ", " Batman " og " The X-Files ". Se Modding Doom .
I 1994 åbnede de kildeteksterne til netværksdrivere. Entusiaster begyndte at udvikle deres egne drivere: for eksempel til LPT-kabel ( PARSETUP) og endda til COM- kabelkæde ( HX8).
I december 1997 blev den fulde kildekode til Doom til Linux udgivet under en ikke-fri, gratis licens ( DOS - versionen blev ikke offentliggjort på grund af det betalte DMX-lydbibliotek). Allerede i januar 1998 dukkede den første port af denne kode til DOS op - DosDoom . I stedet for DMX blev der brugt en åben Allegro .
Pionererne bag Doom -udvidelsen var Lee Killow ( Boom er en udvidet version af Doom , der fiksede mange af det originale spils fejl), Denis Fabrice og Boris Pereira ( Doom Legacy i høj opløsning ) og Bruce Lewis ( glDoom , den første OpenGL -port af Doom ).
Efter et halvt års udvikling satte fejlen på harddisken på Lewis' computer en stopper for glDoom : der var ingen backup . På grund af dette genlicenserede Carmack kildekoden under GNU General Public License : hvis licensen ikke var så restriktiv, ville nogen have fundet kildekoden [16] . Resten af ressourcerne forbliver betalt. Efter 12 år blev kildekoden fundet - fra en ven, som Lewis gik med en disk til.
Et stort antal fejl er blevet fundet i Doom [17] . Fysikmotoren og rendereren afgjorde forskelligt, om flyet var "himmelsk" eller ej: en raket kunne ramme himlen og eksplodere [18] , og omvendt kunne den "flyve væk" uden at eksplodere gennem en blank væg [19] . Monstre ville sidde fast i døre [20] , og Arch-Vile , der genoplivede et knust lig, gjorde det samtidig usårligt og i stand til at passere gennem vægge [21] . Porte tjekkede normalt versionen af demoen : fejl blev slået til, hvis cuttet blev optaget af den originale version af spillet, og slået fra, hvis af porten. Sådanne fejl på nogle brugerniveauer var kritiske for beståelse - derfor kunne de i Boom og afledte porte aktiveres via menuen.
Nu er der flere dusin avancerede versioner af Doom - fra den enkleste til ekstremt kraftfuld. De giver dig mulighed for at spille med en højere opløsning end den originale Doom , har yderligere funktioner (op-ned-visning, trådkors) samt forbedret onlinespil . De mest berømte af disse versioner er:
Doom Legacy , ZDoom og SkullTag har mulighed for at spille med bots .
Mindre væsentlige ændringer er kort opført på listen over porte til Doom-spil.
Doom-datafiler forbliver betalt den dag i dag. For at oprette en helt gratis IWAD -fil blev FreeDoom- projektet startet .
| Doom -serien | ||||||
|---|---|---|---|---|---|---|
| Spil |
| |||||
| Virksomheder | ||||||
| Teknologi | ||||||
| Film |
| |||||
| Andet | ||||||
| Liste over spil i serien Kategori:Doom | ||||||
| ID-software | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Spil |
| ||||||||||||||||
| Medarbejdere |
| ||||||||||||||||
| Selskab | |||||||||||||||||
| Teknologi | |||||||||||||||||
| Andet |
| ||||||||||||||||