FastDoom: DOS Vanilla Doom optimized for 386/486 processors

[YeOldeFellerNoob]

I am more surprised that the crudely made gameplay in the second video sounds WAY better than the audio in the actual game (GZDoom to be exact). Other than that this looks cool. I need a little DOS Doom in my life =)

[viti95]

New release! FastDoom 0.8.9 Download

 

Changelog:

 

• Added new video modes. Huge thanks to @Frenkel !!
  • FDOOMC36.EXE => FastDoom CGA 80x100 (122 pseudocolors)
  • FDOOMV36.EXE => FastDoom VGA 80x200 (122 pseudocolors)
  • FDOOMATI.EXE => FastDoom ATI Small Wonder 640x200 (dithering 16 colors)
• Small optimization for Potato and Low detail column rendering
• Optimized Plantronics ColorPlus, EGA, CGA and Hercules modes
• Added custom palette for VGA 160x200 mode
• Optimized CGA 160x100 and VGA 160x200 rendering
• Remove FDOOMVBP.EXE. It was very buggy and problematic, and in 99% of the cases a little bit slower than FDOOMVBR.EXE
• Converted all ASM files to NASM. This allows to build FastDoom with 100% open source compilers. Borland Turbo Assembler requirement is now gone. Huge thanks to @0x90 (Vogons)
• Fix screen flickering on 80x50 and 80x100 text modes. Use the parameter "-pagefix" in case it flickers
• New mode for PC Speakers. Based on the PWM method, a little bit better but uses more CPU

[Frenkel]

On 1/13/2022 at 8:47 AM, viti95 said:

@zokum The idea is good but won't work with hacked CGA modes. The "high res" 80x100 16 color modes use text mode, but only two rows are drawn per character, so no full characters are available. It's possible though to composite hand crafted graphics and maybe simulate fonts with those glyphs. For example:

 

 

As for basic 80x25, it's definetily useable, but having such low resolution it's preferable to make the HUD as small as possible.

 

Typography from Hell

 

When we combine text mode and composite mode on a CGA, we can get a 80x100 mode in 256 colors. 512 colors is also doable. 1024 colors like in 8088 MPH would be the ultimate goal :)

[zokum]

VGA has a 262144 color palette and can show a selection of 256 from all those. More colors in CGA in total would mean we can get closer to the ~250 colors doom uses for its palette. With these modes I think the palette swaps would look pretty good as well. With 1024 colors one can approximate the color space doom uses better.

I while ago looked into graphics for the norwegian Tiki-100. It can display 256 colors in a 256x256 mode. The majority of the colors are fairly ugly, and there are almost no greys. Most greyish colors have a blue, green or or yellow tint. It uses 332 RGB. Is there a similar problem with the colors in these modes?

[viti95]

Grey colors on CGA hacked modes aren't 100% perfect (some also have sightly tint), and IBM first models have a different palette compared to later ones. https://int10h.org/blog/2015/08/8088-mph-final-old-vs-new-cga-gory-details/

 

But anyway i'm pretty sure Doom on those modes will look insanely good for a CGA card.

[viti95]

New release! FastDoom 0.8.10

 

Changelog:

• Added new video modes
  • FDOOME16.EXE => FastDoom EGA 160x100
  • FDOOME36.EXE => FastDoom EGA 80x100 (122 pseudocolors)
  • FDOOMT43.EXE => FastDoom 80x43 16 colors text mode (only EGA cards)
  • FDOOMT86.EXE => FastDoom 80x43 16 colors text mode (virtual resolution of 80x86, only EGA cards)
