VOGONS


Reply 480 of 565, by NovaCoder

User metadata
Rank Newbie
Rank
Newbie

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

Attachments

Reply 481 of 565, by ViTi95

User metadata
Rank Member
Rank
Member

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 ^^

Attachments

Reply 483 of 565, by mockingbird

User metadata
Rank Oldbie
Rank
Oldbie

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."

jw0vu3.png
(Decommissioned:)
7ivtic.png

Reply 484 of 565, by wbc

User metadata
Rank Member
Rank
Member
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 :)

more rattle

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

Reply 485 of 565, by zyzzle

User metadata
Rank Member
Rank
Member
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 😀

more rattle

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)?

Reply 486 of 565, by ViTi95

User metadata
Rank Member
Rank
Member

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.

Attachments

  • FeE6M8XX0AMtGlb.jpg
    Filename
    FeE6M8XX0AMtGlb.jpg
    File size
    505.51 KiB
    Views
    767 views
    File comment
    eBox 3350 HDA initialization in FastDoom
    File license
    CC-BY-4.0

Reply 487 of 565, by wbc

User metadata
Rank Member
Rank
Member

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

Reply 488 of 565, by ViTi95

User metadata
Rank Member
Rank
Member

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)

Reply 489 of 565, by leileilol

User metadata
Rank l33t++
Rank
l33t++

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.

apsosig.png
long live PCem

Reply 491 of 565, by 7F20

User metadata
Rank Member
Rank
Member

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?

Reply 492 of 565, by ViTi95

User metadata
Rank Member
Rank
Member

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).

https://youtu.be/pBoqGv9fMKs

Reply 493 of 565, by ViTi95

User metadata
Rank Member
Rank
Member

New release! FastDoom 0.9

This is a major release since lot's of fixes were done. Here is the changelog:

  • Fixed lot's of crashing bugs. May be a performance impact, but it's better than crashing the whole game. Huge thanks to @RamonUnch for discovering the issues, fixing them, and providing extensive testing in lots of maps and demos.
  • Added commandline parameter "-palette1" to enable the black-cyan-magenta-white palette on CGA 320x200 mode.
  • Added commandline parameter "-snow" to enable a fix snow bug in IBM CGA cards on modes 160x100 16-color and 80x100 136-color.
  • Added basic compatibility levels support. Now demos wont desync. Also again huge thanks to @RamonUnch. And thanks Decino for the marvelous video explaining the compatibility levels.
    • Added commandline parameter "-complevel X" to select any compatibility level
    • Supported compatibility levels are:
      • 2 -> Doom 1.9 (also Doom II)
      • 3 -> Ultimate Doom
      • 4 -> Final Doom
  • Added OPL2LPT and OPL3LPT support by Jordi Sesmero (@jsmolina)
  • Added new video mode FDOOME80.EXE => FastDoom EGA 80x200 16-color. This video mode is 640x200 EGA mode with write mode 2 enabled, so we can write 8 pixels at the same time with a single 8-bit write (that's 32-bit written at once, and avoiding the chunky2planar process). Should perform well on 8-bit ISA EGA cards.
  • Updated FastDoom Setup program with the new music devices. Also small visual fixes.
  • As always small optimizations here and there.

https://github.com/viti95/FastDoom/releases/tag/0.9

Reply 494 of 565, by xcomcmdr

User metadata
Rank Oldbie
Rank
Oldbie

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 ?

Reply 495 of 565, by ViTi95

User metadata
Rank Member
Rank
Member

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.

Reply 496 of 565, by 7F20

User metadata
Rank Member
Rank
Member
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).

https://youtu.be/pBoqGv9fMKs

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?

Reply 498 of 565, by ViTi95

User metadata
Rank Member
Rank
Member

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:

https://www.youtube.com/watch?v=mF3kf_sIcUE

Reply 499 of 565, by BitWrangler

User metadata
Rank l33t
Rank
l33t

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.