Suche
Beiträge, die mit ascii getaggt sind
Porting Doom to Typescript Types took 3.5 Trillion Lines, 90GB of RAM and a full Year of Work.
The feat was devised by Software Engineer Dmitri Mitropoulos, founder of Michigan Typescript and co-founder of Squiggleconf. He released a video showcasing the results of a year-long effort to get Doom running inside of Typescript's Types system.
https://youtu.be/0mCsluv5FXA
#doom #port #typescript #programming #ascii #art #engineer #media #retro #gaming #history #tech #artist #news
![[ImageSource: Dmitri Mitropoulos]
Typescript is a language built on top of Javascript, that add static typing to catch many errant mistakes before your executes, think of it as guardrails which check that functions and other variables are being used correctly. While this is commonly used in all kinds of development, it's unheard of to run a game within Typescript's Type system.
The port itself runs inside three and a half trillion lines of types, totalling a gargantuan size of 177 TB. This is run through Typescript's Type tracker, which takes 12 days to compile the first frame of Doom (0.0000009645 fps). This meant that 20 million type instantiations were running every second in order to get the output.
Mitropoulos explained in the Michigan TypeScript Discord server that this could be improved to take "1 to 12 hours", as long as someone works on it, with the developer noting that he has notes for where potential performance optimizations could be made.
<https://discord.gg/pfKUSmSY>
This was done by running the project within a custom WASM runtime, which is then processed through Typescript within an editor to display a frame.
<https://github.com/MichiganTypeScript/typescript-types-only-wasm-runtime>](https://friendica-leipzig.de/photo/preview/600/769722 "[ImageSource: Dmitri Mitropoulos]
Typescript is a language built on top of Javascript, that add static typing to catch many errant mistakes before your executes, think of it as guardrails which check that functions and other variables are being used correctly. While this is commonly used in all kinds of development, it's unheard of to run a game within Typescript's Type system.
The port itself runs inside three and a half trillion lines of types, totalling a gargantuan size of 177 TB. This is run through Typescript's Type tracker, which takes 12 days to compile the first frame of Doom (0.0000009645 fps). This meant that 20 million type instantiations were running every second in order to get the output.
Mitropoulos explained in the Michigan TypeScript Discord server that this could be improved to take \"1 to 12 hours\", as long as someone works on it, with the developer noting that he has notes for where potential performance optimizations could be made.
<https://discord.gg/pfKUSmSY>
This was done by running the project within a custom WASM runtime, which is then processed through Typescript within an editor to display a frame.
<https://github.com/MichiganTypeScript/typescript-types-only-wasm-runtime>")
![Dmitri Mitropoulos further explained that each value within the Typescript Types system equates to a line of pixels [totalling 128,000 lines of pixels in total], resulting in a "resolution" of 320x200, displayed in ASCII.
To do this, the developer needed to remove limitations within the Typescript compiler itself, highlighting just how large the project got, with the Type tracker runtime consuming over 90 GB of RAM while it was running.
This huge overhead meant that common tools within Typescript could not be used, which meant that the herculean task of encoding every element of Doom in types. This required learning to develop elements like an L1 CPU cache, within Typescript Types itself. Due to Typescript requiring iteration on a single string from the left-hand side, binary algorithms had to be input in reverse.
"Oh, and AI can't help" Dmitri Mitropoulos added, describing that the work was so low level that AI couldn't possibly assist with any of the tasks. Too bad, Grok 3.
Mitropoulos said that he undertook the challenge after completing "every other" Types challenge, and wanted to understand why Doom wouldn't be able to run within Types. However, he managed to find "ridiculous" workarounds to make it all work, despite his own disbelief in the project.](https://friendica-leipzig.de/photo/preview/600/769724 "Dmitri Mitropoulos further explained that each value within the Typescript Types system equates to a line of pixels [totalling 128,000 lines of pixels in total], resulting in a \"resolution\" of 320x200, displayed in ASCII.
To do this, the developer needed to remove limitations within the Typescript compiler itself, highlighting just how large the project got, with the Type tracker runtime consuming over 90 GB of RAM while it was running.
This huge overhead meant that common tools within Typescript could not be used, which meant that the herculean task of encoding every element of Doom in types. This required learning to develop elements like an L1 CPU cache, within Typescript Types itself. Due to Typescript requiring iteration on a single string from the left-hand side, binary algorithms had to be input in reverse.
\"Oh, and AI can't help\" Dmitri Mitropoulos added, describing that the work was so low level that AI couldn't possibly assist with any of the tasks. Too bad, Grok 3.
Mitropoulos said that he undertook the challenge after completing \"every other\" Types challenge, and wanted to understand why Doom wouldn't be able to run within Types. However, he managed to find \"ridiculous\" workarounds to make it all work, despite his own disbelief in the project.")
The feat was devised by Software Engineer Dmitri Mitropoulos, founder of Michigan Typescript and co-founder of Squiggleconf. He released a video showcasing the results of a year-long effort to get Doom running inside of Typescript's Types system.
https://youtu.be/0mCsluv5FXA
#doom #port #typescript #programming #ascii #art #engineer #media #retro #gaming #history #tech #artist #news
![[ImageSource: Dmitri Mitropoulos]
Typescript is a language built on top of Javascript, that add static typing to catch many errant mistakes before your executes, think of it as guardrails which check that functions and other variables are being used correctly. While this is commonly used in all kinds of development, it's unheard of to run a game within Typescript's Type system.
The port itself runs inside three and a half trillion lines of types, totalling a gargantuan size of 177 TB. This is run through Typescript's Type tracker, which takes 12 days to compile the first frame of Doom (0.0000009645 fps). This meant that 20 million type instantiations were running every second in order to get the output.
Mitropoulos explained in the Michigan TypeScript Discord server that this could be improved to take "1 to 12 hours", as long as someone works on it, with the developer noting that he has notes for where potential performance optimizations could be made.
<https://discord.gg/pfKUSmSY>
This was done by running the project within a custom WASM runtime, which is then processed through Typescript within an editor to display a frame.
<https://github.com/MichiganTypeScript/typescript-types-only-wasm-runtime>](https://nerdculture.de/system/media_attachments/files/114/166/740/010/112/784/original/f54d5e08b8f270ce.png "[ImageSource: Dmitri Mitropoulos]
Typescript is a language built on top of Javascript, that add static typing to catch many errant mistakes before your executes, think of it as guardrails which check that functions and other variables are being used correctly. While this is commonly used in all kinds of development, it's unheard of to run a game within Typescript's Type system.
The port itself runs inside three and a half trillion lines of types, totalling a gargantuan size of 177 TB. This is run through Typescript's Type tracker, which takes 12 days to compile the first frame of Doom (0.0000009645 fps). This meant that 20 million type instantiations were running every second in order to get the output.
Mitropoulos explained in the Michigan TypeScript Discord server that this could be improved to take \"1 to 12 hours\", as long as someone works on it, with the developer noting that he has notes for where potential performance optimizations could be made.
<https://discord.gg/pfKUSmSY>
This was done by running the project within a custom WASM runtime, which is then processed through Typescript within an editor to display a frame.
<https://github.com/MichiganTypeScript/typescript-types-only-wasm-runtime>")
![Dmitri Mitropoulos further explained that each value within the Typescript Types system equates to a line of pixels [totalling 128,000 lines of pixels in total], resulting in a "resolution" of 320x200, displayed in ASCII.
To do this, the developer needed to remove limitations within the Typescript compiler itself, highlighting just how large the project got, with the Type tracker runtime consuming over 90 GB of RAM while it was running.
This huge overhead meant that common tools within Typescript could not be used, which meant that the herculean task of encoding every element of Doom in types. This required learning to develop elements like an L1 CPU cache, within Typescript Types itself. Due to Typescript requiring iteration on a single string from the left-hand side, binary algorithms had to be input in reverse.
"Oh, and AI can't help" Dmitri Mitropoulos added, describing that the work was so low level that AI couldn't possibly assist with any of the tasks. Too bad, Grok 3.
Mitropoulos said that he undertook the challenge after completing "every other" Types challenge, and wanted to understand why Doom wouldn't be able to run within Types. However, he managed to find "ridiculous" workarounds to make it all work, despite his own disbelief in the project.](https://nerdculture.de/system/media_attachments/files/114/166/742/069/675/680/original/110e43577d22fe1d.jpeg "Dmitri Mitropoulos further explained that each value within the Typescript Types system equates to a line of pixels [totalling 128,000 lines of pixels in total], resulting in a \"resolution\" of 320x200, displayed in ASCII.
To do this, the developer needed to remove limitations within the Typescript compiler itself, highlighting just how large the project got, with the Type tracker runtime consuming over 90 GB of RAM while it was running.
This huge overhead meant that common tools within Typescript could not be used, which meant that the herculean task of encoding every element of Doom in types. This required learning to develop elements like an L1 CPU cache, within Typescript Types itself. Due to Typescript requiring iteration on a single string from the left-hand side, binary algorithms had to be input in reverse.
\"Oh, and AI can't help\" Dmitri Mitropoulos added, describing that the work was so low level that AI couldn't possibly assist with any of the tasks. Too bad, Grok 3.
Mitropoulos said that he undertook the challenge after completing \"every other\" Types challenge, and wanted to understand why Doom wouldn't be able to run within Types. However, he managed to find \"ridiculous\" workarounds to make it all work, despite his own disbelief in the project.")
