That's pretty good. There was another early 2.5D game that ran on my IBM PC that I played in around 1994 that this reminds me of. I'll go search for it now
I think the framerate was closer to like 5fps or so.
I was under the impression that this series running on an 8088 was a unique property but Wikipedia fails to mention it. I was a kid then so let's just presume I was wrong
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.
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.
> 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)?
On a 286 sure you can go to protected mode but AFAIK that tended to be more involved than most people would like.
In the case of XMS, that could help but still requires moving data to/from EMB.
Frankly EMS would be the best option to keep it workable on an 8088. At the very least the 64k frames could be used for some of the data that I'm guessing are streamed (belched?) from disk.
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.
"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.
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.
What's bullshit about that last one? I had a 386DX40, AMD made them, they were a popular budget option in the early 90s and the first time I played Doom was on that PC. It ran better than that video demonstrates, even at full res, though I ran it half-res and with the window downsized a notch. I presume they're using a particularly crappy video card.
That's about how I remember my 40MHz 386 playing it. At the time, it was mind-blowing anyway. I would usually play it with the window shrunk a couple notches.
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?
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.
One of the biggest contributor to performance differences was the implementation of the L2 cache on the motherboard.
More expensive chipsets tended to have better cache implementations... Assuming the system even had cache installed, those cheaper systems often paired a 486SX with a cheap motherboard and zero L2 cache.
When installed on the same motherboard, same cache/memory config, with the same graphics card, same bus speed, a 486SX should run Doom identically to a 486DX.
I remember it being the case that Doom was aggressively tight-loop optimized, so the small amount of L1 cache was more significant especially on clock-multiplied 486s. Though you are right that the SX/DX distinction wasn't meaningful for Doom as it was all done with internet mathematics.
Yeah, the clock multiplier will also make a large difference.
Which might actually be a fair comparison, The DX2 and SX were launched at the same time, so there is a decent chance the "fast 486 DX" someone is talking about is actually a DX2.
The SX2 was launched later, with the same 2x clock multiplier and same size L1 cache, so would preform identically to the DX2 (in non-fpu tasks like doom). But the DX4 was launched at the same time, now with a 3x multiplier and L1 cache doubled to 16KB....
IIRC the fastest base 486 (out of the box without trickery) was 50MHz. There was a DX2-66 (and DX2-50, which ran clock doubled with the rest of the motherboard at 25MHz). There was also the DX4 which despite the name was only click tripled, running as fast as 100MHz of a 33.3MHz. Other manufacturers produced faster clocked i486 compatible processors: I had an AMD 5x86 which was actually quad-clocked, running at 133MHz internally. For tight loops where the code and enough data for a fair few cycles fitted into its on-chip cache (something like 8K code & 8K data?) these were surprisingly speedy compared to Intel's 486s and even low-end (66MHz, and in some artificial tests 75MHz) Pentiums. Cyrix had some similar models that were quicker still for integer work, and IIRC cheaper so even better VFM for sure tasks, but had abysmal floating-point performance which was rapidly becoming pretty important for games around that time.
Doom used integer maths throughout, so would not benefit from and FPU, but did get a boost in complex maps from the faster internal clocks of doubled/tripled/quadded chips. The Quake era (maybe a little earlier for some more niche games like certain fight simulators) is when the FPU became a massively significant factor for home use (though it didn't exclusive use it: the original Pentiums' FPU wasn't trials fast enough so only something like 1/16th of the work was done there and integer approximations starting from those values were used between - improved further by the FPU being able to work on its next bits while the CPU ALUs could do there part, a hack somewhere between pipelining which 486+ units did naturally (& Pentiums more so due to extra ALU circuitry) and hyperthreading).
Hi moderators, please consider not downvoting me here; I'm resorting to commenting in this newer thread where replies are still enabled in an attempt to reach mrob (whose profile has no contact info).
---
Hi mrob,
I just wanted to thank you for your extraordinarily helpful comment about harmonics in music. I've been playing guitar for about 30 years and make regular use of harmonics in my playing (and tuning), but when a nonmusical friend recently asked me to explain why those sounds were so different when lightly touching strings above the 5th, 7th and 12th frets, I had little to offer by way of a coherent explanation. Favorited and bookmarked / added to my PKM. Have a great day and thank you for such a great comment! You're a great example of what makes HN such an awesome community.
IIRC AMD put out a chip that officially ran at 66MHz without clock doubling, though obviously you needed a motherboard (and RAM) capable of running at that rate.
I played it a little in a 386SX40. I had to reduce the rendered screen size, and even then it struggled in open or complex scenes and/or when there were a lot of enemies active.
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.
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."
In case, like me, you wondered what an "Interceptor window" was:
"NeXT also have an internal kit called Interceptor Kit, which allows a privileged application to punch a hole through the Postscript windowserver directly to the display card."
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.
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/
Not only that but it was due to their portable software architecture which was by design. Carmack isolated the platform dependent stuff so that you can port it to any other platform without too much effort.
The great majority of platform dependent code is video output, keyboard handling, sound and network.
The functions for that that call dos/x86-specific code are neatly separated by the rest in appropriately named files, so it’s really easy to know what you will need to modify, without a million other distractors.
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.
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.
My first computer was an IBM 486DX@33Mhz. My father had an Apple Macintosh Quatra (Ferrari) and I had this IBM (hooptie). I remember vividly trying to get DOOM to run on it. It would but at 6fps. With the turbo switch on, 66Mhz, I got 12fps on low settings.
My father and I tried everything we could to overclock that IBM into 133Mhz but the CPU was holding it back. Later that year, he bought Marathon by Bungie (precursor to Halo) for me on his Mac. I think he felt bad that I was so disappointed. I loved it. He saw this and for Christmas that year, I had a new motherboard with a new Pentium chip capable of ripping Martian marine mutant faces.
> My first computer was an IBM 486DX@33Mhz.
> With the turbo switch on, 66Mhz
That’s not how a turbo button works, it doesn’t make the pc “go faster” [1] :)
Either you had a 486@66Mhz, or you set your multiplier to 2x instead of just pressing the turbo button.
[1] I mean, you could by default power your pc with turbo in “slow mode”, and activate it for hyperspeed, but you’re still using a 66Mhz CPU that is being normally slowed down
I know the chip was a 66mhz chip. Without the button pressed, it was useless. I also know this was about CPU timing. Having it "on" slowed down the timing. But having it on (to slow the CPU timing) and trying to overclock the CPU (to make it faster), resulted in nothing more than a few fps. After the upgrade to Pentium, it was 60fps.
The turbo button is a 3-pin switch. Some wired it so that "off" was full-speed. Some wired it the other way. I believe mine were wired for "on" = fullspeed.
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.
The Jaguar port is not a port of the SNES port. It was built in-house at Id and was developed by Carmack himself. See Doom Wiki: https://doom.fandom.com/wiki/Atari_Jaguar
The SNES port runs on a bespoke engine written by Randy Linden. Whereas the Jaguar Doom is the basis for many console ports, SNES Doom is something of an (incredibly impressive!) dead-end on the Doom family tree.
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.
It's interesting that a not very optimized port of DOOM was available for m68k Macs where DOOM runs at an almost playable framerate on a Mac LC or LC II with 15 MHz m68020 or m68030 on a 16 bit memory bus. It's worlds faster than DOOM on a 24 MHz 80286.
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.
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.
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.
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.
https://twitter.com/FOmmetje/status/1696266683756003451
or if you prefer:
https://nitter.net/FOmmetje/status/1696266683756003451