Thanks for this great (de)port, runs very nicely on my MiSTer FPGA computer 😀
The original DOS version is a little slow.
Hopefully you'll carry on enhancing it for us old school users
That setup looks really dope! Right now FastDoom development is a little slow, as I'm currently stuck trying to add AC97 and IBM XGA support. Next release will have some important bugfixes made by @RetroUnch, and some optimizations for ISA 8-bit cards. Also some fixes for the snow issue on original IBM CGA cards for 80x100 and 160x100 modes (text modes won't be fixed), and the option to use the Palette 1 on CGA cards for the 320x200 and 4 colors mode.
Fun fact: @Frenkel has discovered that FastDoom is being used on the HomeComputerMuseum in Helmond (Netherlands). I've never expected to see something I've created on a museum ^^
AC-97 and possibly additional PCI soundcard support will be wonderful. There is already a version which runs with sound on Intel HDA soundcards. It's a variant of ZDOOM, I believe.
I copied DOOM.WAD from my doom directory to the FastDOOM directory, I launch the game and after a few seconds it exits with the message "Demo is from a different game version!"... The DOOM.WAD is from a vanilla install with the original disk images.
Any ideas please?
EDIT: I should have looked closer at the README which clearly states:
"All of them must be the 1.9 version to work fine."
(Decommissioned:)
zyzzle wrote on 2022-09-29, 09:20:AC-97 and possibly additional PCI soundcard support will be wonderful.
well the AC97 support is kind of tricky part, as you have to support at least two diffferent PCI controller interfaces (Intel/ALi and VIA), resample everything to 48khz and run a MIDI synthesizer like TiMidity or FluidSynth in thebackground :)
Back when I was writing drivers for my sound library I had enough hassle with HDA codecs and eventually gave up on YMF7x4 :D
--wbcbz7
wbc wrote on 2022-10-02, 21:10:well the AC97 support is kind of tricky part, as you have to support at least two diffferent PCI controller interfaces (Intel/ALi and VIA), resample everything to 48khz and run a MIDI synthesizer like TiMidity or FluidSynth in thebackground 😀
Back when I was writing drivers for my sound library I had enough hassle with HDA codecs and eventually gave up on YMF7x4 😁
Thanks for confirming and the additional insight.
I had heard rumors that AC '97 could only use 48khz audio, everything needed to be resampled to 48k, and it wouldn't work with 22.05 or 44.1 khz natively. Other AC '97 / PCI soundcard player / detection programs exist for bare metal DOS (eg: Judas, Mplayer DOS port, MPXplay, and Quickview Pro 2.61, for example)
Is Intel HDA and IDH the same? (all audio is sampled at 48 khz internally)?
AC97 1.x only supports 48 KHz operation, while in AC97 2.x additional frequencies are optional. The Apogee Sound System can do resampling in real time, so that's not a big issue. Right now I've been able to port the initialization process from the JUDAS library, next step will be make it sound properly.
For now I will include only PCM support, so music will come later.
I just came across an idea, if we have enough of RAM, what about implementing texture mip-mapping? I guess it will not have a much performance impact on wall and sprite rendering (plus it's complicated anyway due to the way sprites are stored) , but for textured flats it can theoretically boost the performace, as they are stepped by both U and V coordinates during texture mapping. additionally it can improve picture quality a bit (the distance dimming kind of hides minification artifacts already)
--wbcbz7
Very interesting idea @wbc, yeah having mipmaps requires more memory, but could accelerate rendering quite a bit and make visuals better. It's true that I'm no expert in 3D graphics, so don't know if i'll be able to develop these ideas onto FastDoom (again, any help is always welcome)
I'd imagine that would add too much overhead to the span drawer. Probably more efficient to pull a Descent and just make distant walls flat (though that wasn't very performance effective on Descent either). With less texture detail in Doom, you'd still be drawing as many pixels to make the lines.
How Quake treated mipmapping is that everything had to be processed into the surface cache (a dynamic texture canvas where the lightmaps are blended in) and then the span drawer draws from that cache. The span functions don't know what mipmaps are. Disabling mipmaps would make an overly big surface cache that'll skip surfaces it can't allocate and be slower. Doom doesn't have that kind of penalty.
thanks for the tech insight, that explains why Quake becomes horribly slow and RAM-hungry with d_mipscale set to 0 :)
--wbcbz7
Having a lot of fun with Fast Doom right now. The Hercules mode is super fun, I wish I had this in 1986 to play on my little Heath Zenith luggable number. I know it wouldn't have been fast enough, but it would have blew my mind. The EGA version is pretty awesome too, I wonder if it's runnable on a 386 with an ATI all-in-wonder card in it?
The low resolution EGA executables maybe are usable on a 386, fdoome16.exe (160x100 16-colors) and 80x100 (80x100 136 "colors") fdoome36.exe should work a little bit faster than the 320x200 EGA mode, since those modes avoid having to convert the screen from chunky to planar graphics, and the drawn resolution is less than the original. The new release will incluide a new mode that renders pretty fast thanks to the write mode 2 from EGA cards, although the resolution is only 80x200. Aaaand I'm investigating a possible hack to make 320x200 EGA mode much faster, still is a work-in-progress and don't know if it will be doable at all. Basically I'm prerendering blocks of pixels permutations on the VRAM, and thanks to the write mode 1 latch copy, move only required blocks to the screen minimizing the number of writes to the VRAM (and also avoiding the chunky2planar process).
New release! FastDoom 0.9
This is a major release since lot's of fixes were done. Here is the changelog:
Fantastic release !
I'm looking into integrating (in the far future, when it has 32 bit code, and other than only VGA Mode 13h support 😁 ) a FLOSS or freeware software into my DOS Emulator CI/CD testing.
FastDoom with FreeDoom assets could be a viable option.
Sadly, I didn't find a LICENSE file. Did I miss it ?
FreeDoom (Phase 1+2) has been tested on the new release and the crashes has been fixed. About the licensing, well I'm no expert in licensing (and really don't care much about it), but I'll take a look.
ViTi95 wrote on 2022-10-14, 07:20:The low resolution EGA executables maybe are usable on a 386, fdoome16.exe (160x100 16-colors) and 80x100 (80x100 136 "colors") fdoome36.exe should work a little bit faster than the 320x200 EGA mode, since those modes avoid having to convert the screen from chunky to planar graphics, and the drawn resolution is less than the original. The new release will incluide a new mode that renders pretty fast thanks to the write mode 2 from EGA cards, although the resolution is only 80x200. Aaaand I'm investigating a possible hack to make 320x200 EGA mode much faster, still is a work-in-progress and don't know if it will be doable at all. Basically I'm prerendering blocks of pixels permutations on the VRAM, and thanks to the write mode 1 latch copy, move only required blocks to the screen minimizing the number of writes to the VRAM (and also avoiding the chunky2planar process).
Cooool. That's really exciting! Thanks for the update. Do you think a 486 would do a better job, or is it mainly the ATI Wonder card that would be a bottleneck?
Yeah a 486 would do a much better job, use one whenever possible. It's more than 2 times faster compared to the 386s usually.
Well, I've finally finished the EGA 160x200 mode using Write Mode 1. I think it can be modified to do 320x200 in the same way, but with a reduced number of colors as there isn't enough VRAM available for the trick to work. Here are some tests with different EGA modes on a Trident Paradise EGA 8-bit ISA (Fullscreen without HUD, 486DX-50):
- EGA Write Mode 2 80x200: ~32fps
- EGA Write Mode 1 160x200: ~20fps
- EGA 320x200: ~14fps
Modes 80x200 and 160x200 can be even faster as visplane rendering is not 100% fully optimized.
Here's a video demo of it working:
Amazing job there... I see that and wonder why they didn't do an Amiga 500 port like it back in 1993 🤣
Unicorn herding operations are proceeding, but all the totes of hens teeth and barrels of rocking horse poop give them plenty of hiding spots.
