ViTi95 wrote on 2021-05-24, 17:14:

Aaaaand new release!! :D […]
Show full quote

Aaaaand new release!! 😁

FastDoom 0.8.1

• New video modes!!
  • VGA Mode 13h (320x200 256 colors, without page flipping). Same mode as Heretic/Hexen. Only high detail mode is implemented, but it's usually faster than the original Mode Y. Recomended for fast 486 processors and upwards
  • CGA (320x200 4 colors). Ugly, needs a better conversion algorithm. Requires a fast CPU. Based on Mode 13h
  • CGA (640x200 monochrome, ordered dithering 2x2). Requires a fast CPU. Based on Mode 13h
  • EGA (320x200 16 colors, page flipped, 128Kb VRAM minimum). SLOW, most ISA 8-bit EGA video cards can't update fullscreen at decent framerates. Based on Mode 13h
  • Hercules (640x400 monochrome, ordered dithering 2x2). Requires a fast CPU. Based on Mode 13h
• Added basic IWAD selector on bootup (if multiple IWADs are detected)
• Fixed Super Shotgun animation
• As always more optimizations. Now text modes are much faster
• Fixed multiple bugs
• Removed color correction parameter "-fixcolors" for 16 color modes. Easier to use

https://github.com/viti95/FastDoom/releases/d … tDoom_0.8.1.zip

oh my! your work and knowledge are simply amazing, i'll have to test it in my desktop 386 and in my 386 laptop to see it work
don't know if it was answered already but, can it run sigil?

SIGIL support is in the to-do list, the problem adding SIGIL support is that it requires uprising some vanilla doom limits, and that makes the executable use more ram memory.

ViTi95 wrote on 2021-05-24, 20:17:

SIGIL support is in the to-do list, the problem adding SIGIL support is that it requires uprising some vanilla doom limits, and that makes the executable use more ram memory.

ohh i see, i thought the biggest issue was that visplanes limit, but it makes sense as the levels are more complex and should need more horsepower and memory

Hmm, i wonder, what speed of serial link one needs to run Doom in text mode over serial in terminal? 😁

Nice release !

Any chance for DEH support too ?

Why do you not recomment 13h for slower 486s (33/40MHz) isn't that where it ought to help most?

@appiah4 it depends, some systems are faster with mode 13h and others not. Mode Y is the standard and it's valid for both slow and fast cpu's (thanks to potato and low detail modes). Also the mode 13h lacks page flipping and that causes screen tearing, problem that Mode Y doesn't have.

@xcomcmdr DEH support is also in the to-do list, I don't know exactly how it works and what changes are required to add support for it for now.

@GigAHerZ I'd love see FastDoom running over a serial terminal. For now you can play it in a Windows 9x terminal 😁

BUG REPORT: Selecting General MIDI causes lockup with PCMIDI MPU401 card, selecting Sound Canvas works. This behaviour is not the same as normal Doom. Different sound engine? Regardless of whichever I pick, I get random lockups at Doomguy start screen if I try to use an external MIDI device.

Testing 13h mode on Cx5x86-120 (With SB Music and 8-ch SB Sound)

Mode Y: 57,377 fps
Mode 13h: 79,079 fps (+37,82%)

I can't wait to try FDOOM13H.EXE on my U5S-33 - I'm pretty sure it will make Doom 1 very playable 😀

Also, where is the documentation? I can't seem to find a list of command switches.

Also..

FEATURE REQUEST Mouse Sensitivity 😀

new mode in 0.8.1 works great on the MiSTer FPGA AO486 core. Core in debug mode at 100MHZ with both L1 and L2 turned on. HIRAM was king, EMM386 and QEMM drop the average by 1 fps.
Timedemo runs:
doom: 31.04
fdoom: 32.084
fdoom13h: 36.109

Amazing work. Highest I've seen in the demo run at 47.1 at one point.

ViTi95 wrote on 2021-05-24, 21:54:

