Frenkel wrote on 2024-06-24, 06:57:

Someday I'll make DJDoom, my Doom port that compiles with DJGPP, as fast as FastDoom.
And then DLLs are possible.

Yep, DJGPP is a much better compiler than OpenWatcom. Generated x86 executables are much better on DJGPP. Also step-by-step debugger is not working for me on OpenWatcom (this is a huge pain to deal with) and the lack of native "DLL" support leads to bigger executables.

Many FastDoom bugs come from not having a proper way to debug it.

One of my todo's is to port FastDoom to DJGPP, but my time available for the project is really low right now. Right now I'm adding Dreamblaster S2P support to FastDoom, and later on I'll continue on hardware accelerated AWE32 sound FX support.

ViTi95 wrote on 2024-06-25, 07:25:

port FastDoom to DJGPP

maybe neozeed will be interested. He is big on compiler quirks/hacking https://github.com/neozeed

I'm testing the latest FastDoom on my IBM ThinkPad A21m. It seems to run fine but when I run FDSETUP the system locks up in DOS and crashes with an illegal operation in Windows. This ThinkPad uses a Crystal SoundFusion that utilizes a CWCDOS TSR for Soundblaster compatibility in DOS. The SoundFusion works fine in vanilla Doom and Doom 2.

ViTi95 wrote on 2024-06-25, 07:25:

Yep, DJGPP is a much better compiler than OpenWatcom. Generated x86 executables are much better on DJGPP. Also step-by-step debugger is not working for me on OpenWatcom (this is a huge pain to deal with) and the lack of native "DLL" support leads to bigger executables.

To be honest, OpenWatcom creates much compact executable, DJGPP is just mess for specified platform (just adding possibility to crash). Really nothing to crave for. With let's say very marginal gain in speed (as we know, isn't computing power the main bottleneck but video transfers through slow buses). OK, maybe the debugger is nice feature. But that's all. I'm talking from personal experience.

Don't bother with DLL's in DOS. DOOM never been customized for dynamic modules. There is always nice feature to add specified module at compile time. 😉

tigrou wrote on 2024-06-22, 10:17:

Is there any plan to disable walls texturing ? (eg: to render "flat walls", just like visplanes).
Same about sprites.
Yes the game would looks like potato, but on a very slow computer that might be a good tradeoff vs playing the game in small viewport.

Finally I've added this, it's indeed faster but gameplay gets compromised. Most switches now are not visible, so you have to remember the maps to be able to play them.

Untextured walls with diminished lightning

Untextured walls without diminished lightning

As a side effect, also sprites can be draw untextured:

This will be available on the next release 😁

You're getiing closer to ASCII Doom.

Just kidding. Keep on good job with optimizations for good old bare metal 😉

I wish there was a *nix port of FastDoom.

ViTi95 wrote on 2024-07-09, 09:54:

As a side effect, also sprites can be draw untextured:

Silhouette Doom.

May as well draw brick lines on that and call it "compatible with major brick construction toys" Doom.

(What they put on the lego knockoffs)

next step, don't draw anything at all!

Even if some draw mode option looks useless it can still be used to determine overall rendering cost of particular subsystem in absence of proper profiling.
Of course profiling would be the ultimate tool for the job. For example I wonder how much % is spend on rendering vs game logic (bsp traversal etc). BSP code is something nobody ever tried to optimize, and there have been some innovations/discoveries/new algorithms since 1993 😀 Maybe this is an undiscovered not so low hanging fruit?
I think Abrash mentioned in his Black Book Carmack discovering perfect zero redraw optimal algorithm for Doom ... while working on Quake 😁 (maybe portals like duke3d?). Carmack had similar epiphany about Wolf3D when making Doom, but at least that idea (bsp instead of ray scans?) was implemented in SNES port.

congrats you've made promode doom

rasz_pl wrote on 2024-07-09, 21:53:

BSP code is something nobody ever tried to optimize, and there have been some innovations/discoveries/new algorithms since 1993 😀 Maybe this is an undiscovered not so low hanging fruit?

There ware some BSP optimizing tools for the .wad files, I don't know if this counts.

analog_programmer wrote on 2024-07-10, 13:07:

rasz_pl wrote on 2024-07-09, 21:53:

