@GigAHerZ i've implemented a double height resolution version in the 80x25 mode, it looks way better! Here's a video showing the new mode on a CGA card.

Also I've fixed the flickering problem using multiple video pages (triple buffering without backbuffer, all pages are stored in the video card).

https://www.youtube.com/watch?v=RFdqiMSYZ08

@LightStruk yes it's really hard to play with such a low resolution, I think it's more playable having more resolution than colors. Anyway more modes will come in the future 😁

@Cyberdyne PWM sound with the PC-Speaker it's one of the first things I want to do, but I'm no expert in sound programming. Any help is welcome!

CGA can work in composite mode =) so you can also reach more colors than 4 in this mode =)
also i heard from https://www.youtube.com/watch?v=niKblgZupOc

Fallen Star Features:

I was a games programmer at Epyx in 1987. We developed a vertical sync hack that enabled us to switch between CGA 4-color palettes on-the-fly, at the same scan line in each frame. That allowed us to use both CGA palettes in the same scene. Check out Epyx' California Games, where CGA synchronous palette switching gave the Hackey Sack game a blue sky at the top of the frame, combined with green grass at the bottom.

Also heavy drty hacks used to reach many more colors on CGA card
https://www.youtube.com/watch?v=yHXx3orN35Y
oh wow

found also this one
https://int10h.org/blog/2015/04/cga-in-1024-c … de-illustrated/
https://bumbershootsoft.wordpress.com/2015/09 … n-the-pcs-book/

amazing , isn't?

Very cool, and it looks much better than aaquake(2). Looking forward to see it in action on a CRT 😀

Doom CGA? Let's see what CGAArt makes of it:

And Doom II:

That... is... AMAZING!

If thing go any further, we will be playing DooM on a IBM PC/XT soon 😁

Kind of reminds me of the Amiga Doom Clone based on Freed∞m assets.

I wonder if it would be possible to use FPUs, though from what I've read that's a real painful process.

I have an AMD 386 DX 40 with 16MB RAM, Cirrus Logic ISA video, and Cyrix FPU. Runs much faster than vinilla Doom, even in low detail mode. 132x200 mode with a 64color palette... Wonder is that would be possible?

ryanfox81 wrote on 2021-03-03, 08:01:

I wonder if it would be possible to use FPUs, though from what I've read that's a real painful process.

IIRC, Doom uses no floating point code. The performance with or without a math coprocessor should be identical. MMX instructions would help, but Pentium MMX chips and later need no help running Doom. 😄

If one were to convert some of Doom's math to use floating point instead of integers, the performance would probably still suffer. The 80387 implementation of FMUL, for example, takes between 29 and 57 cycles to complete. That's still way faster than the 80386 can do floating point multiplication without the coprocessor, but is almost twice as long as the 80386 takes to do integer multiplication. Using floating point math would need to save a lot of instructions to make it useful for Doom.

LightStruk wrote on 2021-03-03, 14:01:

ryanfox81 wrote on 2021-03-03, 08:01:

I wonder if it would be possible to use FPUs, though from what I've read that's a real painful process.

IIRC, Doom uses no floating point code. The performance with or without a math coprocessor should be identical. MMX instructions would help, but Pentium MMX chips and later need no help running Doom. 😄

If one were to convert some of Doom's math to use floating point instead of integers, the performance would probably still suffer. The 80387 implementation of FMUL, for example, takes between 29 and 57 cycles to complete. That's still way faster than the 80386 can do floating point multiplication without the coprocessor, but is almost twice as long as the 80386 takes to do integer multiplication. Using floating point math would need to save a lot of instructions to make it useful for Doom.

I tried to accelerate some functions that used fixed point math by converting them to floating point math and trying to execute those functions asynchronously, but was a fail being slower than the original fixed point versions. Communicating with the FPU on 386 processors is really slow (sometimes is slower than the function to execute), no wonder why ID Software avoided it at all costs. It's a shame that Intel didn't use the same idea that they used in the 8087 FPU, because it behaves as a full parallel coprocessor, rather than a "serial" one. Maybe it's possible to use some kind of parallel processing with memory mapped FPU such as the Weitek 3167 (or 4167) or the Cyrix FasMath EMC87, but I don't have any of these rare FPUs.

