[HN Gopher] Quandoom: A port of DOOM for a quantum computer
       ___________________________________________________________________
        
       Quandoom: A port of DOOM for a quantum computer
        
       Author : lgtx
       Score  : 70 points
       Date   : 2024-09-29 15:04 UTC (7 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | srbhr wrote:
       | I really like these doom ports. As if they've become a standard
       | to learn, try something new and let others test it out. We had
       | entirely AI generated DOOM and now DOOM for quantum computer.
       | Maybe let's try a Doom in Go which is fully CLI? :-)
        
         | rkagerer wrote:
         | _AI generated DOOM_
         | 
         | Was that discussed on HN? How well did it replicate the
         | original game, and what were the subtle defects?
        
           | gl-prod wrote:
           | https://news.ycombinator.com/item?id=41375548
        
         | anthk wrote:
         | There's a port of Quake for the Z-Machine, but just the first
         | level.
        
         | egypturnash wrote:
         | it's in C but this was the first result for "ascii doom":
         | https://github.com/wojciech-graj/doom-ascii
         | 
         | There's also Doom in Notepad:
         | https://arstechnica.com/gaming/2022/10/how-to-get-doom-runni...
        
       | leshokunin wrote:
       | "Please note - it will use about 5-6 GB of ram and take a while
       | to load since it's a very large circuit file."
       | 
       | I love it. So absurd. 200 years from now people will be running
       | Doom on artificial black holes or programmable matter and the
       | readmes will be pretty much the same.
        
         | anthk wrote:
         | Meanwhile, you can run the Z-Machine, at least up to v3 games
         | (most of Infocom games) under a PostScript interpreter like
         | PostScript.
         | 
         | So, it might run under 1GB or ram and less.
        
           | jl6 wrote:
           | Next up: Doom running on this Z Machine:
           | https://en.wikipedia.org/wiki/Z_Pulsed_Power_Facility
        
       | jidar wrote:
       | I both have and have not beaten quandoom.
        
         | Dilettante_ wrote:
         | Pics or it is in a super-position of happened/didn't happen
        
         | 7bit wrote:
         | I think the correct quantum name would be: woop
        
       | hi-v-rocknroll wrote:
       | I'm both glad and slightly disappointed it doesn't use
       | aalib(-patched).[0]
       | 
       | 0. https://github.com/billagee/aalib-patched
        
       | lenerdenator wrote:
       | If something opens up a portal to hell, it's gonna be this.
        
       | theginger wrote:
       | I was all on board until I saw the video. Black and white! Has
       | this been designed for a quantum gameboy? I don't think you can
       | claim this to be truly useful until you've achieved 8 bit colour
       | depth.
        
         | philjackson wrote:
         | Quantum CGA will be mind-blowing.
        
       | bmacho wrote:
       | What is all the "reversibility" the readme is talking about? How
       | are non x-ray walls, reversibility and quantum connected?
        
         | aardvark179 wrote:
         | Generally all quantum computing operations have to be
         | reversible at the gate level, so you can't have a simple thing
         | like an AND gate, and this can make things more complex. As you
         | either need to put some out put to a qubit you don't care
         | about, or find some other way to handle it.
        
         | sakras wrote:
         | Basically, quantum gates are mathematically represented as
         | multiplying your state by unitary matrices. Unitary matrices
         | are ones where their inverse is their own conjugate transpose
         | (i.e. XX*=I). Since each gate has an inverse, for any
         | computation you can reverse it (in other words find a circuit
         | that recovers the inputs from the outputs).
         | 
         | In practice this means that you sometimes have to keep around
         | extra bits called Ancilla bits that just contain garbage, but
         | are necessary for reversibility.
        
           | pyrolistical wrote:
           | But what does this have to do with it being xray?
        
       | bawolff wrote:
       | Quantum computers are a superset of normal computers, so im not
       | sure what the fuss is here.
        
       | Strilanc wrote:
       | The interesting part of this project is compiling doom into a
       | weird target architecture: a .qasm circuit file. This requires
       | you to do things like decompose additions into TOFFOLI gates. But
       | the code in the repo doesn't include that part, it only includes
       | the code for interpreting the circuit and the produced qasm file.
       | 
       | The author is aware of this (from the readme):
       | 
       | > _For now I 'm still tidying up the engine code, but basically I
       | have about 8,000 lines of c++ functions allowing a number of
       | reversible binary and arithmetic operations on quantum registers,
       | for example "flipIfLessThanOrEqualTo" which flips all qubits in a
       | register if the value of another register is less than some given
       | value. Everything is done with integers._
       | 
       | Kinda ironic they left out the most interesting part.
       | 
       | Given that there's only 174 qubytes of storage (72376 qubits
       | total - 6986 qubits ancilla - 64Kqb screen) it's clear that
       | almost the entire world state is in the series of gates rather
       | than in qubits. So, like, the wall locations are probably
       | implicit in the series of instructions rather than being data-
       | driven, so you wouldn't be able to make a wall that was in a
       | superposition of two places. It would be interesting if the
       | author said what specifically was in the qubits; I'd imagine it's
       | probably things like health/ammo/position/enemyposition but an
       | explicit list would be good.
       | 
       | They say this is a reimplementation of Doom, as opposed to a
       | cross compilation. That makes sense to me. For example, I doubt
       | there's anything like a tree data structure anywhere in the
       | rendering, since that stuff doesn't really translate from
       | programs to circuits. Tree structures work efficiently around the
       | fetch-decode-execute bottleneck, but circuits lack that
       | bottleneck. Also, a "true" quantum implementation of the
       | rendering would struggle to do any kind of truncation of what to
       | render since the camera position can be in superposition.
       | Frustrum culling would implicitly measure the position of the
       | camera, preventing some potential interference effects, and so
       | would be an approximation instead of a pure optimization.
       | 
       | From a high level view there's not much point in allowing most of
       | doom's state to be in superposition, since constantly rendering
       | them to the screen measures them preventing interesting
       | interference effects. You could maybe make it so that enemies in
       | rooms not being rendered were undergoing a quantum walk, so their
       | positions behaved sort of analogous to an electron in a potential
       | well. So entering the room at different times would result in
       | different distributions of positions.
        
       | ranger_danger wrote:
       | the most important file (the .qasm) is missing from the repo...
        
       ___________________________________________________________________
       (page generated 2024-09-29 23:01 UTC)