Ontwikkelaar laat DOOM draaien in TypeScript-types

Een ontwikkelaar heeft het voor elkaar gekregen om DOOM te laten draaien in TypeScript-types. Het doel van het project was om te demonstreren waarom DOOM niet in TypeScript-types kan draaien, maar tot verbazing van de ontwikkelaar zelf blijkt dit wel mogelijk.

De ontwikkelaar, Dimitri Mitropoulos van Michigan TypeScript, heeft zijn project op GitHub gedeeld. Daar legt hij uit dat het gaat om een WebAssembly-runtime die puur in TypeScript-types geïmplementeerd is. "Het idee is dat je C-code (of gewoon WebAssembly) in een TypeScript-type kunt omzetten (zonder JavaScript-runtimecode) die de instructies compileert en een resultaat teruggeeft."

Dat resultaat is een TypeScript-object waar iedere waarde bestaat uit een regel pixels. In totaal worden er 128.000 pixels gegenereerd, voor een 320x200 Ascii-frame. Ook is het mogelijk om input vanuit een toetsenbord te verwerken, zodat het spel daadwerkelijk gespeeld kan worden. Om het spel te draaien, was wel flinke rekenkracht nodig: 177 terabytes aan TypeScript-types moeten twaalf dagen lang continu door TypeScript-compiler draaien om de game te kunnen booten en het eerste frame te zien. Dat is al een extreme optimalisatie, zegt Mitropoulos. In eerste instantie ging het om 1,25 petabytes aan types die drie maanden moesten draaien.

Geïnteresseerden kunnen het eindresultaat zelf draaien. Mitropoulos benadrukt op GitHub echter dat hij helemaal geen interesse heeft om verder te werken aan dit project. "Het draait DOOM, dat is genoeg", aldus de ontwikkelaar. "Als je naar de commitgeschiedenis kijkt, zie je dat ik helemaal gestopt ben zodra ik de missie voltooide."

Wel gaat hij de komende tijd op YouTube nog dieper in op de technische details van het project. Er komt namelijk nog een technische deep dive, net als een video waarin Mitropoulos uitlegt waarom hij dit project is gestart. Wanneer de video's verschijnen, is niet bekendgemaakt.

Door Eveline Meijer

Nieuwsredacteur

27-02-2025 • 09:07

31

Submitter: himlims_

Reacties (31)

31
28
15
3
0
12
Wijzig sortering
Vet cool. Hij heeft dus een emulator / virtualisatie laag geschreven om WebAssembly (de Doom runtime) te kunnen draaien in TypeScript.
In theorie kan je natuurlijk alles op alles draaien, mits je vertaallaag ertussen de vertaling kan maken.
Vooral ook zijn motivatie.
"ik wil kunnen aantonen dat het niet kan.... oh, het kan toch wel :) "
Dit gaat iets verder. Hij draait Doom niet in TypeScript, maar in de TypeScript compiler middels het type resolution system. Dit is vergelijkbaar met het template systeem in C++, wat in principe een Turing-complete functionele programmeertaal is die draait in de compiler. Hierbij zijn de templates je functies, de type arguments je variabelen en de types zelf je waardes. Pattern matching binnen de templates is hoe je program flow kunt definiëren. De compiler loopt door deze templates heen om alle concrete types uit te vogelen en voert hierbij effectief een "programma" uit. En als je je eenmaal realiseert dat dit kan, dan is het natuurlijk ook mogelijk om bestaande applicaties te porten naar deze programmeeromgeving. Trek dat ver genoeg door, en voordat je het weet draai je Doom in een compiler. :P
Het is compleet nutteloos, maar ik begin wel steeds meer respect te krijgen voor WebAssembly. Zo liep ik laatst tegen Leptos aan waarmee je de frontend in Rust kunt maken via WebAssembly en een artikel waarin hetzelfde gedaan is om een React (lees: bakken Javascript) front-end te vervangen, maar dan met Go via WebAssembly (dagger.io). Ik ben me inmiddels wel gaan inlezen om er zelf ook eens iets mee te doen.
.oisyn Moderator Devschuur® @gimbal27 februari 2025 15:44
Het WebAssembly deel is echter niet zo relevant hier. Hij heeft een VM geimplementeerd in het Typescript type-systeem om code te kunnen draaien. Hij koos voor WebAssembly als te implementeren VM, maar hij had net zo goed x86 en DOS kunnen emuleren oid (nou ja, op zich niet "net zo goed", WebAssembly is een redelijk contained systeem dus ik snap die keuze wel)
Niet helemaal: hij heeft een webassembly runtime gemaakt die volledig draait in het TypeScript type systeem, dus de logica die er voor zorgt dat typering in Typescript werkt. Deze is zo flexibel dat je er code in kan schrijven.
Wikipedia: Type system

