I have a question about the sound buffer size in FastDOOM. I see a 16x buffer (NumberOfBuffers) instead of a standard double buffer used. I'm wondering what led to that decision? I've looked into the SB mixing code and its not clear to me that it has any kind of advantage. Is it maybe non-soundblaster related or am I missing something?

That value is the default for the Apogee Sound System. I'm not exactly sure why they use 16 buffers for sound mixing. Maybe it's set that high for sound cards that require multiple samples to be prepared in advance before being sent to the device. For example, the Disney Sound Source could receive up to 14 sound packets.

Hi, any chance to set target aspect ratio for resolution ? And 1600x1200 please ?
Love to play doom with ESS1868/wp32 (LPC2ISA project) on i5-4690k @4.5GHz, some 300-ish fps 1280x1024.

Yes, adding 1600x1200 resolution is possible, but proper aspect ratio support is not currently planned.

ViTi95 wrote on 2025-05-09, 06:49:

Yes, adding 1600x1200 resolution is possible, but proper aspect ratio support is not currently planned.

Because 320x200 is 1.6 and 1600x1200 is 1.33 I supposed. It integer scales, but only if you use 5:6.

But wouldn't that mean that the only "true" upscaled ratio, then is 640x400 (1.6:1) or 1280x800, since it maintains the 1.6:1 ratio? Others such as 800x600 (4:3), 1024x768 (4:3), 1280x1024 (1.25:1) are also not in the 1.6:1 "native" aspect ratio. Or, am I missing something and you do integer scaling AR correction on those other supported VESA resolutions?

Do you account for pixel aspect ratio or screen aspect ratio? It's a confusing issue, since all of the above resolutions could be actually displayed in a 4:3 AR on a regular CRT screen.

zyzzle wrote on 2025-05-10, 03:45:

But wouldn't that mean that the only "true" upscaled ratio, then is 640x400 (1.6:1) or 1280x800, since it maintains the 1.6:1 ratio? Others such as 800x600 (4:3), 1024x768 (4:3), 1280x1024 (1.25:1) are also not in the 1.6:1 "native" aspect ratio. Or, am I missing something and you do integer scaling AR correction on those other supported VESA resolutions?

Do you account for pixel aspect ratio or screen aspect ratio? It's a confusing issue, since all of the above resolutions could be actually displayed in a 4:3 AR on a regular CRT screen.

My question was about "fit" resolution to the panel aspect ratio. While 320:200 is 16:10, other hires SVGA modes are 4:3 = vertically compressed on 16:10 screen, more on 16:9. And my thought was: if we have one 16:10 mode and lot of 4:3 then we have some geometry correction in place and under-the-hood tunable may be wired outside.

zyzzle wrote on 2025-05-10, 03:45:

Do you account for pixel aspect ratio or screen aspect ratio? It's a confusing issue, since all of the above resolutions could be actually displayed in a 4:3 AR on a regular CRT screen.

Doug Johnson did the VESA modes, not viti95. My assumption would be that Johnson would have had to make each resolution available to the native renderer of the Doom engine, and the engine took care of PAR. So I think that probably would be an outside request to Johnson to make a new VESA resolution available, not to viti95.

Look back around January of 2024 when the VESA resolutions got added. I asked a bunch of questions about it then.

I can add new VESA modes, in fact I already did this for the 1280x800 resolution executable. The main issue is that I don't have any native 1600x1200 display, so I'd need to test it using emulators.

EDIT: Already working on it 🤭​

ViTi95 wrote on 2020-06-23, 23:06:

<snip>
The main differences between the original Doom and FastDoom are these (as of version 0.4):

How difficult would it be to add CMOV support (and possibly MMX+SSE) to Fastdoom?

Hear me out please: Yes, I know this is supposed to be for old machines - but lately you have released new executables... I find the FDM768R particularly attractive -- 1024x768 looks very crisp on a native LCD whereas lower res modes are blurry. The trouble is, even with write combining enabled, you need an extremely fast processor to get a consistently good FPS -- either an extremely fast P4 or K7/K8.

