[HN Gopher] Why fastDOOM is fast
___________________________________________________________________
Why fastDOOM is fast
Author : wicket
Score : 262 points
Date : 2025-03-04 19:05 UTC (3 hours ago)
(HTM) web link (fabiensanglard.net)
(TXT) w3m dump (fabiensanglard.net)
| ge96 wrote:
| > I always wanted as a teenager but could never afford
|
| Funny how that is, for me it was a Sony Alpha camera (~~flagship
| at the time~~) and 10 years later I finally buy it for $50.
| fabiensanglard wrote:
| It looks gorgeous and compact (https://m.media-
| amazon.com/images/I/61kHENeCK8L._AC_SL1000_....).
| ge96 wrote:
| Yeah I was not exposed to camera gear at that time but seeing
| the NEX series with the tiny body and massive lens, I wanted
| it.
|
| I know there are better cameras in the Alpha line but yeah, I
| had an R3 at one point which was wasted on me as an amateur.
| ndegruchy wrote:
| The linked GitHub thread with Ken Silverman is gold. Watching the
| FastDOOM author and Ken work through the finer points of arcane
| 486 register and clock cycle efficiencies is amazing.
|
| Glad to see someone making sure that Doom still gets performance
| improvements :D
| kridsdale1 wrote:
| I haven't thought of KenS in ages but back in the 90s I was
| super active in the Duke3D modding scene. Scripting it was
| literally my first "coding".
|
| So in a way, I owe my whole career and fortune to KenS. Cool.
| nurettin wrote:
| His blog was the first page I "surfed". Talking about duke3d
| map editor and his big project using voxels.
| prox wrote:
| Is there a recommended place where I can play Doom in the
| browser?
|
| If such a thing exists!
| tasn wrote:
| https://archive.org/details/doom-play or any of the other ones
| linked at the bottom of that page.
| yjftsjthsd-h wrote:
| I dunno about "recommended", but a quick search turns up
| several options, the most interesting of which (IMHO) is
| https://js-dos.com/DOOM/ (mostly because it looks like a
| generic "dosbox in web technologies" and that's sweet)
| pastage wrote:
| There are many variants of DOOM in the browser vanilla DOOM is
| easy but these are cooler
|
| https://news.ycombinator.com/item?id=42607794
| https://news.ycombinator.com/item?id=42566112
| ge96 wrote:
| tangent: after playing Eternal, damn all other Doom is just
| slow... Dark Ages is coming out I'm pumped
|
| Also reading Masters of Doom, Carmack and I have something in
| common ha (went to a form of jail)
| ChrisArchitect wrote:
| https://silentspacemarine.com/
| yjftsjthsd-h wrote:
| > To get the big picture of performance evolution over time, I
| downloaded all 52 releases of fastDOOM, PCDOOMv2, and the
| original DOOM.EXE, wrote a go program to generate a RUN.BAT
| running -timedemo demo1 on all of them, and mounted it all with
| mTCP's NETDRIVE.
|
| I'm probably not the real target audience here, but that looked
| interesting; I didn't think there were good storage-over-network
| options that far back. A little searching turns up
| https://www.brutman.com/mTCP/mTCP_NetDrive.html - that's really
| cool:)
|
| > NetDrive is a DOS device driver that allows you to access a
| remote disk image hosted by another machine as though it was a
| local device with an assigned drive letter. The remote disk image
| can be a floppy disk image or a hard drive image.
| leshokunin wrote:
| I'm curious: were there NAS' or WebDAV mount in the DOS era?
| Obviously there was FTP and telnet and such. Just curious if
| remote mounts was a thing, or if the low bandwidth made it
| impossible
| sedatk wrote:
| Yes, there was Novell Netware that let you mount remote
| drives, and there were even file locking APIs in DOS to
| organize simultaneous access to files. In fact, DOOM's
| multiplayer code relied on part of Novell Netware stack
| (IPXODI and LSL). The remote mounts were mainly used on LANs
| though, not over Internet.
| bombcar wrote:
| Yes, it's basically what Netware was, and Novell was a HUGE
| company.
|
| SMB (samba) is also from the DOS era. Most people only know
| of it from Windows, though.
|
| There were various other ways to make network "drives" as the
| DOS drive interface was very simplistic and easy to grab
| onto.
|
| It was rare to find this stuff until Win95 make network
| connections "free" (before then, you had to buy the
| networking hardware and often the software, separately!).
| roywashere wrote:
| In the 90s my student union ran a computer network mainly
| for gaming with DOS PCs and netware running on a Linux
| server with MARS. This was before they had internet access
| but it was great for lan gaming: command & conquer, doom,
| or quake. All games were started from network mounts. Fun
| times.
| diet_mtn_dew wrote:
| A network redirector interface (for 'redirecting' local
| resource access over a network) was added at least by DOS 3.1
| in 1985, possibly earlier in 3.0 (1984)
|
| [1] https://www.os2museum.com/wp/redirectors-and-dos-3-0/
| jandrese wrote:
| > I didn't think there were good storage-over-network options
| that far back.
|
| Back in school in the early 90s we had one computer lab where
| around 25 Mac Plus machines were daisy chained via AppleTalk to
| a Mac II. All of the Plus machines mounted their filesystem
| from the Mac II. It was painfully slow, students lost 5-10
| minutes at the start of class trying to get the word processor
| started. Heck, the Xerox Altos also used network mounts for
| their drives.
|
| If you have networking the first thing someone wants to do is
| copy files, and the most ergonomic way is to make it look just
| like a local filesystem.
|
| DOS was a bit behind the curve because there was no networking
| built-in, so you had to do a lot of the legwork yourself.
| ben7799 wrote:
| There was already relatively deep penetration of this stuff
| in the corporate world and universities way back in the early
| 1990s.
|
| Where I want to school we had AFS. You could sit down at any
| Unix workstation and login and it looked like your personal
| machine. Your entire desktop & file environment was there and
| the environment automatically pointed all your paths at the
| correct binaries for that machine. (While we were there I
| remember using Sun, IBM, and SGI workstations in this
| environment.)
|
| When Windows came on campus it felt like the stone ages as
| none of this stuff worked and SMB was horrible in comparison.
|
| These days it feels like distributed file systems are used
| less and less in lieu of having to upload everything to
| various web based cloud systems.
|
| In some ways it feels like everything has become less and
| less friendly with the loss of desktop apps in favor of
| everything in the browser.
|
| I guess I do use OneDrive, but it doesn't seem particularly
| good, even compared to 1990s options.
| aaronbaugher wrote:
| I was using HP Apollo systems with the Aegis OS in the
| early 90s, and they basically shared one filesystem across
| their token-ring network. Plug in two or more systems,
| login to one of them, and each other system's files would
| be under //othersystem.
|
| I don't recall whether there were any security-minded
| limits you could put on what was shared, but for a team
| that was meant to share everything, it was pretty handy.
| bluGill wrote:
| I miss those days often. I have more than once computer,
| why it it such a big deal to share my filesystem. But many
| things don't work if you try (firefox for example doesn't
| like sharing settings that way). The web is great for some
| things, but local applications are often much more powerful
| and faster.
| aeyes wrote:
| My school had Windows NT and the experience was similar.
| Any workstation looked the same and had my data.
|
| Later I saw some Citrix setups which would load the
| applications from the server. That also worked pretty OK.
|
| With Windows you definitely had all the options to make
| this work in the late 90s.
| bluGill wrote:
| Appletalk was horribly slow - 230.4 kbit/s. Ethernet was
| already 10mbit at the time (but a lot more expensive).
| General best practice would have been having the world
| processor installed on each machine and only saving files
| across the network, which would have made performance
| acceptable - but at the cost of needing a hard drive in all
| those plus machines (I don't recall the price a a harddrive
| at the time, but I'm guessing closer to $1000 for 20mb,
| compared to multi tb drives for around $100 today)
| svilen_dobrev wrote:
| > the worLd processor
|
| made my day :)
|
| you did have networking? waw
|
| not here.. that's why Floppy-net was something.. as well as
| bus-304-net (like, write a floppy, hop on bus 304, go to
| other campus)
| kingds wrote:
| > I was resigned to playing under Ibuprofen until I heard of
| fastDOOM
|
| i don't get the ibuprofen reference ?
| kencausey wrote:
| Guess: headache from low frame rate?
| fabiensanglard wrote:
| Indeed.
| apetresc wrote:
| I legitimately thought it was some DOS compatibility layer
| or something. Like, you'd have to run Doom that way because
| of the low framerate natively.
| hinkley wrote:
| So what does one do with a faster Doom, besides bragging, larger
| maps and more simultaneous players?
| kridsdale1 wrote:
| Run it on more obscure hardware?
| pixelpoet wrote:
| Does it always have to be for practical benefit? What about
| pure learning and intellectual enjoyment? Where are the true
| limits? In the end absolutely nothing we do matters :)
|
| These dudes are living their best lives, and having done Quake-
| style asm texture mapping loops in the 90s (Mike Abrash,
| fastmap, Chris Hecker, PC Game Programming Encyclopedia, ...),
| I can definitely appreciate it <3
| fabiensanglard wrote:
| You can play on vintage hardware with a decent refresh rate. It
| makes it more enjoyable.
| pixelpoet wrote:
| Thanks for your awesome articles, esp the path tracing
| postcard[0] :) I've had the pleasure of hanging out with
| Andrew Kensler at a conference dinner (EGSR 2019?), amazing
| guy! He scribbled a bunch of great quasi Monte Carlo notes
| into my notebook and even signed it on request :")
|
| [0] https://fabiensanglard.net/revisiting_the_pathtracer/inde
| x.h...
| Narishma wrote:
| Run on slow hardware or save power if you're on a battery.
| FartyMcFarter wrote:
| People enjoy learning about old software. Fabien Slangard who
| wrote this article built a whole website and wrote several
| books based on that.
| pak9rabid wrote:
| Impress chicks
| sedatk wrote:
| If the author reads this: John Carmack's last name was mistyped
| as "Carnmack" throughout the document.
| fabiensanglard wrote:
| Thank you for taking the time to report it. It has now been
| fixed.
| mkl wrote:
| Another typo s/game/gave/: "Another reason John game me".
| CamperBob2 wrote:
| Speaking of Carmack, can you (or someone) elaborate on this
| quote?
|
| > _DOOM cycles between three display pages. If only two were
| used, it would have to sync to the VBL to avoid possible
| display flicker._
|
| How does triple buffering eliminate VBL waits, exactly? There
| was no VBL interrupt on a standard VGA, was there?
| fabiensanglard wrote:
| Triple buffering mean you can render at any speed, there
| will always be a valid target where to render.
|
| This is not the case with double buffering there can be a
| case where the previous target is still being sent to the
| CRT and you need to block on VBL.
| gwern wrote:
| > The MPV patch of v0.1 is without a doubt build 36 (e16bab8).
| The "Cripy optimization" turns status bar percentage rendering
| into a noop if they have not changed. This prevents rendering to
| a scrap buffer and blitting to the screen for a total of 2 fps
| boost. At first I could not believe it. I assume my toolchain had
| a bug. But cherry-picking this patch on PCDOOMv2 confirmed the
| tremendous speed gain.
|
| Good example of how the bottlenecks are often not where you think
| they are, and why you have to profile & measure (which I assume
| Viti95 did in order to find that speedup so early on). The
| _status bar percentage_?! Maybe there 's something about the Doom
| arch which makes that relatively obvious to experts, but I
| certainly would've never guessed that was a bottleneck a priori.
| robocat wrote:
| Example: "Our app was mysteriously using 60% CPU and 25% GPU.
| It turned out this was due to a tiny CSS animation [of an
| equaliser icon]"
|
| https://www.granola.ai/blog/dont-animate-height
| ericmcer wrote:
| Why was the solution to optimize the animation instead of...
| using a static asset?
| moffkalast wrote:
| We paid for the whole CSS spec and we're gonna use the
| whole CSS spec.
| barbariangrunge wrote:
| As a gamedev, those slowdowns are common. Ui rendering, due to
| transparency, layering and having to redraw things, and
| especially from triggering allocations, can be a real killer.
| Comparing old vs new before allowing it to redraw is really
| helpful. I found layers and transparency was a killer in css as
| well in one project, but that was more about reducing layers
| there
| aeyes wrote:
| He ported the optimization from the Crispy Doom fork. Since
| this is one of the first changes in the repo I bet that this
| was a known issue at the time.
| pjs_ wrote:
| Reminds me of the incident where npm was 2X slower than it
| should have been because of the fancy terminal progress bar:
|
| https://news.ycombinator.com/item?id=10974929
| qingcharles wrote:
| The original Doom must have been heavily profiled by id though,
| surely? Obviously there is a bunch of things that were missed,
| but I was in game dev at Doom time and profiling was half the
| job back then.
| fabiensanglard wrote:
| What tools did you have in 1993? From what I understood, id
| Software used NeXT because the tooling was not up to the
| task.
| ognarb wrote:
| I had a similar case when I work on a Matrix client (NeoChat)
| and I and the other devs were wondering why loading an account
| was so slow. Removing the loading spinner made it so much
| faster, because the animation to render the loading spinner
| uses 100% cpu.
| jiggawatts wrote:
| A common one for server apps is logging, especially to the
| console.
|
| It's far more expensive than people assume and in many cases
| is single-threaded. This can make logging _the_ scalability
| bottleneck!
| klaussilveira wrote:
| Glad to see another post on Fabien's blog!
| unleaded wrote:
| One feature of FastDOOM I haven't seen mentioned here are all the
| weird video modes, some interesting examples:
|
| - IBM MDA text mode: https://www.youtube.com/watch?v=Op2tr2lGK6Y
|
| - EGA & Plantronics ColorPlus:
| https://www.youtube.com/watch?v=gxx6lJvrITk
|
| - Classic blue & pink CGA: https://youtu.be/rD0UteHi2qM
|
| - CGA, 320x200x16 with 'ANSI from Hell' hack:
| https://www.youtube.com/watch?v=ut0V1nGcTf8
|
| - Hercules: https://www.youtube.com/watch?v=EEumutuyBBo
|
| Most of these run worse than with VGA, presumably because of all
| the color remapping etc
| fitsumbelay wrote:
| very nice website design
___________________________________________________________________
(page generated 2025-03-04 23:00 UTC)