I was also thinking of using some kind of DSP to accelerate some functions, but there is no common ISA card that has that kind of function. The only one that comes to my mind is the Creative CSP/ASP (ST18932, 12 MIPS), but having no documentation nor compiler makes it an impossible task.

Cyberdyne wrote on 2021-03-01, 12:41:

If thing go any further, we will be playing DooM on a IBM PC/XT soon 😁

I wish someone port Doom to 16-bit code, that would be awesome. For now the bare minimum to run Doom is a 386-SX at 16Mhz.

Here's a little update, textmode is fast even with CGA or EGA cards, the game framerate still relies on the CPU. This video shows the new textmode running on a 8-bit Trident EGA card (connected to a MCE2VGA i've recently acquired) in my 486DX-50.

https://youtu.be/fFrkKUQO61Q

wow legendary =0
Sorry for a small content of my message. But i said =)

Impressive!

ViTi95 wrote on 2021-03-25, 00:02:

Here's a little update, textmode is fast even with CGA or EGA cards, the game framerate still relies on the CPU. This video shows the new textmode running on a 8-bit Trident EGA card (connected to a MCE2VGA i've recently acquired) in my 486DX-50.

https://youtu.be/fFrkKUQO61Q

I've been trying to think of ways to make entities like monsters and powerups easier to see in these low-res text modes. You're using the top-half / bottom-half CP437 characters 0xDC and 0xDF to make a pseudo 80x50 mode from 80x25 text mode, correct? If you're willing to sacrifice a bit of accuracy or a bit of vertical resolution, you could use different characters to draw entities.

• Perhaps the shade characters ░ , ▒, ▓ , (0xB0-0xB2) could be used for entities with the background/foreground colors chosen to dither the color of that whole block as closely as possible instead of a solid color for each half.
• I suspect it's not possible to use the half-left and half-right characters ▌(0xDD) and ▐ (0xDE) to draw twice as many columns and half as many rows for entities, since you found my earlier suggestion to render entities at full res in potato mode didn't work. If it would work, entities rendered at 160x25 would strongly stand out from a background rendered at 80x50.
• If it's not insane to detect edges of entities, you could boost the gamma of the edges of entities to outline them.

It's possible to use the shade characters for the VGA 80x50 mode, and apply that only to the sprites. That would make them look different and a bit easier to see. It's also doable for the 80x25 CGA and EGA modes, but the 80x25 resolution it's way to low for the sprites, the more vertical resolution, the better. This weekend I will release a test executable so people can test it and give feedback.

Edit: A little update, a basic status bar is now implemented 😁

I have released a new dev build, so everyone can test the new 80x25 video mode (virtual 80x50 resolution, 16 colors and CGA and EGA support!). This release includes the Doom shareware WAD so everyone can test this directly. There are some bugs to be fixed, but can give you an idea of how the new video modes work.

How to use:

• Option 1 (original Doom color palette, 256 colors to 16 color conversion): fdoom.exe -fixcolors
• Option 2 (using an optimized color palette, precalculated colors): fdoom.exe -file ega_pal.wad

If you have a CGA video card you have to add the command line parameter "-cga" in order to work properly.

Changelog:

• Better RAM usage (also reduced memory footprint)
• More code optimizations
• Compiled with the latest OpenWatcom v2 version
• Stripped episode finale texts from the executable, now are stored in external text files
• Support for Doom II BFG edition. Use the command line parameter "-bfg"
• New option to render the status bar background a little bit faster. Use the command line "-simplestatusbar". It replaces the status bar background with a simple grey color.
• New command line parameter "-cga", this let's the new video modes run properly with CGA video cards
• New command line parameter "-fixcolors", this is needed to correct the 256 to 16 colors conversion, as the original Doom palette is too dark for a direct conversion
• New video modes based on text modes: 80x25 (CGA, EGA and VGA supported, 16 colors and virtual resolution of 80x50) and 80x50 (VGA only, 16 colors). Both support triple buffering. Those video modes will be released as separated executables, in order to not slowdown the original Mode Y version. Also the new executables have reduced load times and reduced RAM usage.