@xcomcmdr DEH support is also in the to-do list, I don't know exactly how it works and what changes are required to add support for it for now.

Cool ! I might send a PR for it once I understand it better. It seems quite complicated when looking at prboom+

Tested out FDOOM and FDOOM13H on my Cyrix MII 300 - very impressed with the results. The 13H mode introduces screen tearing so I won't be using that, but 'standard' FDOOM looks and sounds great with the new sound library, so I'll give it a more thorough play test over the next few days.

1doom (sound disabled in setup)
2110 FPS
3
4fdoom -timedemo demo3 -nosound
5126 FPS
6
7fdoom13h -timedemo demo3 -nosound
8164.2 FPS

Anybody besides me having lockup issues with General MIDI / Sound Canvas options in FDOOM?

appiah4 wrote on 2021-05-25, 11:53:

Anybody besides me having lockup issues with General MIDI / Sound Canvas options in FDOOM?

Nope working for me, using a YMF718 based card with an NEC XR385 attached to the wavetable header. Port 330.

I noticed in the github notes that there's a -vsync option, this didn't fix the screen tearing in the 13H mode though.

I also noticed that when used with DOOM2 (full version), FDOOM.EXE works fine but if you let a demo start in-game then it exits with a message "Demo is from a different game version!"

What dat about?

Is your DOOM2 version 1.9?

@appiah4 What cards, configuration and ports are you using? I've tested a NEC XR385 and an Ensoniq SoundscapeDB on an Aztech card and it works without problems at port 330. BTW I'll update the readme file including all new command line options. Regardles mouse sensitivity, you can change it from in-game options menu.

@badmojo I'll check the vsync and mode 13h combination, it might be not working right. The demo problem you've found is indeed a bug that I have to fix, happens with all IWADs, thanks for noticing it. I guess I made a mistake when unifying all the executables onto a single one.

ViTi95 wrote on 2021-05-25, 15:52:

@appiah4 What cards, configuration and ports are you using? I've tested a NEC XR385 and an Ensoniq SoundscapeDB on an Aztech card and it works without problems at port 330. BTW I'll update the readme file including all new command line options. Regardles mouse sensitivity, you can change it from in-game options menu.

Hi, I listed it as a bug report on the git but here you go:

Biostar 8433UUD-A
IBM Cx5x86-100@120MHz
Macronix MX86200 2MB
Sound Blaster 16 (A220 I5 D1 H5 P300)
PCMIDI MPU-401 I/O (P330)
2GB Sandisk Ultra CF-IDE
LG 16x DVD-RW

Maybe having two different MPU devices is causing the confusion?

ViTi95 wrote on 2021-05-25, 15:52:

@badmojo I'll check the vsync and mode 13h combination, it might be not working right. The demo problem you've found is indeed a bug that I have to fix, happens with all IWADs, thanks for noticing it. I guess I made a mistake when unifying all the executables onto a single one.

Thanks very much, count me in as a tester for these issues or anything else I can help with. What you've done so far is brilliant 👍

Anyone else getting some random lockups with version 0.8.1? With both fdoom and fdoom13h

This is with my TI486SXLC bridgeboard. Sometimes the machine will hard lockup whilst playing, sometimes it hard locks on quitting (for example once it’s completed a timedemo).

If I go back to 0.8 or previous releases the game seems completely stable.

I also seem to get the following warning upon quitting the game and returning to dos

DOS/32A warning (9003): real mode interrupt vector had been modified: INT xxx

I can’t recall what the xxx was at the moment but I think it was 43h! 😀

DOS/32A warning (9003): real mode interrupt vector had been modified: INT xxx

These will occur with allmos all games where you replace DOS4GW with DOS32A

I just (null) these text strings out from the DOS32A.EXE, I am kind a OCD with those kind of "annoyances"....

These errors are not fatal in any form.

I've added a classic README.txt file in the 0.8.1 release, it includes all command line parameters detailed @appiah4. Debugging the new discovered errors is hard, but i'll try to fix them as soon as possible.