Hello, I saw some YouTube video from ViTi95 running FastDoom in EGA 640x200 16 colors with dithering.
Is it possible to try it from official build ? I took a look at the README and try many of the executables. None of them offers dithering.

640x200 EGA was deprecated for being too slow a few major versions ago

vsharun wrote on 2024-06-19, 09:58:

Well, several constraints are involved: 1. only DOS 2. only PCI soundcards, Ensoniq/Creative with cleanest possible sound 3. ma […]
Show full quote

Well, several constraints are involved:
1. only DOS
2. only PCI soundcards, Ensoniq/Creative with cleanest possible sound
3. maximum compatibility (Dune2 for example - jemmex with maxmem)
what platform will be the fastest one for doom/q1/q2/duke3d.

Okay, so you're not doing any of this to solve an issue, it's all basically a personal project to get FastDoom (and not actual Vanilla regular Doom) to run on a narrow description of hardware that is self-imposed. Gotcha. Good luck!

So sorry about everything going on in the Ukraine. My thoughts are with all of you out there.

tigrou wrote on 2024-06-20, 23:19:

Hello, I saw some YouTube video from ViTi95 running FastDoom in EGA 640x200 16 colors with dithering.
Is it possible to try it from official build ? I took a look at the README and try many of the executables. None of them offers dithering.

leileilol wrote on 2024-06-21, 02:34:

640x200 EGA was deprecated for being too slow a few major versions ago

Yes, the 640x200 EGA dithered mode was deprecated for two reasons. First the chunk-to-planar process required to convert the 320x200 256 color backbuffer to a 640x200 16 color planar is really CPU intensive, too much even for a fast 486. Second, EGA cards are mostly 8-bit ISA, which have a very limited bandwidth available. In worst case scenario, you need to update 64.000 bytes from VRAM, 35 times per second. That requires 2187Kb/s transfer rate, while 8-bit ISA bus only goes up to ~940kb/s in my tests.

The current EGA executable uses this 640x200 resolution, but generates a non-dithered 320x200 image. This way I can use latch copy tricks to avoid the chunky-to-planar conversion and bottlenecking the ISA bus.

7F20 wrote on 2024-06-21, 04:18:

Okay, so you're not doing any of this to solve an issue, it's all basically a personal project to get FastDoom (and not actual Vanilla regular Doom) to run on a narrow description of hardware that is self-imposed. Gotcha. Good luck!

Imagine you would like to run fastdoom on 386/16 MDA and it crashes for some reason (bios incompatibility, clock jitter, address space overlap, dunno) and then you heard your insults in respond.
So yes, and this is my contribution to the project as a bug reporter/tester within specific usecase.

ViTi95 wrote on 2024-06-21, 06:21:

Yes, the 640x200 EGA dithered mode was deprecated for two reasons. First the chunk-to-planar process required to convert the 320x200 256 color backbuffer to a 640x200 16 color planar is really CPU intensive, too much even for a fast 486. Second, EGA cards are mostly 8-bit ISA, which have a very limited bandwidth available. In worst case scenario, you need to update 64.000 bytes from VRAM, 35 times per second. That requires 2187Kb/s transfer rate, while 8-bit ISA bus only goes up to ~940kb/s in my tests.

It makes me think about a possible cool retro hardware project: a graphics card that can connec to TTL RGB monitors (CGA and EGA) and provide a VGA/MCGA-compatible chunky 13h mode, which would then dither the virtual 320x200 256 color graphics to 640x200 in 16 colors in hardware. It would be even better if such a card could somehow leverage the capabilities of EGA monitors so that it could show all 64 colors on screen at once. Combine that with pulse-width modulation techniques, and perhaps you'd even be able to show 256 unique colors as well. 😅

And finally, have such a card have a 16-bit ISA card, with downwards compatibility with 8-bit slots if 16-bit slots aren't available.

I know, such a card historically never existed, but it would be cool if such hardware would make it possible to show almost-VGA-quality graphics on EGA monitors, and finally being to fully leverage the theoretical capabilities of those monitors.