• Multiple optimizations for special backbuffered modes
• Better colormaps / palettes for black&white modes, and 16 color dithered modes
• Removed FDOOMV.EXE, the scaling was horrible and didn't look good at all
• Revert custom palette for VGA 160x100 mode. The attribute controller requires the display to go blank to change each color association. Not doing this causes some random screen glitches while changing the palette (which I haven't been able to solve, since the hardware works this way). VGA 256 color mode doesn't have this problem

Download: https://github.com/viti95/FastDoom/releases/tag/0.8.10

[viti95]

New release! FastDoom 0.8.11:

 

Changelog:

- Optimized backbuffered video modes: Hercules, CGA B&W, Plantronics ColorPlus, EGA, ATI 640x200
- Small optimization on multiple modulo operations, sound code and gameplay code
- Fixed music initialization volume (@deat322)
- Fixed mouse move fordward button (@deat322)
- Include full FastDoom version number (issue #72, @SpitFire-666)

 

Download: https://github.com/viti95/FastDoom/releases/tag/0.8.11

 

Edited April 12, 2022 by viti95

[deathz0r]

On 4/12/2022 at 5:41 AM, viti95 said:

Changelog:

- Fixed music initialization volume (@deat322)
- Fixed mouse move fordward button (@deat322)

 

Thanks for merging those changes, I appreciate it! I need to look into how to set up a debugger with Open Watcom so I can further diagnose issues #52 and #66.

[viti95]

I've tried to use the OpenWatcom debugger but it always have caused lot's of troubles and it's very unstable. Don't know exactly why. Even on a local machine (DosBox-X + com2com + OpenWatcom for W64) which shouldn't have communication problems, didn't work reliably. For now I debug using the DosBox-X debugger and the "i_debug.h" functions (requires a second monitor connected to a MDA/Hercules card, or DosBox-X running with the secondary monitor enabled).

 

 

[zokum]

I got a wild idea this morning. The port has low detail modes, rendering with double height pixels etc. What would the game be like if you rendered it in an interlaced fashion? Would it tear so much that it would be unplayable/ugly? On one frame you update line 0,2,4 of the 200 lines and the next frame you update line 1,3,5 etc. You would get 320x200 whenever you're standing still / not much is happening and in Doom pixels are often fairly blocky. You wouldn't be able to use double buffering for this though.

And on that note, how about a low detail mode that wasn't on/off. What if the center 160*100 was rendered as in 320x200 and the rest of the image was rendered in double height etc. Giving you good vision straight ahead, but less image quality at the edges. Other variations could also be possible, like rendering the center 160 pixels in full resolution and the 80 pixels at each edge as double height.

Without looking at the code, I have a hunch that this isn't something that would speed things up much. Though there might be other ideas about not having a uniform detail level that could speed things up.

A friend told me he used to play deathmatch in low detail mode until he had a high end pentium 2 era machine so that he would get the least latency and highest framerate no matter what happened. Apparently playing as indigo is better if you have very fast machines.

[zokum]

A note on CPU optimizations. Open Watcom allows you to optimize for 386, 486 or pentium class cpus. You can even optimize for the timings on a pentium, but use only 386 instructions. You can also generate inline x87 instructions for systems that have an FPU. I looked around on the project github page and couldn't find anything about which cpu architecture you optimized for. Have you tested different compiler flags to see what gives you the best speed?

Might be worth it to compile say 4 versions, i386, i486, pentium and 386 with fpu so that people can download the one that suits their architecture best. I have a hunch that dosbox most likely favors one of them as well, that would be nice to know since this is a common platform these days. PCem and others might also favor a certain set of optimizations.

And if there is no noticable difference, you could mention this in the documentation so that people know that this has been taken into account. From what I remember form Abrash Black book, it can be fairly important to know which cpu you optimize for. Some code is faster on 386, other instructions wok better on a 486. It's quite fascinating to read about, at least to me.

Edited April 13, 2022 by zokum

[LuciferSam86]

Pretty impressive updates, I like the direction of this port.

In the weekend I'll make a 486 machine using 86box (a PCEm fork) and play doom :)

[viti95]

The problem with interlaced rendering is that it requires very fast screen updates to look reasonably good, and here we are dealing with low framerates most of the times. I'm pretty sure that can cause some headaches. The other idea is good, but the Doom engine requires big changes to allow different rendering resolutions at the same time (I did some testing and failed miserably, for example rendering the sprites at high quality while rendering the scene at a lower one). Old 386/486 computers benefit a lot from sending less data via the ISA bus, and that is one way to do that.

 

Regarding CPU optimizations, the first executables were optimized for 386 and 486 cpu's, and in all the testing done the 386 executable was always the faster one (also smaller). That's why I decided to release only the executables optimized for the 386. I guess OpenWatcom isn't very good at optimizing code, compared to newer compilers.

 

Again, this requires time to research, and I'm pretty limited right now.

[viti95]

 

¯\_(ツ)_/¯

 

[zokum]

Not bad, but if you have both background and foreground shade colors you can use the block characters to make many more shades and make it look better than this currently does. Not a bad early version though. I could recognize the areas and understand what was going on.

 

[viti95]

For now it's just quick'n'dirty support for the IBM MDA, guess I'll make it better someday.

[Maes]

Well, at these sorts of resolutions, it maybe pays to have custom assets optimized for the display's limitations. E.g. it would make much more sense to have Zombiemen redrawn as stickmen (even if they had to undergo the same scaling process), than a bunch of blocky characters.

[viti95]

Yeah this definitely requires custom assets to get better results. BTW new release:

 

FastDoom 0.8.12:

 

- New video mode: IBA MDA text mode (FDOOMMDA.EXE). Just for fun, quick'n'dirty

- Small optimization on gameplay code and melting screen functions

- Fixed corruption on VGA palettes (issue #75). Force fix if still doesn't work using the command line parameter "-fixDAC"

 

https://github.com/viti95/FastDoom/releases/tag/0.8.12

[zokum]

I think it would look good enough without the use for custom assets.

What you could do is to figure out how to make custom glyphs. Replace the character set with one optimized for rendering game worlds with text characters. That way you could have all kinds of interesting shade block, half blocks, quarter blocks, three quarter blocks etc. Doom needs about 60 chracters or so for all the supported ingame font. The remaining 190 you could repurpose into a tone of shade variations.

One should be able to render the game in the 320x200 resolution and pick the custom glyph that is the closest to the frame buffer and output the text version.

Impulse tracker aparently did something really funky, it redefined the glyph for the mouse pointer constantly in order to provide a good mouse cursor in a text interface. It also used custom colors for the interface and a higher text mode resolution. Might be some tricks in there, or similar apps that you could use?

I am pretty sure this is a mixture of DOS/BIOS glyphs and custom glyphs, it is aparently not a graphics mode, it is text mode. Kind of amazing. Then again, as it was a demoscene tool, this isn't unexpected.



Cubic Player also has a lot of cool custom stuff and tricks up its sleeve. Not sure if those are text mode or graphic modes though:

[Blzut3]

3 hours ago, zokum said:

What you could do is to figure out how to make custom glyphs. Replace the character set with one optimized for rendering game worlds with text characters.

If I remember correctly MDA gets the character set exclusively from ROM so this isn't a thing.

[viti95]

@Blzut3 is right, that technique is only usable on EGA/VGA cards, the MDA and CGA cards cannot redefine the characters. That's why I had to create a new specific text mode for the IBM MDA, as it doesn't support any kind of graphics mode.

 

Redefining characters is pretty powerful, this demo is a pretty good example I've been testing with it's creator. This demo works at 60fps on 8086 computers (custom text mode, 40x30 characters):

 

 

[zokum]

I was thinking of EGA+ stuff yes, not MDA specifically. Redefinig the glyphs is standard practice in DOS when changing code pages. I'm norwegian so we have a few changes in DOS like æøå ÆØÅ and ¤. The ¤ is the generic symbol for currency, I think it's called scarab.

Way more characters than 80x25 is probably also an ega/vga thing. Some of the modes are probably vga only. With 256 glyphs, you could create pseudo pixels out of the characters or lower resolution, but dithered pixels to improve the color space. Add the custom color trick used in earlier doom setup versions and you could probably find a set of color values to create a really nice doom experience in text mode.

With 16 custom colors, I'd probably go with something like:
1 white
1 black
3 shades of grey 64,64,64 160,160,160 and 192,192,192
3 shades of red
3 shades of green
2 shades of blue
2 shades of yellow
1 shade of brown.

The trick would be to make the brightness of the colors in a way so that you could use dithering of black and red to make a darker red, or with white for a brighter red. Orange in the game would be replaced with yellow/red dither. The less vibrant green colors with a dither of green and grey etc.

The 64,64,64 dithered with black would look like a 32,32,32 pixel. The 3x160 a 3x80. Dither of 64 and 160 would look like 3x112. Ideally you would need some sort of spacing that would give you many perceived brightnesses of each color. Having a 3x64 and 3x128 isn't as useful as dithering the 3x128 with black would look similar to the solid 3x64. The brightnesses I chose here were taken out of thin air, more optimal schemes for getting more dithered hues probably exist.

You could also make every 3/4 pixels on dither patterns as seen in ansi art. Then you could use black and 64 together to make a pseudo 48,48,48 and 16,16,16. The math for all of this wouldn't be too hard and could be pre-computed into a lookup table for each color in the doom palette. Dithering black and white to make a 128,128,128 color pixel doesn't look good. You'd probably get a better result from a 3/4 dither of 160 and 64. Dithering works best if the colors are close in brightness.

The 132*50 svga mode is fairly standard and could allow for some really nice "text mode" doom. The 80x60 or 80x50 is probably a safer bet on older machines and monitors. Windows NT loves to use higher res text modes, so support should be decent. NT 4.0 used 80x50 during boot.

[zokum]

I made a quick mockup and experimented with the color intensities a bit. Doom doesn't have so many dark reds, so we should adjust all those upwards. We could also do with just one yellow and two browns instead. Orange didn't look particularly good with dithering. Maybe squeeze in one orange and drop a green? Or perhaps we could do with just two reds due to the lack of dark red in the game palette. The point is that this kind of approach does have some potential.

The important thing to remember is that some colors are used much more in Doom than others, making them more important. Bright blue isn't seen a lot in the game, while brown is. One should adjust to favor color choices in representing the more commonly used colors and not the full palette. I dropped the pink and purple hues. Mixing red and grey might work for the brighter pink colors and the darker just map to red.

If we wanted to go completely bonkers, we'd render 320x200 VGA to a buffer and compute the 16 optimal colors for that frame and use those colors. Constantly updating the palette to render the game as close to vga as we can. In a dark room with brown walls, we'd have many browns and some grey and others for hud/weapon and no greens etc.

Doom in grey scale with this approach should look very good. You'd easily get 64 shades of grey, enough to render everything fairly close to the original brightness.

 

[zokum]

Many of the 256 color lucasarts games used a special palette technique. The UI and main characters were in a certain set of fixed colors that were available in every area/room/scene. The remaining colors were custom per image. This allowed for eerie greenish stones, lush jungles, fantastic lava, just not all at the same time.

The same approach could be used in Doom. Use a few fixed colors (grey/black) for ui and have the others as dynamic colors from frame to frame. Implementing red tint when hit, green tint for rad suit etc should be easy peasy with custom colors and a nice touch in text mode port.

[viti95]

Something I've always wanted to implement, dual screen support. Right now I'm testing on MAME (the only emulator that supports Hercules+CGA emulation, Hercules+VGA it's currently broken on the emulator), it'll be available on the next release.

 

Edit: Proof of concept video

 

Edited June 3, 2022 by viti95 : New screen capture, updated code to fill all the Hercules screen

[maxmanium]

4 hours ago, viti95 said:

-snip-

 

Off-topic, but same energy:

 

Spoiler

 

[Dark Pulse]

6 minutes ago, maxmanium said:

Off-topic, but same energy:

 

  Hide contents

 

Similarly off-topic, similar energy.

 

 

[viti95]

Yeah I know, the CGA 4-color mode needs better colormap / playpal 😂

[Blzut3]

10 hours ago, viti95 said:

Something I've always wanted to implement, dual screen support. Right now I'm testing on MAME (the only emulator that supports Hercules+CGA emulation, Hercules+VGA it's currently broken on the emulator), it'll be available on the next release.

Glad to see you did this!  Might encourage me to finally getting around to trying my Hercules card in various 386/486 systems I have to see if I can get dual display working.  Wasn't able to do it with my K6 (AGP card would just take over monochrome functions), but I don't think that was entirely unexpected either.

[zokum]

I have had two monitors for almost 20 years now. Games have never used such setups in any meaningful way. In world of Warcraft you could have had the main game on one and map, chat, inventory on the other. So i end up eith irc or YouTube on the 2nd display