Dat is een orde grootte meer indrukwekkend dan een port naar TypeScript (waarvan er ook al een aantal zijn).

[Reactie gewijzigd door bzzzt op 27 februari 2025 10:02]

Om het spel te draaien, was wel flinke rekenkracht nodig: 177 terabytes aan TypeScript-types moeten twaalf dagen lang continu door TSC draaien om de game te kunnen booten en het eerste frame te zien.
Persoonlijk vind ik dit wel een erg ruim begrip voor de term "draaien". Per frame heb je dus 12 dagen en 177 TB aan TypeScript-types nodig. Compleet onspeelbaar dus!
Tijd is relatief, dat is het antwoord.
Het is juist een uitkomst voor drukke mensen die weinig tijd hebben om te gamen. Twee keer per maand kijk je naar Doom om te zien wat de volgende frame brengt, en af en toe geef je een input. Heerlijk Zen, en je kunt maandenlang genieten van een kill. :+
Je bent eerst maanden verder voordat je daadwerkelijk een kill hebt. Mocht je missen dan mag je weer een paar maanden wachten :|
Met 1 frame per 12 dagen wordt Doom trager dan de meeste play-by-mail schaakpartijen. Als je er dan nog in slaagt om te missen dan doe je het expres. :P
Nou.... ik heb eens zitten kijken en rekenen en de snelste speedrun van Doom is 8.93 seconden (we nemen even 9 seconden voor dit voorbeeld). Doom draait standaard op 35 fps.
9x35=315 frames moeten gerenderd worden

12 dagen per frame x 315 = 3.780 dagen = 540 weken = 10 jaar en 20 weken om 1 map uit te spelen.... :X
idd, iemand moet een definition of done specificeren om te bepalen of het draait.
Maar niemand zei dat het soepel draaide. Als dingen slecht draaien, draaien ze nogsteeds ;) .
Debuggen moet wel een nacht merry zijn,

Even 12 dagen wachten op frame heb je net je bug gemist omdat je stop te ver stond kun je weer 10 dagen wachten.
Dan render je interlaced, zodat je alsnog een volledige afbeelding met halve resolutie kan uitbrengen als halverwege blijkt dat de eerste helft corrupt is. :P

[Reactie gewijzigd door The Zep Man op 27 februari 2025 10:01]

ja wat moet je er van zeggen... meesterlijk gedaan sowieso... ik heb er geen kaas van gegeten maar kudo's!
Eindelijk een goede benchmark na Crysis, but will it run typescript type doom? :P
Aantonen dat iets onmogelijk is.


Tja dat kan niet. Onmogelijk betekend dat je nog niet snapt hoe het wel gedaan kan worden.
Dat zegt meer over jouw onbegrip. Twee even getallen vinden die optellen tot iets onevens? Onmogelijk. Een Turing-complete systeem simuleren in een niet Turing-complete systeem: onmogelijk. Onmogelijk betekent dat iets niet mogelijk is. Dat is iets heel anders dan "onbekend".
Uiteindelijk kom je uit bij bewijzen dat je wetenschap niet archaïsch is. Wie de meeste vrienden heeft, heeft altijd gelijk. :Y)
Die "kaders" noemen we "definities" of "axioma's". Het gaat hier om wiskunde, niet om, zeg, sneller dan het geluid vliegen, waar een praktische component aan zit. Die "kaders" zijn nou net het hele punt.

Iemand kan best "laten zien" hoe het "mogelijk" is dat "2 + 2 = 5", maar aangezien we het dan niet meer hebben over optelling van natuurlijke getallen maar over iets anders zijn we van de oorspronkelijke vraagstelling afgestapt.