I don't have the expertise to make something like that myself, but given the many cool retro hardware projects that people have been coming up with, perhaps this is not such a crazy idea? Worth a separate topic here on Vogons, perhaps?

digger wrote on 2024-06-21, 10:09:

It makes me think about a possible cool retro hardware project: a graphics card that can connec to TTL RGB monitors (CGA and EGA) and provide a VGA/MCGA-compatible chunky 13h mode, which would then dither the virtual 320x200 256 color graphics to 640x200 in 16 colors in hardware. It would be even better if such a card could somehow leverage the capabilities of EGA monitors so that it could show all 64 colors on screen at once. Combine that with pulse-width modulation techniques, and perhaps you'd even be able to show 256 unique colors as well. 😅

Maybe the easiest way to do this would be to just use a VGA card and build a converter to turn the VGA signal into EGA. You would actually be able to do better than 640 horizontal pixels, as EGA has effectively infinite horizontal resolution.

Yeah, an adapter would indeed be an even better idea. And why stop at VGA? Perhaps make a DVI-to-TTL adapter, given how at least the color signals are digital to begin with. 😄

Good one about cranking up the horizontal resolution. It might allow for even better dithering.

Cool idea @digger. Maybe it's possible to modify a standard VGA card with separated DAC IC, and replace it with a Pico or FPGA PCB that outputs TTL EGA signals. Imagine having real time 640x350 64 color output with dithering.

I find the huge number of different executables a tad inconvenient. Could it be possible to merge them into a single executable and switches or maybe integrate the renderer option into fdsetp?

Is there any plan to disable walls texturing ? (eg: to render "flat walls", just like visplanes).
Same about sprites.
Yes the game would looks like potato, but on a very slow computer that might be a good tradeoff vs playing the game in small viewport.

digger wrote on 2024-06-21, 10:09:

