[HN Gopher] Doom for 16-bit DOS computers
___________________________________________________________________
Doom for 16-bit DOS computers
Author : elvis70
Score : 101 points
Date : 2023-08-31 16:04 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ArtWomb wrote:
| How can multi-player be ported to https://dos.zone/ ? WebUDP ??
| extraduder_ire wrote:
| According to another comment, this is based on GBA doom.
| Dos.zone seems to already support multiplayer, so it should be
| as simple as implementing (probably copying in) the multiplayer
| part to replace the link cable functionality.
| aidenn0 wrote:
| I can't easily tell; does it still require VGA or MCGA to run?
| iguessthislldo wrote:
| I was wondering that as well since Wolfenstein got a CGA port:
| https://github.com/jhhoward/WolfensteinCGA
|
| The CGA mode is playable, but pretty bad looking as would be
| expected. It looks much better with the Tandy graphics mode
| enabled. It'd be cool to be able to run Doom on my Tandy 1000
| as well.
| molticrystal wrote:
| While i haven't tried it, there is code that sets it to mode
| 0x13 [0][1] so it would be VGA.
|
| [0]
| https://github.com/FrenkelS/Doom8088/blob/2001f8c2576a2e99f3...
|
| [1] https://en.wikipedia.org/wiki/Mode_13h?useskin=vector
| jonny_eh wrote:
| > It's based on GBADoom
|
| I wonder why. The GBA has a 32-bit ARM processor.
| speps wrote:
| Not all projects have #defines for pointer and type sizes, or
| hardcode values for these sprinkled through the code. So
| probably to port to GBA they had to go through the code and fix
| these. Now this specific codebase of Doom is better suited for
| other ports as well.
| monocasa wrote:
| Probably better matches the makeup of RAM and processor speed.
| The GBA only has 384KB and runs at 12.5MHz.
| AnotherGoodName wrote:
| Also a quick background and the GBA port is a port of the
| jaguar port which is a port of the SNES port.
|
| So somewhere in that heritage is the SNES version of doom. A
| 16bit version.
| rocky1138 wrote:
| I took this to mean the assets rather than the code.
| CamperBob2 wrote:
| [flagged]
| devit wrote:
| Well, it's going to look like normal Doom.
| jylam wrote:
| For everyone here, this quote is not a quote. CamperBob2 just
| wanted to bully someone it seems, because they doesn't seem to
| value neither time or skills over quick entertainment for
| themselves. Next time, just ignore the post and get your tiktok
| shot.
| CamperBob2 wrote:
| _Next time, just ignore the post._
|
| Excellent advice.
| rado wrote:
| Yes, it makes no sense
| hypercube33 wrote:
| I see these cool or potentially cool projects posted once a
| week here without screenshots or even documentation sometimes.
| I too do not understand.
| schemescape wrote:
| It's possible someone else just ran across the repository and
| submitted it to HN, but the author wasn't ready to share the
| project yet. I've seen that happen several times.
| jonhohle wrote:
| The documentation one get me, especially with GitHub repos.
| Don't show me all your build status widgets and give me build
| instructions before ever (or without even) telling me what
| the project does.
| ido wrote:
| We should demand our money back!
| extraduder_ire wrote:
| I think most times this happens because the description of
| the project is hosted elsewhere, and github is primarily
| thought of as a way to host the files for download. I see
| this a lot with projects that only link to the /releases/
| page, especially when the code itself is not open source.
|
| Or, they're just too close to the project and the idea that
| someone would have to read the readme completely slips
| their mind.
| erkkonet wrote:
| For those that wonder how it looks, I found a video:
|
| https://twitter.com/FOmmetje/status/1696266683756003451
|
| or if you prefer:
|
| https://nitter.net/FOmmetje/status/1696266683756003451
| ChrisArchitect wrote:
| When I hear 8088 I'm picturing like an IBM PC original from
| like 1981, so seeing the video of this running on a _286_ isn
| 't as impressive in the end.
| rograndom wrote:
| Doom barely ran on 386s and lower 486s, so running at all on
| a 286, let alone better than most any 386, is pretty
| impressive to me.
| gwbas1c wrote:
| Looks just like the DOS Doom that I played in the 1990s
| thecatspaw wrote:
| surprisingly smooth considering that its reading all the
| textures from disk every frame
| JohnBooty wrote:
| Yeah, that's wild.
|
| I imagine that on a physical vintage PC with a spinning rust
| hard drive (rather than in an emulator with storage
| presumably backed by an SSD) we'd be looking at a 1fps
| slideshow or less.
|
| But, maybe I'm wrong! Maybe things would fit into the HDD's
| onboard cache and it would perform OK.
| deadlyllama wrote:
| Ha ha ha onboard anything
|
| PCs of a sufficient vintage had so little logic on the HDD
| that you could swap out the MFM controller card in your PC
| for an RLL one and get 50% more storage. The modulation of
| the signal written to the disk was the job of the
| controller card, not the board on the HDD. Turn your 20MB
| HDD into a 30MB with a controller change and reformat?
| Mighty tempting.
| Narishma wrote:
| But why is it doing that?
| apricot wrote:
| The video is running at 15x, though...
| iancmceachern wrote:
| Looks about how wolfenstein 3d ran on my 286 Tandy 1000 rlx.
| Luckily you could reduce the graphics window size and
| dramatically improve performance
| agentdrek wrote:
| Doom will soon have been ported to more hardware than NetBSD!
| temporallobe wrote:
| But wasn't Doom originally developed for "16-bit DOS computers"?
| That's the way I originally played it, by installing it from 3.5"
| floppies as a DOS program on my Windows 3.11 PC, although it was
| a 486/33 IIRC. I could play the entire game, save my progress,
| and I had sound via SoundBlaster. In fact, I even installed Doom
| II on that same computer.
| jezze wrote:
| One thing I remember was that DOOM did not run well on the
| 486SX. You needed the 486DX which had an FPU. Maybe there was a
| 486DX with 33mhz but most were 66mhz I think?
| feiss wrote:
| I played Doom in my 486sx 25mhz..
| sillywalk wrote:
| If I recall, the 486-SX was a DX with the FPU disabled (or it
| was defective). There were 25,& 33MHZ versions.. I think the
| 66MHZ were "DX2"
| miohtama wrote:
| You are confusing Doom with Quake.
|
| Doom run okish on 486SX.
| mrob wrote:
| "okish" by 1993 standards, but not a solid 35fps with full
| detail and full viewport size. Of course, that didn't stop
| people from enjoying it.
| mrob wrote:
| Doom uses fixed point math so it doesn't matter if you have
| an FPU. But the fastest 486SX was only 33MHz, which isn't
| really fast enough for Doom, and they were typically used in
| cheaper systems with slower graphics cards/buses, which also
| made a big difference.
| Facemelters wrote:
| 486DX2/66 checking in
| selimnairb wrote:
| 486DX2/66 with VLB S3 Vision864 checking in
| Bellyache5 wrote:
| I played Doom on my 486DX 33MHz.
| nxobject wrote:
| I thought it was originally developed on 32-bit 68k NeXT
| workstations, no? I would be interested if there was anywhere
| to learn how the porting to x86 went, especially with regards
| to different strategies for block transfers/etc.
| sillywalk wrote:
| It wasn't really "ported", is was developed _on_ NeXTStep,
| but the target was X86 /VGA/DOS"
|
| Apparently they just cross-compiled it. Also, the NeXTStep
| version of Doom didn't have sound.
|
| "We wrote all of DOOM and Quake's code on NeXTSTEP. We
| debugged the code in NeXTSTEP with DOOM and Quake's 320x200
| VGA screen drawing in a little Interceptor window while the
| rest of the screen was used for debugging code. When all the
| code ran without bugs we cross-compiled it for the Intel
| processor on NeXTSTEP then turned over to our Intel DOS
| computers, copied the EXE and just ran the game. The DOS4GW
| DOS-Extender loaded up and the game ran. It was that easy."
|
| http://web.archive.org/web/20140310124554/http://rome.ro/200.
| ..
| tredre3 wrote:
| Id Software's history at that point (commander keen,
| wolfenstein, catacomb, doom) was entirely on x86 MS-DOS and
| they were exploiting all the tricks to achieve decent
| performance for games thought to not be possible on that
| platform.
|
| So it seems very unlikely (to me) that they would develop the
| games first for a different platform, using a different OS,
| on a different CPU, with a different endianness.
| xcv123 wrote:
| They developed Doom on NeXT with highly portable C code.
| The reason for that is they were more productive on NeXT
| workstations (development and map design). Doom has been
| easily ported to every platform because they designed it to
| be easily ported. Recommended reading:
| https://fabiensanglard.net/gebbdoom/
| syntheweave wrote:
| The difference is that the id devs had already come from
| the Apple II world first, so they had written plenty of
| 6502 assembly and were aware of the cycle counting types of
| optimizations, but chose to give some of them up to use C
| when they started on x86. That was, at the time, a
| relatively bold move.
|
| By the time Doom was being made they definitely had a sense
| of what a high-level approach brought to the table, and
| that they could focus on just the "hot loops" for micro-
| optimization when targeting a 386. The process they were
| using to build their engine was ultimately iterative in
| nature, building some tools and some rendering and some
| assets, then gradually pushing each a little further: the
| introduction of the BSP algorithm came relatively late, for
| example.
| [deleted]
| tom_ wrote:
| That is exactly what they did. It's discussed in the
| Masters of Doom book, as I recall.
| sjm-lbm wrote:
| Doom used a DOS 32 bit extender called DOS/4GW:
| https://en.wikipedia.org/wiki/DOS/4G.
| pavlov wrote:
| The 486 is a 32-bit CPU, like the 386 before it. Doom's
| official minimum system requirement was a 486/66MHz.
| mrob wrote:
| Mobygames has a scan of the packaging:
|
| https://www.mobygames.com/game/1068/doom/cover/group-1549/co.
| ..
|
| "System Requirements: PC compatible 386 or greater"
|
| But unofficially, you needed a fast 486 to run it properly.
| On a 386 you have to switch to low detail mode and/or shrink
| the view area to get an acceptable frame rate.
| JohnBooty wrote:
| I seem to remember having a good time with it on a 386SX
| 20mhz. If I am remembering correctly (I have about 75%
| confidence in these memories) I just dialed down the view
| area by a notch or two which worked well for _most_ of the
| game until I got to an area with a looot of monsters.
|
| It was pretty tolerable since quicksave and quickloads were
| so fast. If you stumbled into an area where you took a
| bunch of damage because your frame rate dropped to 5fps you
| could just quickload, downsize the viewport, and try again.
| justsomehnguy wrote:
| Only if you somehow time traveled and brought a FAST DOOM
| source port with you.
|
| 386SX 20MHz no cache: https://youtu.be/osgld_uynl8?t=95
|
| 486SX 8KB cache: https://youtu.be/osgld_uynl8?t=151
|
| 386DX 40MHz 8MB RAM: https://youtu.be/9_2qGaIOvjs
|
| 386DX 33MHz 8MB RAM ET4000:
| https://youtu.be/KQDEKoRcXZc?t=140
|
| 386DX 40MHz 4MB RAM 256KB cache (probably bullshit), full
| viewport: https://youtu.be/L6U8fyEgRH4
|
| Notice how it's fine in the corridors but starts to lag
| at any open space. There was a reason DOOM/2 got it map
| design.
| [deleted]
| chrisco255 wrote:
| Does anyone know of any compact Doom wasm examples? Looking for
| the tiniest Doom that could run in a web browser.
| idonotknowwhy wrote:
| Doom ran on the 16 bit SNES console
| MBCook wrote:
| > Super slow because for every frame every necessary image is
| read from the hard disk and for every calculation involving a
| lookup table the hard disk is also accessed
|
| The 8086 was limited to 640k, a 286 could actually do 16MB with
| paging.
|
| Is the problem simply the ram limit on the 8086? Is that why
| assets have to be reloaded off disk constantly?
|
| Couldn't a 286 with enough memory handle it (if you were
| emulating that processor)?
|
| I'm curious what the issue is.
| Narishma wrote:
| Even an 8088 could use more than 640kB through paging with EMS
| add-on cards. A 286 doesn't even require paging to use up to
| 16MB.
| basementcat wrote:
| Adding EMS support is on the issue list.
| https://github.com/FrenkelS/Doom8088/issues/1
___________________________________________________________________
(page generated 2023-08-31 23:00 UTC)