VOGONS


Reply 1040 of 1053, by ViTi95

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

https://www.youtube.com/@viti95

Reply 1041 of 1053, by rasz_pl

User metadata
Rank l33t
Rank
l33t
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

Open Source AT&T Globalyst/NCR/FIC 486-GAC-2 proprietary Cache Module reproduction

Reply 1042 of 1053, by AirIntake

User metadata
Rank Member
Rank
Member

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.

Casio BE-300 Advancement Society alumni

Reply 1043 of 1053, by Grunt

User metadata
Rank Newbie
Rank
Newbie
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. 😉

Reply 1044 of 1053, by ViTi95

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

dos4gw_000.png
Filename
dos4gw_000.png
File size
9.4 KiB
Views
515 views
File comment
FastDoom flat wall rendering
File license
CC-BY-4.0

Untextured walls without diminished lightning

dos4gw_001.png
Filename
dos4gw_001.png
File size
9.33 KiB
Views
515 views
File comment
FastDoom flatter wall rendering
File license
CC-BY-4.0

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

dos4gw_002.png
Filename
dos4gw_002.png
File size
4.24 KiB
Views
515 views
File comment
FastDoom flat sprites rendering
File license
CC-BY-4.0
dos4gw_003.png
Filename
dos4gw_003.png
File size
4.18 KiB
Views
515 views
File comment
FastDoom flatter sprites rendering
File license
CC-BY-4.0

This will be available on the next release 😁

https://www.youtube.com/@viti95

Reply 1045 of 1053, by analog_programmer

User metadata
Rank Oldbie
Rank
Oldbie

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.

from СМ630 to Ryzen gen. 3
engineer's five pennies: this world goes south since everything's run by financiers and economists
this isn't voice chat, yet some people, overusing online communications, "talk" and "hear voices"

Reply 1046 of 1053, by DracoNihil

User metadata
Rank Oldbie
Rank
Oldbie
ViTi95 wrote on 2024-07-09, 09:54:

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

Silhouette Doom.

“I am the dragon without a name…”
― Κυνικός Δράκων

Reply 1047 of 1053, by BitWrangler

User metadata
Rank l33t++
Rank
l33t++

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)

Unicorn herding operations are proceeding, but all the totes of hens teeth and barrels of rocking horse poop give them plenty of hiding spots.

Reply 1049 of 1053, by rasz_pl

User metadata
Rank l33t
Rank
l33t

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.

Open Source AT&T Globalyst/NCR/FIC 486-GAC-2 proprietary Cache Module reproduction

Reply 1051 of 1053, by analog_programmer

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

from СМ630 to Ryzen gen. 3
engineer's five pennies: this world goes south since everything's run by financiers and economists
this isn't voice chat, yet some people, overusing online communications, "talk" and "hear voices"

Reply 1052 of 1053, by rasz_pl

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

Open Source AT&T Globalyst/NCR/FIC 486-GAC-2 proprietary Cache Module reproduction