https://github.com/viti95/FastDoom/releases/tag/0.8_DEV1

Executable: https://github.com/viti95/FastDoom/releases/d … om_0.8_dev1.zip

Hopefully this is not completely useless information to you.

I just played a bit of Freed∞m Phase 2 with a recent build of the experimental IWAD (which means a lot of new, possibly unpolished art, but maps should be vanilla compatible), using FDOOM2.EXE v0.7, 486 build in DOSBox. Played through MAP01 and started MAP02 with no issues, but then decided to check demo compatibility. The first demo started and played but then froze after about half a minute, possibly upon waking a monster. The same demo plays fine in the recent revision of MBF, not sure what would be the behaviour with the original DOOM2.EXE.

Please note that I was not really expecting 100% Freed∞m compatibility, but I do think that in theory it would be nice to have support for these IWADs, especially since the recent releases have been more or less vanilla-fied, so they should not be incompatible even with the original Doom binaries.

I'd also like to note that tested this with Gravis Ultrasound for sound and music in DOSBox, both sound really good.

Well, time for a new release. FastDoom 0.8. As always, here is the final changelog:

• Better RAM usage (also reduced memory footprint)
• More code optimizations
• Compiled with the latest OpenWatcom v2 version
• Stripped episode finale texts from the executable, now are stored in external text files
• Support for Doom II BFG edition. Use the command line parameter "-bfg"
• Smaller executable thanks to UPX compression tool
• New option to render the status bar background a little bit faster. Use the command line "-simplestatusbar". It replaces the status bar background with a simple grey color.
• Two new executables: FDOOMT25, which renders in text mode at 80x25 resolution (CGA, EGA and VGA supported, 16 colors and virtual resolution of 80x50) and FDOOMT50, which renders in text mode at 80x50 resolution (VGA only, 16 colors). Both support triple buffering. These executables have reduced even more the memory footprint as multiple graphics don't need to be loaded (fonts for example). Automap feature isn't supported. This release also includes the WAD ega_pal.wad, which replaces the original colormaps to a better one for text modes.
• New command line parameter "-cga", this let's the new video modes run properly with CGA video cards
• New command line parameter "-fixcolors", this is needed to correct the 256 to 16 colors conversion, as the original Doom palette is too dark for a direct conversion.
• Unified the 386 and 486 executables, the 486 executables were always slower and bigger than the 386 ones. Never figured out why this happens, maybe you can blame OpenWatcom.
• Unified executables between different versions of Doom onto a single one. The supported wads are the following:
  - DOOM.WAD -> DOOM Registered (3 episodes)
  - DOOM1.WAD -> DOOM Shareware (1 episode)
  - DOOMU.WAD -> Ultimate DOOM (4 episodes)
  - DOOM2.WAD -> DOOM II
  - PLUTONIA.WAD -> Final DOOM The Plutonia Experiment
  - TNT.WAD -> Final DOOM TNT Evilution
• New SETUP program! I've found how to edit and compile the original IDSETUP program, and modified it to create a custom version for FastDoom.
• Renamed the configuration file from default.cfg to fdoom.cfg. Also renamed save files from doomsav*.dsg to fdoomsv*.dsg.

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

Executable: https://github.com/viti95/FastDoom/releases/d … astDoom_0.8.zip
Uncompressed executable: https://github.com/viti95/FastDoom/releases/d … ncompressed.zip

@MrFlibble I will check that bug, and see if i can correct it for a bugfix release.

"Smaller executable thanks to UPX compression tool"
less size in storage , but probably more loading time ? coz it should expand itself on fly, brobably more resources needed at that time, i am not know how that exactly works, i just thinking.

Ehe Text mode and ega pal wad was epic =)
thanks for release)