When id Software released DOOM back in 1993 it helped define the genre, but it was hardly the only hit first-person shooter of that decade. There was also 3D Realms’ 1996 Duke Nukem 3D, a game which added some humor to the genre. Here’s [PicoPlus-devel], with pico-duke3D. It’s Duke Nukem 3D, on an RP2350.
Before reaching the conclusion that this might be obvious and easy, the three years between the two releases saw quite significant movements in the world of gaming PCs. DOOM’s minimum spec in 1993 was a 386 and 4 MB of memory, and would have been playable on a basic VGA card in an ISA slot. By contrast three years later Duke Nukem 3D required at least a 486DX2 and 8 MB, which would inevitably have had VESA local bus or PCI graphics. It’s a Quake competitor rather than a DOOM competitor, thus the power required to run it has stepped up a notch or two.
The RP2350 then is up to the job, and runs the game on a DVI equipped Pico clone. It can be controlled via either SNES or USB controllers given the right hardware, making it the perfect one-game console. The shareware game works, as does the full version if you own a copy. Having been around in the ’90s then, we’re curious. Could it be made to run Shadow Warrior as well? You no mess with Lo Wang!
No video, no information about basic things like framerate, all Claude.
Disappointing on all three counts. I’d rather read about projects where an actual human can talk about their experience doing it, but this is even more scant on details.
TIL duke3d is open source? (at least, the engine)
It doesn’t look like it is open source:
https://en.wikipedia.org/wiki/Build_(game_engine)
Source available software:
https://en.wikipedia.org/wiki/Source-available_software
It looks like Duke Nukem 3D (at least, the game code) was released under the GPLv3 in 2003.
See: https://en.wikipedia.org/wiki/Duke_Nukem_3D (the source code can also be found on github)
Hi, yes, pre-assembled 486DX2 and later systems often had mainboard with more than just plain ISA bus.
The 486DX2-66 was very popular as an upgrade to existing 486 systems, too.
It was 5v tolerant (intel version at least) and a drop-in replacement for the 486DX33.
So there had been ISA-only mainboards with a 486DX2, as well.
About Doom vs Duke Nukem 3D..
Doom was using very dated technology even by 1993 standard, that was part of its success, after all.
It worked on old PCs in teenager bedrooms and on slow office PCs.
To make it happen, it used the generic, pixelated VGA Mode 13h (320×200 pixel @256c).
However, almost all VGA graphics cards since 1988 could do any form of SVGA.
Be it 800×600 pixel in 16c (defacto Super VGA res, first standardized by the VBE draft in ’89) or 640×400 pixel in 256c (PVGA1A from 1988).
The reason the advanced features weren’t used was perfomance and simplicity/comfort.
Mode 13h did use 320×200 in 256c that fit in a single 64 KB segment in the framebuffer area (A segment).
That way, no bank-switching was needed and a single byte (8 bit, 256 values) could represent a 256 color pixel on screen.
In principle, Mode 13h is not “pure” VGA, though.
That would be Mode 12h (Standard VGA is 640×480 in 16c, planar layout).
Mode 13h rather is closer to MCGA (formerly called “PS/2 graphics”), because it is more of an enhanced CGA the way it works (no bank-switching, a default palette).
The IBM PS/2 Model 30 (8086) has a discreet MCGA circuit that could do Mode 13h only (and IBM CGA modes, plus Mode 11h which is 640×480 mono).
A feature that real MCGA lacks, however, is a custom palette.
VGA cards can optionally use custom palettes in Mode 13h.
That’s why some Mode 13h games require an VGA card and can’t run on MCGA hardware.
By comparison, Duke Nukem 3D was much more advanced.
It could use VESA VBE, which not only standardized video modes but also introduced the Linear Frame Buffer (LFB) in the VBE 2.0 specification.
That means that VBE 2.0 compliant cards could use a frame buffer location far away from VGA’s (starting in A segment, 640 KB onwards).
In principle, this meant that the VGA frame buffer was available to another graphics card
or that an advanced OS could grab VGA data while outputting its own video via VBE.
This Youtube video explains it: https://www.youtube.com/watch?v=Kkok544z61E
The LFB was supported by most PCI (S)VGA cards if a VBE 2.0 compatible VGA BIOS was available.
Or if a DOS TSR (UniVBE, Display Doctor, S3VBE20 etc) was loaded.
(S)VGA cards for VESA Local Bus (VLB), EISA or Opti bus may or may not had LFB support.
It did depend on the graphics chip used..
Some newer SVGA chips with LFB support were used on ISA graphics cards, even. Such as Cirrus Logic CL-GD5424.
Here, the 15-16 MB region near the end of the ISA/80286 address space was used for the frame buffer (or also 14 to 16 MB, not 100% sure).
Systems equipped with the full 16 MB of RAM had the “15-16 MB memory hole” setting in CMOS Setup to be enabled for this to work.
Otherwise, the frame buffer location wasn’t available.
As a side effect, though, enabling that memory hole feature also interrupted the contiguous extended memory,
so memory past 16 MB nolonger was used by any OS.
Local bus cards may also have used 32 MB, 64 MB or an even higher location.
PCI cards usually had access to whole 4 GB address space and had the frame buffer being located much higher.
This is just a short summary, as I’m just a layman here.
I thought I should mention it, because I think the DOS era is underrated sometimes.
On a closer look, the technology of its time wasn’t fully being utilized sometimes.
I don’t think this specific statement is true – the computers at my school back in the early 90’s were PS/2 model 25s with MCGA, and I remember them allowing you to set the palette in mode 13h just fine.
I was able to find a ps/2 technical manual online and indeed, MCGA implements palettes in 256-color mode using what appears to be the same general setup, and the same BIOS calls, as VGA.
Whether the palette systems are compatible on a deeper hardware register level, I don’t know, and I wouldn’t be surprised if the answer turned out to be “not quite”.
Hi there, thanks for pointing that out!
It seems that MCGA hardware didn’t have an EGA/VGA style memory controller,
so VGA effects (shaking, scrolling, split screen etc) didn’t work.
The palette may indeed have been changeable, however. My bad. 😅
I’ve found some information over here:
https://www.swiat-owocow.pl/lang/en/1285.html
https://www.ardent-tool.com/video/PS2_Video_Programming.html
Doom ran at a maximum of about 35 frames per second (half the refresh rate of the video mode). At 64000 bytes per frame at 320×200, achieving that would require pushing over 2 Megabytes per second through the ISA bus. Ok, it didn’t need to update the status bar at that frequency, but even excluding that, we are still talking about 1.8 Megabytes per second. Of course, a 386 or even a lower end 486 CPU wasn’t able to do that anyway while rendering the content of the frame. Now, imagine rendering in higher detail and pushing 4 times that much data 640×400) on even the faster CPUs available at or around the time Doom launched (late 1993) and through the ISA bus, no less. That probably helps explain why 640×400 or other VESA mode was not deemed to be worth considering. Even 320×200 VGA mode ran like a dog on many mainstream ISA cards.
VLB and PCI and came out in the mid 1992 time frame, at the high end edge of the market. While prices started dropping fast and things moved faster in tech in that era, and a baseline affordable mid 1994 system with a clock doubled 486 + VLB video was capable of playing Doom well, at launch of Doom, the part of the installed base that was able to run it had framerates that were marginally acceptable even then. Reaching the max rendering speed the engine could muster meant using one of the newly launched (about 6 months prior) Pentium systems (no clock tripled 486s available yet).
So, saying that Doom was “dated technology”, if that means to imply that Doom could actually run well, let alone to the fullest, on hardware that was considered old at game launch is something I would not agree with, barring some nuances to what “running” implies [1]. And I can only dare hope that you are not implying Doom’s engine was based on “dated technology”.
[1]
“Doom was using very dated technology even by 1993 standard, that was part of its success, after all.
It worked on old PCs in teenager bedrooms and on slow office PCs.”
There’s a Usenet post from 1994 you may want to read.
Especially these bits are interesting, maybe.
Also because in context of historical truth.
But be careful, this may cause cognitive dissonance.
Since not everyone appreciated Doom when it was new.
There were people with statements that made people think.
I’ll quote some of them here, I hope my comment won’t get deleted because of it.
“I’m quite sick about hearing about how Doom was the best
thing since sliced bread, how their graphics are absolutely
revolutionary, how their entire system is revolutionary.
They took an inside view walkthrough game and used 3d texture
mapping to draw it, and slapped it onto a truly pathetic
networking system (which got replaced by something better
very soon afterwards, if only because it started getting
site-banned not 4 hours after the game was released).”
[..]
“I often play violent games to get rid of violent energy in my system.
I get the same satisfaction I would get if I chose to slam shut doors,
but nothing gets damaged when I play violent games such as …………”
Response by another user:
“Not very much get damaged by slamming doors shut either (unless you livein a house almost falling abart).
But did you ever think about how and why this “violent energy” ever got into your system?
Wouldn’t it be better to try to prevent it from getting into your system, or at least from influencing you that much?
Suppose your boss harasses you at your job.
You get frustrated and go home to play some “Doom” to get it “out of your system”,
perhaps pretending it’s your boss you shoot down.
Then you get
back to work, where nothing has changed – your boss still harasses you.
Wouldn’t it be better to do something about it than to just escape into
some silly game,
and during a particularly bad day perhaps use a real
shotgun?”
[..]
“People who really never ever would kill somebody, they wouldn’t run these “killing simulators” either.
After all, if you’re completely uninterested in doing something in real life, why run a computer simulation of it?”
Usenet post: https://tinyurl.com/3w6kh6e7
About ISA performance..
There were workarounds, such as using “dirty-rectangle” technique, which the Windows 3.1 VGA driver used in 640×480 pixel at 16c.
It made it possible to run multimedia software on a slow, unaccelerated ISA card.
Secondly, it wasn’t unheard of to overclock ISA bus to 10, 12 or 16 MHz even.
Early AT motherboards didn’t stop a 8.33 MHz, also, because they pre-dated EISA specification.
Same goes for ISA memory boards from mid-late 80s.
They often had been specced for up to 12 MHz bus operation.
The slowness had multiple reasons, I’d say
a) some 16-Bit ISA cards ran in 8-Bit mode by accident
b) some had a very slow chip (OTI-37c, ATI VGA Wonder 8-Bit etc).
d) many had no buffered bus interface (ET4000AX, latter Cirrus Logic cards etc had)
e) …
There were DOS games using 640×400 256c (VBE mode 100h), though.
They even worked with 256KB of VGA memory, if the manufacturer’s VBE TSR was used (VBE 1.0 to 1.2, often).
UniVESA/UniVBE rejected all 256 KB cards, so many users of budget VGA cards had no VBE.
Despite technically being available (though without LFB).
Examples:
Jump ‘n’ Run: https://www.mobygames.com/game/6846/shakii-the-wolf/
Point&Click adventure: https://www.mobygames.com/game/19435/die-hohlenwelt-saga-der-leuchtende-kristall/
Other types of games also used 640×400 256c, such as chess games and Flight Unlimited (DOS/WIN 1995).
It supported 320×200, 320×400, 640×400, 1024×768 pixel resolutions.
https://aiss.stars.ne.jp/fu/index.html
800×600 16c (native SVGA res) was used by many graphics adventures from Legend Entertainment and Magnetic Scrolls.
MS Flight Simulator 4 and 5 had supported SVGA, as well.
By the way, DOOM is not a “true” 1993 game depending on how we look at it.
I mean, yes, sure, it was a ’93 game in the sense of being develeped in 1993 (or earlier),
but because it was released in the very last month of 1993 (December 10, 1993) it’s same time a stretch to call it a ’93 game.*
In reality, most players probably started to learn about it somewhen in 1994, thus,
when new PC magazines or Shareware CD-ROMs had left the press (January ’94 releases).
Technologically, DOOM was at least a year behind, thus. Mildly said.
(*As an analogy, Windows 98SE was 90s era tech on paper, but it was released in late 1999.
In reality, it spent most of its time being run in early 2000s.
Or let’s take the GameBoy. It appeared in ’89 but belonged somewhat to the 90s really.
Again, depending on how we look at it.)
I forgot to mention, EGA/VGA cards had a vertical re-trace interrupt on IRQ2*.
It was buggy sometimes, but most ISA VGAs had a jumper to enable it.
PCI VGA cards could have it enabled in CMOS Setup (“BIOS”).
It’s one of these obscure things of the DOS days that was underutilized, I think.
https://www.dosdays.co.uk/topics/io_addresses_irq_dma.php
https://forum.vcfed.org/index.php?threads/the-myth-of-the-vertical-retrace-interrupt-on-ega-vga.62971/
https://www.vogons.org/viewtopic.php?t=58445
(*IRQ2/IRQ9 are in cascade, MPU-401 and ACPI use them too)
Shadow warrior was great but had a nasty auto play bug on Windows 95. If I let the auto play run, it put some junk in the registry that corrupted it.
My dad figured out the fix of dumping the registry to text and importing it back.
According to https://www.youtube.com/watch?v=IJHGUTm_92s Doom/Duke break even is exactly DX2-66 with Doom faster on slowed CPUs and Duke taking over with faster ones. But that doesnt mean Doom was playable on slower computers by todays standard, it ran at 15fps to Dukes 10-12.
Duke Nukem 3D was already ported one year ago, to run on the Arduino Nano Matter Board. It ran only on the embedded 256 kB of RAM, implemented all the features (including cheats and save games, and sound/music) and featured even wireless multiplayer, at 30+ fps. It required external flash ICs for the GRP file, and supported only 320×240 display though, and wasn’t covered by HaD. This is the link: https://community.silabs.com/s/share/a5UVm0000011Q1VMAU/porting-duke-nukem-3d-to-arduino-nano-matter-board?language=it