Bug reports you say?

At first, using the direct rendering builds, I saw flickering (looked like different brightnesses?) on the uppermost line of the status bar; the backbuffered ones had straight up garbage there instead. Saw this across multiple runs at different resolutions... can't reproduce it at all now though. Dang.

The episode end screens are drawing their text vertically - probably just need the coords switched somewhere. And at 800x600, the background tiles are drawn incorrectly (think "interlaced video file"), and they don't fill the entire screen either (parts of the status bar left at the bottom).

Wondering if one could find a card with fast 800x600 VBE 2.0 and then stick it in a low end 386, turn it to low detail at 800x600 and have faster fast doom... guess it don't work like that.

BitWrangler wrote on 2024-01-15, 15:51:

Wondering if one could find a card with fast 800x600 VBE 2.0 and then stick it in a low end 386, turn it to low detail at 800x600 and have faster fast doom... guess it don't work like that.

I have 386DX-40 @ 45MHz with Diamond Speedstar 64 ISA (Cirrus Logic CL-GD5434, 2MB), supposedly fastest ISA videocard. I can try it out.

As i have not meticulously monitored the topic, maybe you could tell me exactly what exe file to use and what command parameters exactly to use to run the benchmark. 😀 And I'll report back, what result i got. 😜

ViTi95 wrote on 2024-01-14, 17:45:

The new modes are native resolution VESA 2.0 modes. The video card decides if it uses double-scan or not. Right now these resolu […]
Show full quote

The new modes are native resolution VESA 2.0 modes. The video card decides if it uses double-scan or not. Right now these resolutions are available:

- 320x200
- 320x240
- 512x384
- 640x400
- 640x480
- 800x600
- 1024x768
- 1280x1024

2.0? So with linear frame buffer support? Does it fall back to bank-switching on cards or video bioses that don't have that available?

Cool either way, though! 🙂

GigAHerZ wrote on 2024-01-15, 17:09:

BitWrangler wrote on 2024-01-15, 15:51:

Wondering if one could find a card with fast 800x600 VBE 2.0 and then stick it in a low end 386, turn it to low detail at 800x600 and have faster fast doom... guess it don't work like that.

I have 386DX-40 @ 45MHz with Diamond Speedstar 64 ISA (Cirrus Logic CL-GD5434, 2MB), supposedly fastest ISA videocard. I can try it out.

As i have not meticulously monitored the topic, maybe you could tell me exactly what exe file to use and what command parameters exactly to use to run the benchmark. 😀 And I'll report back, what result i got. 😜

I do have a VL-Bus motherboard for 386 and Trident TGUI9440, so I can give it a try. I'm pretty sure it will be running at 0.000...1 fps xD

digger wrote on 2024-01-15, 17:30:

2.0? So with linear frame buffer support? Does it fall back to bank-switching on cards or video bioses that don't have that available?

Cool either way, though! 🙂

Both banked and LFB are supported on backbuffered modes. Direct rendering mode requires LFB though, so no banked support on direct rendering. Also banked video modes support was added last minute, it's not as optimized as LFB.

digger wrote on 2024-01-15, 17:30:

2.0? So with linear frame buffer support? Does it fall back to bank-switching on cards or video bioses that don't have that available?

Cool either way, though! 🙂

...

EDIT: I've added support for banked VESA 320x200 direct mode, as the 320x200 framebuffer fits in a single 64kb window. Don't know if there is way to use a 128kb window and allow for bigger video modes (320x240, maybe something like 400x300).

elszgensa wrote on 2024-01-14, 20:57:

Bug reports you say?

At first, using the direct rendering builds, I saw flickering (looked like different brightnesses?) on the uppermost line of the status bar; the backbuffered ones had straight up garbage there instead. Saw this across multiple runs at different resolutions... can't reproduce it at all now though. Dang.

The episode end screens are drawing their text vertically - probably just need the coords switched somewhere. And at 800x600, the background tiles are drawn incorrectly (think "interlaced video file"), and they don't fill the entire screen either (parts of the status bar left at the bottom).

BTW thanks for the reports, I'll focus on fixing these bugs. The game is designed with a resolution of 320x200 in mind, so adding support for higher resolutions takes quite a bit of time. Still amazes me the job done by Doug.

I couldn't get sound or music working with SBEMU. This is the build of SBEMU I tested with. Sound and music are working with Doom v1.9.

Error messages from FastDoom:
Error initializing Music device: -1
Error setup Sound device: -1

SBEMU compatibility is still an issue, Sound Blaster initialization is not working properly. For now I've discovered that the DSP version is read as FF.01 instead of 3.01, so I need more to time debug what's really happening. As always, any help is appreciated.

EDIT: DOS sound code is the worst nightmare a developer could have

Not a developer myself, but by using this method it looks like SBEMU present DSP 3.02 as default (/T5).

Kamerat wrote on 2024-01-18, 01:44:

Not a developer myself, but by using this method it looks like SBEMU present DSP 3.02 as default (/T5).

Hey, that seems useful for anyone working on Sound Blaster emulation! Thanks for sharing. 🙂

ViTi95 wrote on 2024-01-17, 17:39:

SBEMU compatibility is still an issue, Sound Blaster initialization is not working properly. For now I've discovered that the DSP version is read as FF.01 instead of 3.01, so I need more to time debug what's really happening. As always, any help is appreciated.

EDIT: DOS sound code is the worst nightmare a developer could have

Probably needless to say, but please report any of your findings and insights about SBEMU in the SBEMU thread here on Vogons or on the SBEMU GitHub issues page, instead of working around such issues in FastDoom. Of course, patches and Pull Requests for SBEMU are absolutely welcome!

