[HN Gopher] Porting Doom to a/UX
___________________________________________________________________
Porting Doom to a/UX
Author : soopurman
Score : 52 points
Date : 2022-06-08 17:07 UTC (5 hours ago)
(HTM) web link (katelibc.medium.com)
(TXT) w3m dump (katelibc.medium.com)
| pinewurst wrote:
| I want to see Doom for Multics.
| kinghajj wrote:
| Why stop there? Doom on the Analytical Engine!
| asveikau wrote:
| I was disappointed to see the git history. A single giant commit.
|
| She should have imported the source code unmodified as a first
| commit and tracked her work.
| selimnairb wrote:
| In retrospect, it's kind of mystifying that Apple didn't merge
| A/UX and System 7 into a next-gen OS.
| duskwuff wrote:
| They _tried_. There were multiple death-march projects to
| modernize classic Mac OS, like Taligent and Copland; all of
| them failed.
| Comevius wrote:
| There is a port called FastDoom that could serve as inspiration
| for achieving better performance.
|
| https://github.com/viti95/FastDoom
|
| There is also the official SNES port for the faster Super FX
| GSU-2 chip running at 21 Mhz.
|
| https://github.com/RandalLinden/DOOM-FX
| rzzzt wrote:
| When porting to SerenityOS, Andreas used a Doom flavor that
| required very few platform-specific changes to make it run:
| https://github.com/ozkl/doomgeneric
| classichasclass wrote:
| The SFX Doom is a lot of assembly. I think the official Lion
| port of Doom to the Mac uses a lot of assembly too. (Heck,
| plenty of it in the original.) 68K isn't hard to write in, and
| I think any fast implementation on hardware of this spec won't
| be able to avoid it.
| andrewf wrote:
| A third renderer that exists is the assembly for the official
| Jaguar port. I think Carmack wrote it? It's staged, like a
| really old C compiler, because the Jaguar's faster processors
| could only execute programs from a tiny scratchpad memory.
| https://github.com/Arc0re/jaguardoom/blob/master/r_phase1.ga...
|
| I think Rebecca Heineman ported this back to C for the official
| 3DO port. https://github.com/Olde-
| Skuul/doom3do/blob/master/source/pha...
| tpmx wrote:
| This _seems_ implausible at first: A 34 year old Unix-based
| platform with no previous Doom port. I spent a few minutes
| furiously googling this, pulling out all of my tricks. Nope. I
| couldn 't find a previous port. Please someone else try it. There
| _must_ be one, right? I want to live in universe that makes
| sense.
| hedgehog wrote:
| It makes a little more sense knowing that A/UX install media
| was hard to find for a long time, until recently (2021?) there
| were no compatible emulators, and a lot of the real hardware is
| probably too slow to run Doom or has too little memory to do
| the build.
| jandrese wrote:
| Also, the real hardware was both rare and fairly expensive so
| the community is further restricted. I wouldn't be surprised
| to learn that Doom was never ported to stuff like TANDEM
| mainframes either.
| tpmx wrote:
| Also:
|
| https://twitter.com/id_aa_carmack/status/134079486105060556
| 8
|
| > AFAIK, nobody ever ported Doom to run on a Cray 1. The
| scalar CPU should be fast enough (in 1976!) to draw
| 320x200, but memory would be an issue because it wasn't
| byte addressable -- you could only load and store aligned
| 64 bit values, and a max of 1M elements would be a pinch.
|
| > You could burn instructions to shift and mask on the low
| order address bits, but a faster path would be to
| interleave 8 independent textures at different bit
| positions in the words, and have specialized texture
| mapping routines with a constant shift and mask. I don't
| recall ever considering that arrangement, but there may
| have been relevant consumer systems where doing it for 2 or
| 4 bit textures packed in bytes would have been helpful.
|
| > Figuring out how to best exploit chained vector
| instructions for texture mapping on the Cray would be phase
| two.
| cptnapalm wrote:
| I love John Carmack.
| tenebrisalietum wrote:
| So this would be like making Doom run entirely with SIMD
| instructions?
| jandrese wrote:
| Not entirely, but it sounds like you might need to
| rewrite parts of it in a SIMD manner to make it
| performant.
|
| The memory thing might be an issue, but I remember Doom
| was ported to the SNES which only had 128kB of RAM and a
| 3.5Mhz CPU. While that was a heroic hack, it leaves a lot
| of possible overhead for a Crey-1 port with 1 million
| words addressable and an 80Mhz clock.
| classichasclass wrote:
| Well ... not quite. SNES Doom had a co-processor
| (SuperFX) doing the work. Even with that it had a lot of
| compromises to work on the hardware.
| asveikau wrote:
| You could probably run the 68k mac port unmodified on a/ux.
| A/ux ran contemporaneous Mac binaries unmodified.
|
| (Source: I have a quadra with a/ux i haven't touched in about
| 10 years)
| Maursault wrote:
| I wonder why the Mac port of Doom, November 4, 1994, doesn't
| run on A/UX in the compatibility layer, Macintosh Application
| Environment (MAE). If it does, then that is why.
___________________________________________________________________
(page generated 2022-06-08 23:01 UTC)