That's exactly the idea, but as 386/486 CPUs aren't powerful enough to do the pattern-matching in real time, let's use a powerful CPU to make a translation LUT. It's possible to make it full 320x200 but using insane amounts of memory (or reducing the number of colors too much).

Basically the idea is to read the backbuffer in chunks of 4 pixels, reduce the number of colors to 16, and then use the LUT to get the best character/color (foreground+background) match. There are 65536 total possible combinations of those 16 colors in 4 pixels, and knowing that we need two bytes per character, the total LUT size is those 128Kb. It's not as good as analyzing the whole 256 color image and do pattern matching, but should be enough to make it more playable.

Reading that in my mind come flashes that CGA has several palettes and it might be possible to change on fly to use more colors but that might be very very slow?

ViTi95 wrote on 2022-10-21, 17:09:

Basically the idea is to read the backbuffer in chunks of 4 pixels, reduce the number of colors to 16, and then use the LUT to get the best character/color (foreground+background) match. There are 65536 total possible combinations of those 16 colors in 4 pixels, and knowing that we need two bytes per character, the total LUT size is those 128Kb. It's not as good as analyzing the whole 256 color image and do pattern matching, but should be enough to make it more playable.

Ah, yeah I follow you.

What I had in my head was a 256-color 4x2 slice. I suppose it's unreasonable to expect a DOS PC to have 18 exabytes of RAM for lookup tables...

Just for fun, here's what DOOM looks like through reenigne's cgaart program in ANSI from hell mode : https://www.youtube.com/watch?v=l485yX41z24

(Even on a modern PC it's extremely non-realtime... likely optimizable/threadable though)

Looks very very cool, but I think it has the same issue as my EGA 640x200 dithered mode. The 16 CGA colors don't match well with the dark Doom palette, and that makes the image difficult to see. I'm pretty sure it will look much better with the adapted 16 color playpal + colormap.

RaVeN-05 wrote on 2022-10-21, 19:02:

Reading that in my mind come flashes that CGA has several palettes and it might be possible to change on fly to use more colors but that might be very very slow?

I think it's possible to change it between scanlines with very strict timings, and that is very difficult task to do. Maybe some expert here can show us how it's really done.

Colour correction helps a little - https://www.youtube.com/watch?v=8_d4Cozj7WY

Don't think it's worth spending any more time on though... interested to see how your approach works out

rasteri wrote on 2022-10-22, 19:40:

Just for fun, here's what DOOM looks like through reenigne's cgaart program in ANSI from hell mode : https://www.youtube.com/watch?v=l485yX41z24

(Even on a modern PC it's extremely non-realtime... likely optimizable/threadable though)

That's awesome! Yeah, CGAArt only uses one thread for matching at the moment - doing that on a GPU has been on my list for ages as all the character/attribute combinations could in principle be tested in parallel. Another feature I'd like to implement is temporal error diffusion which would either improve colour fidelity or image stability (depending on how it's used) when processing videos like this.

reenigne wrote on 2022-10-29, 09:49:

That's awesome! Yeah, CGAArt only uses one thread for matching at the moment - doing that on a GPU has been on my list for ages as all the character/attribute combinations could in principle be tested in parallel. Another feature I'd like to implement is temporal error diffusion which would either improve colour fidelity or image stability (depending on how it's used) when processing videos like this.

Temporal dithering is something I've experimented with but I've never got it to look good. Interested to see what you can manage.

I wonder if it would be possible to speed things up by implementing a kind of ordered dither... like have a pre-defined static pattern of 8x2 chars. Or flick between two patterns at 60hz. I think part of area 5150 does something like that?

rasteri wrote on 2022-10-29, 12:22:

I wonder if it would be possible to speed things up by implementing a kind of ordered dither... like have a pre-defined static pattern of 8x2 chars. Or flick between two patterns at 60hz. I think part of area 5150 does something like that?

Yes, some of the effects in Area 5150 treat the screen as 80x100 "pixels", and have a lookup table from a 9 bit RGB colour (3 bits per channel) to a character/attribute combination (only characters b1/8e/b0/1d/14/7f are considered, so that they look like nice dither patterns). It's very fast, but the results aren't as nice as CGAArt's slow method.

I've finished the precalculated LUT and made it work, the quality is a little bit better but far from perfect. Maybe a better comparison formula could get better results. Anyway, the scripts have been uploaded in GitHub, so anyone can modify and test as wish (the FastDoom rendering code will be uploaded tomorrow when I clean it up). Here are two pictures comparing the original CGA 160x100 mode against the CGA Ansi From Hell 320x100:

Also video: https://youtu.be/PXU7wiJPndY

ViTi95 wrote on 2022-10-31, 01:27:

Also video: https://youtu.be/PXU7wiJPndY

Wow that's nuts... looks incredible!

Video running on real hardware, the IBM CGA is a bit slow to do full screen updates (and the snow fix slows it down even further), but works pretty nice on newer CGA cards.

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

Oh wow. Hoping I can try this out at some point.

It will be available in the next release, I want to fix a crash in Plutonia's MAP12 that has appeared on the 0.9 release and didn't exist before. As of now this is the changelog:

- C/MS (Game Blaster) music support thanks to Tronix286
- New EGA 320x200 mode, it's a bit faster compared to the older one but only supports 14 colors (based on Write Mode 1)
- Updated FDSetup program, command line parameter "-mono" for MDA/Hercules graphics cards
- Add SBK soundfont support for AWE32/AWE64 sound cards, command line parameter "-sbk" to select the SBK. Also thanks to Tronix286.
- New ANSI from Hell mode for CGA cards, 320x100 resolution with 16 colors

ViTi95 wrote on 2022-11-01, 10:42:

- Add SBK soundfont support for AWE32/AWE64 sound cards, command line parameter "-sbk" to select the SBK. Also thanks to Tronix286.

Woah! Finally a new feature that's not a bizarre eye bleeding video mode to get excited about 😁

maxtherabbit wrote on 2022-11-01, 14:19:

Woah! Finally a new feature that's not a bizarre eye bleeding video mode to get excited about 😁

Hey...! I've been enjoying the hell out of these bizarre eye bleeding video modes...! 😁

ViTi95 wrote on 2022-11-01, 10:42:

- Add SBK soundfont support for AWE32/AWE64 sound cards, command line parameter "-sbk" to select the SBK. Also thanks to Tronix286.

Very nice to get SBK SoundFont support for AWE cards natively! 👍

Gmlb256 wrote on 2022-11-01, 21:15:

ViTi95 wrote on 2022-11-01, 10:42:

- Add SBK soundfont support for AWE32/AWE64 sound cards, command line parameter "-sbk" to select the SBK. Also thanks to Tronix286.

Very nice to get SBK SoundFont support for AWE cards natively! 👍

Why is this a thing? Can't it be loaded at driver level in DOS and then the card can be used in GM mode in Doom?

SBK load support natively avoids having to load AWEUTIL + DOS32AWE, I guess later we can replace the PAWE32.LIB from the SBK version to the SF2 version and make it work with SF2 soundfonts.

ViTi95 wrote on 2022-11-02, 07:56:

SBK load support natively avoids having to load AWEUTIL + DOS32AWE, I guess later we can replace the PAWE32.LIB from the SBK version to the SF2 version and make it work with SF2 soundfonts.

Now that would be useful.. But as is, I fail to see the point. Using AWEUTIL + DOS32AWE is really not an issue, nothing that can run DOOM should have memory issues with those I'd think. (Also, can't UNISOUND also load SBKs?)