[HN Gopher] Quandoom: A port of DOOM for a quantum computer
___________________________________________________________________
Quandoom: A port of DOOM for a quantum computer
Author : lgtx
Score : 117 points
Date : 2024-09-29 15:04 UTC (1 days 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.
| xelxebar wrote:
| I just had to see that:
| https://ifdb.org/viewgame?id=lkr2jf03np19ieix It's playable
| online and quite well done!
| anthk wrote:
| A pity is not libre; if if were I could make a few more
| levels for it as the Inform6 language it's literally a
| dumbed down OOP language (except for the non-
| English/Spanish grammar library methods/commands, the ones
| made in Inform6 itself) and the objects in the game are
| self-explanatory to code. Really simple, even a 10 year old
| could make a shortish game.
| 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
| stevekemp wrote:
| The Z-machine could run under 64k or RAM, or less, back in
| the day.
|
| 1GB is probably more than you'd need to store all the Infocom
| releases!
| anthk wrote:
| I know, there are even ports for the original Game Boy (not
| even the Color, the less powerful B/W one). I ran Calypso
| and Tristam Island on these as an experiment.
|
| But I meant 1GB for the quantum computer OFC.
| 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
| gsck wrote:
| "No Fair! You changed the outcome by measuring it!"
| 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.
| nunobrito wrote:
| Including Quantum Sound Blaster(tm)
| toast0 wrote:
| Gameboy wasn't black and white, it was a mushy greenish gray.
| Thank you very much. I've seen some nice monochrome screens
| with 8-bit depth, but the Gameboy was only 2-bits. Maybe you
| could do some time based dithering...
| 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?
| kqr wrote:
| Layman speculating, but wouldn't occlusion throw away
| visual data? Discarding data is disallowed because it
| breaks reversibility.
|
| Though I'm not sure about this becuase I would guess the
| current implementation also discards data where wireframes
| intersect.
| bmacho wrote:
| So by 'reversibility' they mean that good graphics would
| require too much memory (bc quantum can't reuse memory as
| traditional computers do), and we don't have the resources
| for that yet.
| bawolff wrote:
| Quantum computers are a superset of normal computers, so im not
| sure what the fuss is here.
| djha-skin wrote:
| This is not strictly correct.
|
| Quantum computers can do some things normal computers can't,
| but the reverse is also true.
| ttshaw1 wrote:
| I don't think that's true. What's your example? As far as I
| know any operation on a classical computer can be emulated on
| a quantum computer in some short amount of time; constant
| time, maybe.
| thrance wrote:
| Getting your quantum computer to do a classical task (and
| actually simulating it) is far from easy.
| 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.
| kqr wrote:
| > 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.
|
| I'm also wondering how much of the computation is really ...
| quantum? I.e. is _anything_ in superposition, phase shifted,
| entangled, etc.?
|
| This looks to me like it's entirely relying on reversible
| classical logic gates. Impressive! But not quantum computing on
| its own.
| ranger_danger wrote:
| the most important file (the .qasm) is missing from the repo...
| reikonomusha wrote:
| The most important code would be that which generated the .qasm
| file. That's not included in the repo, just the "compiled"
| result and a little program to run it. The code generator will
| look like a conventional C++ program that turns geometry
| operations (like line drawing) into subroutines which are
| written out to the .qasm file. There's no point to commit
| generated code to the repo.
|
| The .qasm file can be found in the downloads/releases section.
| pjmlp wrote:
| I know that it is only the early days of quantum, and this is
| already a marvellous achievement given the current state of the
| technology, however I wonder how well a quantum computer will
| eventually be able to render a ray tracing version.
___________________________________________________________________
(page generated 2024-09-30 23:02 UTC)