Conversely, Quake in software rendering mode easily reaches near 100FPS with a decent setup (in my case, Tualatin 1.4Ghz) because Quake uses more modern CPU instructions...

I often find myself wanting to play Doom when I have pure DOS mode but find this limitation prohibitive.

Perhaps it's time for some new executables?

Thanks

Quake wasn't using 'more modern' instructions. Also how quake renders is extremely different from how Doom does it - all the lighting is applied to a surfacecache, and that blob of surfacecache is where all the optimized spans work from. If you want to see that in action for Doom, there's Vavoom.

Also I believe leveraging the FPU was already explored with no resulting gain.

leileilol wrote on 2025-05-13, 00:59:

Quake wasn't using 'more modern' instructions. Also how quake renders is extremely different from how Doom does it - all the lighting is applied to a surfacecache, and that blob of surfacecache is where all the optimized spans work from. If you want to see that in action for Doom, there's Vavoom.

Also I believe leveraging the FPU was already explored with no resulting gain.

What about compiling with CMOV? Surely that's going to vastly improve integer performance on newer CPUs, no (forgive my ignorance please)?

leileilol wrote on 2025-05-13, 00:59:

Also I believe leveraging the FPU was already explored with no resulting gain.

I remember watching a youtube video about this awhile ago. IIRC, Doom is coded using fixed point math operations, so it can't be made to speed up with an FPU. Quake was specifically created to take advantage of the Pentium's fully pipelined FPU, and the code is optimized for that kind of math.

AFAIK, it's not as simple as tossing things into a different compiler, it would be a fundamental change to the underlying code.

There is a really great video that explains the difference between Fixed Point and FP in coding: https://youtu.be/i1phJl-0v54?si=32dhy5utfwQSL45V

I have some ideas to improve the performance of hires VESA modes. First of all, I plan to add again non-unrolled drawing functions for columns and spans (selectable). I'm quite sure the unrolled code becomes too large at higher resolutions, which likely causes a performance hit on CPUs with small L1/L2 caches. As for newer instructions, I believe MMX could offer a good speedup. Not just because of its SIMD capabilities, but also thanks to the additional registers it provides.

EDIT / Slightly OffTopic: Development has slowed down a bit lately, as I'm currently focused on other side projects, this time unrelated to retro hardware or programming. In fact, I'm now doing endurance racing in a '97 Civic 😄

ViTi95 wrote on 2025-05-13, 16:04:

First of all, I plan to add again non-unrolled drawing functions for columns and spans (selectable).
<snip>
instructions, I believe MMX could offer a good speedup. Not just because of its SIMD capabilities, but also thanks to the additional registers it provides.

I eagerly await this 😀

ViTi95 wrote on 2025-05-13, 16:04:

EDIT / Slightly OffTopic: Development has slowed down a bit lately, as I'm currently focused on other side projects, this time unrelated to retro hardware or programming. In fact, I'm now doing endurance racing in a '97 Civic 😄

Quite a change of pace, in more ways than one. 😅

Have fun, and stay safe!

ViTi95 wrote on 2025-05-13, 16:04:

EDIT / Slightly OffTopic: Development has slowed down a bit lately, as I'm currently focused on other side projects, this time unrelated to retro hardware or programming. In fact, I'm now doing endurance racing in a '97 Civic 😄

That's amazing. I am working on a 91 Civic with a friend currently; hope to make it rally worthy.

Any chance we'll ever see a FastDoom version/port with 286 support trough something like DOS|286 (TNT DOS) Extender or DOS/16M?

I know about Doom8088 and RealDoom ports, but they still seem so immature.

analog_programmer wrote on 2025-05-14, 08:22:

Any chance we'll ever see a FastDoom version/port with 286 support trough something like DOS|286 (TNT DOS) Extender or DOS/16M?

Fastdoom is written is for 32bit processors, it doesn't really make sense to have 16-bit binaries compile from the same codebase. It would just be a total mess.

rasteri wrote on 2025-05-14, 09:01:

Fastdoom is written is for 32bit processors, it doesn't really make sense to have 16-bit binaries compile from the same codebase. It would just be a total mess.

I thought it's mainly written in C, not 32-bit specific assembly.