Ultimately, we need SBEMU to be as compatible as possible with actual Sound Blaster cards. If your code works properly on the actual hardware, it should work just as well with SBEMU, or at least that's the goal. Thanks for your insights and help with this! 🙂

EDIT: DOS sound code is the worst nightmare a developer could have

Indeed. All the more reason to add a proper abstraction for it, in the form of a proper API and modern drivers. It's a shame that the VBE/AI standard never took off back in the day, and was never extended to support protected mode and DPMI.

I'm still hoping that the AIL/32 driver model can be resurrected, with added support for Intel HDA and other more modern sound devices. But that's another topic.

I've uploaded a new bugfixing test release (just VESA HighRes fixes). Also I've added support for banked VESA 320x200 direct rendering.

https://github.com/viti95/FastDoom/releases/tag/0.9.9_test2

I want to do more changes but for now this is to check if everything is working fine. For example, pixel scaling is limited to 2x on some screens and HUD (not the gameplay), which I want to upgrade to make 3x and 4x available. Also I want to add 1280x800 support.

ViTi95 wrote on 2024-01-23, 07:24:

I've uploaded a new bugfixing test release (just VESA HighRes fixes). Also I've added support for banked VESA 320x200 direct rendering.

https://github.com/viti95/FastDoom/releases/tag/0.9.9_test2

I want to do more changes but for now this is to check if everything is working fine. For example, pixel scaling is limited to 2x on some screens and HUD (not the gameplay), which I want to upgrade to make 3x and 4x available. Also I want to add 1280x800 support.

Any chance of multiplayer support being reinstated in the future? Would love to do a death match with 386’s.

zuldan wrote on 2024-01-23, 07:51:

Any chance of multiplayer support being reinstated in the future? Would love to do a death match with 386’s.

Don't think so, we gained some fps after removing this feature, and the codebase underwent significant modifications following the removal of the multiplayer. Nevertheless, any developer can create a pull request to reintegrate this feature as an option if it doesn't make FastDoom slower.

ViTi95 wrote on 2024-01-23, 07:24:

I want to do more changes but for now this is to check if everything is working fine. For example, pixel scaling is limited to 2x on some screens and HUD (not the gameplay), which I want to upgrade to make 3x and 4x available. Also I want to add 1280x800 support.

Your FastDoom VESA binaries are working well for me. This is really great.

Any chance to add a 1366x768 binary and / or support 16:9 or 16:10 scaling? I don't know if this would even be possible in keeping the proper aspect ratio. The reason is that many of us have laptops with a native 16:9 display and so the 4:3 VESA modes look way out of proportion on these screens. And, most of these laptops have a native display of either 1366x768 or 1920x1080, so all other 4:3 modes are internally upscaled to these resolutions, anyway (but without aspect ratio correction).

As to getting SBEmu working with Fastdoom, the "hack" above to get the proper DSP version would appear to work, but how to implement this in the code and / or into FastDoom?

zyzzle wrote on 2024-01-27, 01:22:

Your FastDoom VESA binaries are working well for me. This is really great.

Any chance to add a 1366x768 binary and / or support 16:9 or 16:10 scaling? I don't know if this would even be possible in keeping the proper aspect ratio. The reason is that many of us have laptops with a native 16:9 display and so the 4:3 VESA modes look way out of proportion on these screens. And, most of these laptops have a native display of either 1366x768 or 1920x1080, so all other 4:3 modes are internally upscaled to these resolutions, anyway (but without aspect ratio correction).

As to getting SBEmu working with Fastdoom, the "hack" above to get the proper DSP version would appear to work, but how to implement this in the code and / or into FastDoom?

For now aspect ratio is fixed, I'm pretty sure it's possible to modify it but maybe it's a bit out of scope, don't know if there are video cards that support those resolutions for VESA 2.0 modes. I've added support for 1280x800 resolution, and support for pixel scaling 3x (1024x768) and 4x (1280x800 and 1280x1024), now 2D items scale much better. As an example, this is my Compaq NX7300 running at 1280x800

Regarding SBEMU, I'm still debugging what's wrong. The Apogee Sound System works fine with SBEMU on games like ROTT or Duke3D, so maybe any of the optimizations I've added to the sound library is breaking SBEMU.

ViTi95 wrote on 2024-01-17, 17:39:

SBEMU compatibility is still an issue, Sound Blaster initialization is not working properly. For now I've discovered that the DSP version is read as FF.01 instead of 3.01, so I need more to time debug what's really happening. As always, any help is appreciated.

Well, I played a bit with Fastdoom and can say that it partially works with both SBEMU and VSBHDA. There are a few issues:

- hdpmi32i should be loaded with the -x option, since the DOS32A extender isn't happy if too much free memory is offered
- if Soundblaster FM music is enabled, a crash will happen. Soundblaster SFX works, though!
- It must be ensured that hdpmi is used as DPMI host for Fastdoom. I achieved this by entering "JEMMEX NOVCPI" before launching fastdoom.

I also compiled Fastdoom with Watcom v1.9, creating a HX binary instead of DOS32A - it works.

So then it seems an issue in the DOS32A 32-bit extender, or an incompatibility between it and SBEMU. I'm going to try your settings on my laptop and the eBox, and see if it behaves in the same way. Thanks Baron for testing! 😄

EDIT: It works on my HP Compaq NX7300, but as you said, it crashes when Adlib / Sound Blaster music is selected. PCM music is working though.

https://youtu.be/lwKfzuXirxY?si=dsSOz9v_dM9YM7h0

EDIT2: How do you stub HX on FastDoom?

Sorry that I didn't know the incompatibility problem until recent days, I've created a PR so FastDoom can work with HDPMI, and maybe for win9x too.