Well some news about the Apogee Sound System GUS code, I've asked Jim Dosé if there was any source code available that uses hardware mixing instead of software mixing:

Sadly there is no source code available, so I guess we will have to spent some time learning how GUS and hardware mixing work.

What about Recreation of differing revisions of the Apogee Sound System codebase?

(I haven't looked if it has GUS hardware mixing.)

More or less a cross-post from the Doomworld thread for FastDoom, but I'm posting here for anyone who wants to give comments on things that could use with an improvement. Please give it a test!

My biggest issue with FastDoom is that as of 0.9.3, all non-VGA palettes have a COLORMAP lump that makes everything fullbright in-game, as if the player has a permanent light-amp. Since this is effectively a cheat, I've decided to revamp all of the non-VGA palettes to get something that is closer in spirit to how the COLORMAP lump from the IWADs portray sector brightness. Obviously downsampling from 256 colours to 16 colours/4 colours/monochrome requires a bit of artistic interpretation, but all things considered I feel this is a good effort towards something closer to VGA.

I've already submitted a patch for FDOOMHGC and FDOOMBWC (which has been merged into git) as the main improvement for those was simply changing the threshold for drawing pixels based on luminosity in the source code, to the point that MODEBW.WAD no longer requires a PLAYPAL lump and only needs a COLORMAP lump for better vision with the invul colormap. As for everything else - I streamed a playthrough of all of the IWADs using FDOOMEGA, making tweaks here and there when a few edge cases had appeared. The PLAYPAL is based off the existing one in MODE16.WAD and improved for a somewhat better palette translation for static graphics, while the COLORMAP is very heavily modified based off the COLORMAP from IWADs to the point where it's effectively close to being remade from scratch. There probably is some finer tweaking that can be done to both PLAYPAL and COLORMAP especially with the less common areas of the standard palette, but this should be a significant improvement over the existing non-VGA palettes. Some notes:

* I duplicated palette sheet 4 into palette sheet 3 in PLAYPAL as it seemed a bit weird that the berserk effect was fading away too quickly
* MODETXT is the same as MODE16, but with COLORMAP adjusted for how the text modes utilise the colormap
* MODECVBS is based off MODE16, but COLORMAP has transitions from dark red->dark gray->black changed to dark red->black as the dark gray is significantly brighter than dark red on my IBM old-style CGA
* MODE4 is based off MODECVBS, but has the invul colormap modified for better visibility

I will eventually get around to making a MODE4 that better utilises the limitations of CGA (mainly that it needs a better balance of red vs. brown), but it's acceptable for the time being. The EXEs included in the ZIP are compiled from the latest commit as of this post.

An amusing side effect is that for every non-VGA mode except FDOOMV16 and the text modes, there's generally a significant performance increase (especially with FDOOMEGA and FDOOMBWC) with timedemo results when the CPU bottleneck is removed, though this is highly dependent on the level, regressions are rare (DEMO2 from Ultimate Doom, DEMO2 from Doom 2 and DEMO2 from Plutonia being the only built-in examples). FDOOME uses MODE16D.WAD, which as far as I can tell is just simply PLAYPAL pulled from an IWAD without modification.

EDIT: got a response from viti regarding MODE16D on DW. Meanwhile I looked at MODE4 with FDOOMCGA -palette1 and noticed how awful some of the leftover transitions from dark colour shades->dark gray->black that I had kept from MODE1 6 had looked as there was a lot of random white pixels being drawn everywhere, so I've improved MODE4.

EDIT 2: removed attachments as I wasn't expecting a release this quickly, see below post from viti

New release! FastDoom 0.9.4. Changelog:

- PCM music support. Up to 44.1 KHz, 8-bit mono music. For now PCM music is stored in RAM, so more than 16Mb is recommended
- Tandy 3-voice SN76489 sound support. Sound quality is nowhere near good, but can be improved
- Sound frequency is now selectable (from 7KHz up to 44.1KHz). Removed "-lowsound" parameter since is not needed anymore
- Updated PLAYPAL+COLORMAPS for B&W, 4-color and 16-color modes thanks to @deat322 (@Deathz0r). The image quality is much better now on non-256 color modes
- Fixed issues #95, #133, #134 and #135
- Made source code buildable again on 8.3 filesystems (DOS)
- Updated FDSetup program
- Removed "Tandy Sound Source" sound card. This was the same as Disney Sound Source, but for old Tandy with incompatible parallel port

As always, have fun. https://github.com/viti95/FastDoom/releases/tag/0.9.4

I wasn't expecting the release to be this quick! I also realised I forgot to include comparison shots in my last post, so here's a quick glimpse at the start of Monster Condo (doom2 MAP27) for comparison:

VGA

FDOOMEGA 0.9.3

FDOOMEGA 0.9.4

FDOOMBWC 0.9.3

FDOOMBWC 0.9.4

FDOOMHGC 0.9.3

FDOOMHGC 0.9.4

Finally, a video I made showing all of the demos of each IWAD with FDOOMBWC from my IBM old-style CGA via composite output:
https://www.youtube.com/watch?v=WRpB0EOz-zE

I figure a custom PLAYPAL will be needed for FDOOMBWC (and kept separate from FDOOMHGC) to iron out the rough edges of static images such as the HUD - I should be hopefully able to get to that sooner than later.

DEAT wrote on 2023-03-15, 05:44:

Since this is effectively a cheat

You can't possibly be serious?

The non-VGA versions are so difficult to see compared to anything higher resolution that it's already insanely more difficult to make out what's going on no matter how "bright" it appears.

Your own screenshots show how little good the extra brightness does to have any advantage

I couldn't give a rat's ass about it being a chet but the current pallette is definitely a lot more in tune with the spirit of the game, and more recognizable as being that level.

appiah4 wrote on 2023-03-16, 07:11:

I couldn't give a rat's ass about it being a chet but the current pallette is definitely a lot more in tune with the spirit of the game, and more recognizable as being that level.

Exactly.

Great job, DEAT. 👍

I have been following DEAT on Twitch and he sometimes streams working on these new COLORMAP lumps, I personally think this looks way better than it being stuck at full bright, and it takes some dedication to figure out how to pull this off without the light diminishing getting "salt & peppered" by occasional bright pixels of the palette.

Nice work, DEAT! I like how the lighting looks on non-VGA video modes in the current version. 👍

I understand the argument but ...

7F20 wrote on 2023-03-16, 05:38:

You can't possibly be serious? […]
Show full quote

DEAT wrote on 2023-03-15, 05:44:

Since this is effectively a cheat

You can't possibly be serious?

The non-VGA versions are so difficult to see compared to anything higher resolution that it's already insanely more difficult to make out what's going on no matter how "bright" it appears.

Your own screenshots show how little good the extra brightness does to have any advantage

... what he said.

However, since I notice the rear third of the depth of view is what gets hard to see on VGA and these modified versions that appears to kick in at the end of the front third of the depth of view, that it is considerably overdone, and some darkening should kick in closer on non-VGA perhaps, but not basically just out of fist/chainsaw range.

Thanks for the positive comments! I started working on a proper CGA palette yesterday (rather than using the 16-color PLAYPAL and letting FDOOMCGA convert it to 4-colors) and I've noticed that the COLORMAP for the 16-color WADs could do with a few improvements with regards to the part of the palette that is used by the torso of the Hell Knight/beige crates in E2M2, and a couple of obscure parts of the palette that stand out more prominently when I had converted the COLORMAP to the CGA palette. Blues look much better when they're being rendered as green/cyan instead of being a mess of brown and black! Sadly, nothing I can do will make megaspheres look anything but a solid brown/white blob simply due to the palette indices that are used for the sprite and the fact it's always rendered at full brightness. Trying to change the darker blues to make the eyes visible on the soulsphere messes up with navigating the dark blue hallway of E2M4 - there's always some compromise that needs to be made.

7F20 wrote on 2023-03-16, 05:38:

You can't possibly be serious?

Did I stutter? Congrats on focusing on the wrong part of that statement, by the way.

7F20 wrote on 2023-03-16, 05:38:

Your own screenshots show how little good the extra brightness does to have any advantage

I'll entertain your white-noise comment with what happens if you start doom2 MAP27 with FDOOMEGA without MODE16.WAD, relying on the PLAYPAL and COLORMAP lumps from DOOM2.WAD instead:

BitWrangler wrote on 2023-03-16, 21:45:

However, since I notice the rear third of the depth of view is what gets hard to see on VGA and these modified versions that appears to kick in at the end of the front third of the depth of view, that it is considerably overdone, and some darkening should kick in closer on non-VGA perhaps, but not basically just out of fist/chainsaw range.

There's several things to consider here which lead to my current decisions on how to create the COLORMAP for 320x200 non-VGA.

The most significant with improving visibility that would be a greater overall benefit is if FastDoom was able to convert the textures used in a map into dithered 4/16 colours when entering a map to produce better results with visible geometry - doing the same for sprites would be a nice addition, but the Icon of Sin makes that already unreliable as monster sprites won't be pre-cached, unless there was code to scan for the presence of a monster spawner and then it could convert all monster sprites spawned by IoS. I had a discussion with zokum from Doomworld while streaming a playtest of the EGA palette, and an idea that popped up was converting into an image format that only contains information for 4/16 colours which would reduce RAM usage rather than keeping around unnecessary data.

The reduction in RAM usage has known benefits, especially with <=4MB of RAM - using the vanilla DOS EXE as a reference (no idea how FastDoom handles it, but it does have a -ram parameter to allocate all RAM instead of 8MB), a very texture-heavy map will cause microstutters if there's a large amount of visible animated textures as it needs to drop textures that are not visible while trying to allocate newly visible textures. This was a problem I specifically pointed out to the lead dev of KDiKDiZD while I was beta testing Z1M3/MAP15 as it was originally using an engine trick to show 128 frames for animated textures; this was reduced to 32 frames in the release version.

Of course, all of what I mentioned with converting graphics simply does not happen in FastDoom - the current code instead looks at the RGB value of a palette indice and simply tries to convert it to the nearest valid RGB value, which does sound more CPU efficient but I haven't spent enough time looking at the code to determine if that RGB conversion happens at runtime or if its processed each frame. It does appear that FDOOME/FDOOMATI does something different but I haven't looked too deep into that yet.

The conversion of RGB values to nearest valid results is precisely what is happening with the screenshot above - the map design of each of the IWADs generally favour middle shades gravitating towards darker shades, and results in a lot of #555555 or #000000 with the standard EGA palette because of how COLORMAP works. Want to make a guess at what happens when converting to the CGA palette when using the PLAYPAL and COLORMAP from DOOM.WAD/DOOM2.WAD/TNT.WAD/PLUTONIA.WAD? But wait - there's a twist! You'll find maps or areas of maps that are significantly brighter than normal (DOOM E3M6, outdoor areas of most of DOOM E1, the outside area of DOOM2 MAP26 being three examples I can immediately think of) where you're more likely to see the geometry without MODE4/MODE16 to assist, and then you have maps/areas of maps that are significantly darker than normal (the soulsphere secret in DOOM E1M3, DOOM E2M4, DOOM2 MAP27, TNT MAP08, a good part of TNT MAP20, the DISASTER AREA of TNT MAP27, Plutonia MAP23) which will ultimately look like the screenshot above. The way I designed the COLORMAP for 4/16 colour modes is to try to use black for shading whenever reasonably possible - this does work generally well, but some textures such as METAL2 (prominently used in TNT MAP08) just simply can't work. So what's the solution, make everything brighter? You risk gradually heading towards a situation where you can't distinguish a dark area from a moderate section.

Something I should note is that the PLAYPAL from MODE16 in versions prior to 0.9.4 generally remaps the first palette sheet to the nearest EGA colour without much consideration of artistic interpretation with the notable exception for palette indices 152-159, which favours green instead of gray shades. This also means that very dark shades get translated to pure black. Translating those very dark shades to the darkest shades of colour in the EGA palette risks the geometry being less distinguishable in general, not to mention details on monster sprites like the torso of Hell Knights/Barons. A useful tweak for getting a bit more detail in the COLORMAP for 16 colours is to add a single line of #555555 around colours where the COLORMAP would have normally transitioned from a dark shade to black helps a lot, but while this can work to some extent with the green/red/brown/black CGA palette, it looks extremely awful with the cyan/magenta/white/black palette. There is one specific part with the 4/16 colour palettes that just looks outright bad and there's no good solution that I can currently think of - rooms where both the walls and the floor/ceiling are mid-bright gray, such as the room where the red skull key is in DOOM E3M9, the room that leads to the blue skull key in DOOM2 MAP19 and the room where the yellow skull door is in TNT MAP20.

The way I designed the COLORMAP is somewhat a logarithmic scale - there can be a bit of tweaks in the lower end, but given how the COLORMAP works I need to be careful around the darkest sector brightness and how the depth field lighting works. There isn't a straight-forward solution for 4/16 colours - currently the monochrome modes don't even use a custom PLAYPAL, and the COLORMAP within MODEBW only modifies the invul colormap for better visibility. The code patch I made for tweaking the monochrome values were based around the lowest threshold that was able to generate the lowest luminosity before completely screwing up the HUD and making it completely unreadable. This was chosen as a baseline for custom WADs that may have PLAYPAL and COLORMAP lumps that differ from the IWADs. It's something that I'll look into eventually for the monochrome modes.

Consider the entire spectrum of officially released maps, don't base it on how good you can get an opening shot of E1M1.

Something i've been working on, Sigma Designs Color 400 support. 320x200 and 16 colors. It's possible to use 640x200 or 640x400 and 16 colors, but the card is already too slow, so no point on adding support for those. The VRAM layout is very similar to the Plantronics ColorPlus, but uses different planes for red/green and blue/intensity combination (which makes it slower as a OUT instruction is required to change between planes).

One thing I've discovered is that this card is really picky, it doesn't work on fast cpu's (at least on 86Box). I've been able to make it work on a simulated 386SX. I did also buy one card but it didn't work on my 386DX nor my 486 (now I have to try on something slower).

Maybe it's been covered and I've missed it, but how about a few degrees of dithered shades in CGA and EGA modes, as is already done in Hercules (FDOOMHGC)? Even an extra 4 or 16 "colors" achieved by blending with black (in a checkerboard pattern) would add tons of flexibility to brightness tuning.

BTW, things like fonts, HUD elements, and static screens could definitely use customized versions which are hand-tuned to the target palettes (yeah, I'm basically volunteering here).
Ideally the same would go for textures and sprites, but perhaps that would introduce a different sort of colormap headaches.

In my testing dithering only looks fine when higher resolution than 320x200 is available, otherwise small fonts become barely readable. That's why only 640x200 and 640x400 video modes have 0rdered dithering, with 2-to-1 or 4-to-1 pixel ratio without distortion.

I didn't put much effort into creating custom graphics just because I still not consider non 256-color modes a priority (that's why those modes do 256-color backbuffer conversion in realtime, is faster in dev time that spending time on creating custom graphics). Anyway any help and ideas is always welcome, Deat has done an excellent job getting better visuals for non-256 color modes.

There is one thing that I want to upgrade in EGA modes though. Right now the 320x200 and 16 color mode internally uses a resolution of 640x200, so it's possible to create a better LUT (basically a 2-to-1 ordered dithering). This way I could remove the slow-as-hell 640x200 EGA mode, and make the "320x200" mode much better.

DEAT wrote on 2023-03-17, 14:03:

I'll entertain your white-noise comment with what happens if you start doom2 MAP27 with FDOOMEGA without MODE16.WAD, relying on […]
Show full quote

I'll entertain your white-noise comment with what happens if you start doom2 MAP27 with FDOOMEGA without MODE16.WAD, relying on the PLAYPAL and COLORMAP lumps from DOOM2.WAD instead:

How gracious of you your majesty. 🙄

Anyway, I see how much better the colors are now, so thanks for that and for contributing to this project that I enjoy. I'm still not totally sure about much visibility there will be, and my eyes aren't really up to the task the same way they used to be. It looks like there is a lot of development efforts going on still, so hopefully things will keep evolving and there will be more granular control over such things in the future.

New feature that will come to FastDoom 0.9.5, translucent invisible objects rendering (like Heretic and Hexen do)

since some people are already talking about cga, why not give the undocumented 160*100*16color mode a try?

FastDoom already supports CGA 160x100 16-color mode, and the upgraded ANSI from Hell 320x100 16-color mode 😁

https://youtu.be/_6Jft32G3ls
https://youtu.be/ut0V1nGcTf8

ViTi95 wrote on 2023-03-27, 20:36:

In my testing dithering only looks fine when higher resolution than 320x200 is available, otherwise small fonts become barely readable. That's why only 640x200 and 640x400 video modes have 0rdered dithering, with 2-to-1 or 4-to-1 pixel ratio without distortion.

I didn't put much effort into creating custom graphics just because I still not consider non 256-color modes a priority (that's why those modes do 256-color backbuffer conversion in realtime, is faster in dev time that spending time on creating custom graphics). Anyway any help and ideas is always welcome, Deat has done an excellent job getting better visuals for non-256 color modes.

Here's a simplified manual mock-up of what I was thinking about. It's identical to the current EGA rendering, except for the areas that are currently mapped to black - which are replaced with dither patterns (black alternating with some other color, or even with more than one).

In other words, that could work if the colormap was able to dither *only* the darker colors. It's still brighter than the VGA palette overall, but not as bright as 0.9.3 EGA. The dithered areas lose some detail, but this only happens where you'd otherwise get black anyway - so it may be a good compromise between the current rendering and the original intent.

Just an idea; don't know how feasible it is, and it may simply turn out ugly. (Although if it was possible to implement using the colormap, I'm sure it would look better than my manually-doctored screenshot.)