BSP code is something nobody ever tried to optimize, and there have been some innovations/discoveries/new algorithms since 1993 😀 Maybe this is an undiscovered not so low hanging fruit?

There ware some BSP optimizing tools for the .wad files, I don't know if this counts.

I meant new algorithm for BSP traversal, converting into more optimal data structure/algorithm on map load, or at the very least optimizing current implementation by rewriting slowest portions in assembly. It all depends on what % of CPU is spend on this on something like 486DX40.

Rawit wrote on 2020-06-30, 06:44:

The video/source files makes it look like you're using the DMX sound library?

APODMX. On the fly conversion from MUS to MIDI.

vswitchzero has uploaded a YouTube video about FastDoom 😄

https://youtu.be/9zAI8K7OzDQ?si=i5Xv0Q8qcDnGjTyb

ViTi95 wrote on 2024-07-16, 17:10:

vswitchzero has uploaded a YouTube video about FastDoom 😄

https://youtu.be/9zAI8K7OzDQ?si=i5Xv0Q8qcDnGjTyb

love his videos. He's done a lot for people trying to repair old video cards. 👏👏👏

@Viti95

I'm sorry to bother you, I downloaded the latest fastdoom version and I noticed that the Int 13 version has the limit of 367 ticks on the benchmark, I tried several video cards they all top at 367 despite with an older version I was able to reach at least 361.

rasz_pl wrote on 2024-07-09, 21:53:

For example I wonder how much % is spend on rendering vs game logic (bsp traversal etc).

There's a command line option in original DOOM to disable rendering entirely and still do Timedemo. Few years ago I've tested this on 25 MHz 386SX and DOOM without rendering was able to run at it's full 35 FPS on such machine, while normally it has less than 2 FPS on full screen full detail (Fast DOOM will be a bit faster).

Game logic and bsp traversal only use a small amount of CPU cycles compared to rendering. Probably not worth the effort optimizing it.

However since even 386SX can get 35 FPS on game logic alone, we could make a DOS 3D accelerator that would generate image based on the instructions how to draw a scene from CPU. Perhaps we could even write a new firmware for PicoGUS, though a card that connects directly to VGA using VESA Feature connector would be able to directly draw it's frame buffer on the screen.

Such 3D accelerator for 386 and lower is one of my dream projects I would like to do at some point.

New release! FastDoom 0.9.9f

Changelog:

* Dreamblaster S2P support (MIDI through LPT)
* New rendering options, now it's possible to draw walls and sprites untextured (single color)
* Update display options menu, scroll it's available so it's possible to add as many options as wanted
* Optimize flat sky rendering
* Two new command line options "-freeram" and "-limitram". First one limits the amount of ram available for zone memory (kb), and second limits the ammount of memory free after allocating zone memory (also in kb). Reverted default free memory to 128kb (fixes issues on some setups) @jsmolina
* Added file size verification for supported IWADs (in order to reduce unsupported IWAD version issues)

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

ishadow wrote on 2024-07-27, 11:37:

There's a command line option in original DOOM to disable rendering entirely and still do Timedemo. Few years ago I've tested th […]
Show full quote

rasz_pl wrote on 2024-07-09, 21:53:

For example I wonder how much % is spend on rendering vs game logic (bsp traversal etc).

There's a command line option in original DOOM to disable rendering entirely and still do Timedemo. Few years ago I've tested this on 25 MHz 386SX and DOOM without rendering was able to run at it's full 35 FPS on such machine, while normally it has less than 2 FPS on full screen full detail (Fast DOOM will be a bit faster).

Game logic and bsp traversal only use a small amount of CPU cycles compared to rendering. Probably not worth the effort optimizing it.

However since even 386SX can get 35 FPS on game logic alone, we could make a DOS 3D accelerator that would generate image based on the instructions how to draw a scene from CPU. Perhaps we could even write a new firmware for PicoGUS, though a card that connects directly to VGA using VESA Feature connector would be able to directly draw it's frame buffer on the screen.

Such 3D accelerator for 386 and lower is one of my dream projects I would like to do at some point.

Yes, basically rendering is what uses most CPU time on Doom. A 2D/3D ISA accelerator would make the game much much faster on 386 CPUs. Disabling texturing makes everything much faster (this is on my 386SX-33, latest release):

https://x.com/viti95/status/1812065740133920798