Ofwel het TypeScript-typesysteem kon Doom draaien (en daarmee dus elk willekeurig computerprogramma), ofwel niet, omdat essentiële constructies ontbreken. Bewijs leveren van dat eerste kan door Doom te draaien (zoals hier gebeurd is), bewijs van dat tweede vergt het uitwerken van de stelling en bewijzen middels logica.
Ik kan als afgestudeerd natuurkundige bevestigen dat ook in de quantummechanica geen informatie sneller dan het licht reist. Zwarte gaten idem.

Dat is even los van het feit dat je niiet begrijpt wat een wiskundig axioma is. Natuurkunde is niet axiomatisch.

Het is ook bepaald geen natuurwet dat water kookt bij 100 granden. Natuurkundigen werken sowieso met Kelvin.
Zie hier weer de ontkennigheid van iemand die niet beter weet dus altijd zal ontkennen Dat is Pecies het punt wat ik maak en je altijd ziet je kunt iemand pas overtuigen als tegendeel bewezen is zolang je er niet voor open staat dat die persoon ook fout kan zijn.

bij kwantum kunnen we nogsteeds niet verklaren hoe 2 verstrengelde delen op afstand sneller dan het ligt elkaars status over nemen.

WHo cares of het nu kelvin , celcius of bobicles zijn het feit blijft dat men eerst uit ging van 100 graden en daarna pas uitvond dat het ook anders kan.

Je kunt God ook als een axioma beschouwen maar is dat dan waarheid tot dat bewezen is dat hij niet bestaat en wat als hij dan toch ineens voor de deur staat.
.oisyn Moderator Devschuur® @MneoreJ27 februari 2025 15:50
Bewijs leveren van dat eerste kan door Doom te draaien (zoals hier gebeurd is)
Tja, het was al bewezen dat typescript types Turing Complete waren, dus daarmee was al het bewijs al geleverd dat het in theorie kan. In de praktijk blijkt het niet te kunnen op standaard compilers omdat ze limieten definieren (zoals recursie) waar deze usecase ver overheen gaat. Hij heeft dan ook aanpassingen gemaakt aan de compilers om het wel aan te kunnen.

Daarmee wil ik overigens niet zijn toewijzing en prestaties bagatelliseren! Het is ronduit indrukwekkend wat hij gedaan heeft. Maar het bewijs was er in principe al.

[Reactie gewijzigd door .oisyn op 27 februari 2025 15:51]

Ik wil niet off-topic gaan, maar uw gebruik van Stam+T is in veel gevallen Stam+D geworden en dat leest niet lekker weg. Even Voltooid Deelwoord en Werkwoord er even bij pakken.
Naast dat de persoon het leuk vond, heeft deze er vast ook veel van geleerd. Het doel is niet dat een willekeurig persoon nu eindelijk Doom kan spelen op een complexe manier.
Je krijgt -1 omdat deze soort reacties jammer genoeg elke keer opnieuw de revue passeren. Dergelijke 'het draait Doom' - projecten zijn gewoon om aan te tonen dat het kan, het is een uitdaging, leerrijk voor de persoon zelf én wat die persoon doet met zijn tijd is volledig zijn zaak 👍🏻.
Ja de kreet “kreet waste of time” soms heb je de neiging om helemaal ge-obsedeert te zijn in hypothese wat je gaat onderzoeken en tijd in stopt. Soms zijn thema waar hypothese geen praktisch nut heeft.
Dus de stelling zou beter zijn wat heb je hier aan.
Ik heb wel hypothese wat wel praktijk waarde heeft.
Kunnen games wel ontwikkeld worden door goed Multithreaded cpu en al hun cores goed te gebruiken. Alsof je de lasso tool al geïntegreerd heb.
Hypothese 2 next innovatie van FPS genre.

Sommige pro tools op Mac gebruiken alleen de big cores andere alle cores.

Hypotesen zijn leuk. Het bewijzen van. Sommige hebben praktisch nut andere geen nut. Deze is van laatste soort.

Op dit item kan niet meer gereageerd worden.