It makes me think about a possible cool retro hardware project: a graphics card that can connec to TTL RGB monitors (CGA and EGA […]
Show full quote

ViTi95 wrote on 2024-06-21, 06:21:

Yes, the 640x200 EGA dithered mode was deprecated for two reasons. First the chunk-to-planar process required to convert the 320x200 256 color backbuffer to a 640x200 16 color planar is really CPU intensive, too much even for a fast 486. Second, EGA cards are mostly 8-bit ISA, which have a very limited bandwidth available. In worst case scenario, you need to update 64.000 bytes from VRAM, 35 times per second. That requires 2187Kb/s transfer rate, while 8-bit ISA bus only goes up to ~940kb/s in my tests.

It makes me think about a possible cool retro hardware project: a graphics card that can connec to TTL RGB monitors (CGA and EGA) and provide a VGA/MCGA-compatible chunky 13h mode, which would then dither the virtual 320x200 256 color graphics to 640x200 in 16 colors in hardware. It would be even better if such a card could somehow leverage the capabilities of EGA monitors so that it could show all 64 colors on screen at once. Combine that with pulse-width modulation techniques, and perhaps you'd even be able to show 256 unique colors as well. 😅

And finally, have such a card have a 16-bit ISA card, with downwards compatibility with 8-bit slots if 16-bit slots aren't available.

I know, such a card historically never existed, but it would be cool if such hardware would make it possible to show almost-VGA-quality graphics on EGA monitors, and finally being to fully leverage the theoretical capabilities of those monitors.

I don't have the expertise to make something like that myself, but given the many cool retro hardware projects that people have been coming up with, perhaps this is not such a crazy idea? Worth a separate topic here on Vogons, perhaps?

IDK about never existed, it sounds kinda familiar, like some Paradise or Video7 card in the super early VGA times, 2 sockets on it, 9 pin and 15pin, maybe an RCA for composite also, big bank of switches and maybe also jumpers... might be on minuszerodegrees in the 3rd party area... though it's not like there are piles of surplus EGA monitors around any more to have a large market for a repro, probably the opposite would be more popular, EGA convertor for a VGA monitor.

appiah4 wrote on 2024-06-21, 11:34:

I find the huge number of different executables a tad inconvenient. Could it be possible to merge them into a single executable and switches or maybe integrate the renderer option into fdsetp?

Backbuffered modes with same resolution can be merged into a single executable, for example FDOOM13H, FDOOMEGA and FDOOMCGA. The issue is that the executable will be bigger, and thus less RAM for assets, etc. will be available. Maybe I can add an option on FDSETUP to select which video mode will run (like in Duke3D setup program), and a launcher that reads fdoom.cfg and launches the executable selected.

tigrou wrote on 2024-06-22, 10:17:

Is there any plan to disable walls texturing ? (eg: to render "flat walls", just like visplanes).
Same about sprites.
Yes the game would looks like potato, but on a very slow computer that might be a good tradeoff vs playing the game in small viewport.

Yeah for sure, this idea is still in my to-do list. Disabling wall texturing is quite easy, and should be a good speed up. Even I have an idea of a wireframe mode, that should be even faster (draw only first and last pixel for each column), similar to what MDA mode does.

ViTi95 wrote on 2024-06-22, 14:53:

The issue is that the executable will be bigger, and thus less RAM for assets, etc. will be available.

quake 2 DOS peeps (neozeed?) figured out how to make dynamically loadable libraries (DLLs) work under dos.

Q2DOS is compiled with DJGPP which supports DXE libraries. The same can't be trivially done with FastDOOM as it uses the DOS/32A extender where DLLs aren't an option.

Why aren't DLLs an option with the DOS/32A DOS extender?

Because DOS/32A in its current state has no way to handle DLLs, at least AFAIK.

Someday I'll make DJDoom, my Doom port that compiles with DJGPP, as fast as FastDoom.
And then DLLs are possible.

digger wrote on 2024-06-21, 10:09:

It makes me think about a possible cool retro hardware project: a graphics card that can connec to TTL RGB monitors (CGA and EGA) and provide a VGA/MCGA-compatible chunky 13h mode, which would then dither the virtual 320x200 256 color graphics to 640x200 in 16 colors in hardware. It would be even better if such a card could somehow leverage the capabilities of EGA monitors so that it could show all 64 colors on screen at once. Combine that with pulse-width modulation techniques, and perhaps you'd even be able to show 256 unique colors as well. 😅

And finally, have such a card have a 16-bit ISA card, with downwards compatibility with 8-bit slots if 16-bit slots aren't available.

I know, such a card historically never existed, but it would be cool if such hardware would make it possible to show almost-VGA-quality graphics on EGA monitors, and finally being to fully leverage the theoretical capabilities of those monitors.

Some Tandy 1000 models support a 640x200 16 color mode with chunky pixels at 0xA000.

Gmlb256 wrote on 2024-06-23, 14:43:

Because DOS/32A in its current state has no way to handle DLLs, at least AFAIK.

Maybe I should clarify my question: why would a DOS extender have a role in whether an application can dynamically load code from a DLL file or not? Or asked differently: what aspect of DOS/32A precludes the use of DLLs?

I'm asking this, because I tried to build the AIL/32 drivers a while back, which are DLLs, and try to link the example applications with DOS/32A, and indeed this led to some kind of run-time error. Not sure if that's related to what you alluded to.

Sorry if this is a bit off-topic.

digger wrote on 2024-06-24, 13:50:

Maybe I should clarify my question: why would a DOS extender have a role in whether an application can dynamically load code fro […]
Show full quote

Gmlb256 wrote on 2024-06-23, 14:43:

Because DOS/32A in its current state has no way to handle DLLs, at least AFAIK.

Maybe I should clarify my question: why would a DOS extender have a role in whether an application can dynamically load code from a DLL file or not? Or asked differently: what aspect of DOS/32A precludes the use of DLLs?

I'm asking this, because I tried to build the AIL/32 drivers a while back, which are DLLs, and try to link the example applications with DOS/32A, and indeed this led to some kind of run-time error. Not sure if that's related to what you alluded to.

Sorry if this is a bit off-topic.

DLLs weren't originally designed for 32-bit protected mode DOS. However, some DOS extenders did provide capabilities to dynamically load code from a separate file.

One way of achieving this was by using and abusing overlays which DOS/4GW supports. The AIL/32 drivers were compiled that way.