I'm assuming NukeYKT reverse-engineered their own DMX-like given their prior work on the Doom OPL3 Windows MIDI driver.

Well, the DMX source code can be found on the Internet, somewhere.

It's clean-roomed enough over the decades that doing that won't ever be necessary. (and DMX itself isn't legally compatible anyway)

MrFlibble wrote on 2020-06-26, 15:52:

Playing with the shareware 1.9 IWAD does not display the third episode's title for some reason on the episode selection screen.

I'll check into this, there are more bugs out there for sure.

Calvero wrote on 2020-06-28, 19:23:

Is Doom faster when it uses a chained hash table instead of linear search?

I haven't implemented it yet, but I think this should be a minor speedup, as the number of visplanes used ingame aren't that much (original WADs).

MAZter wrote on 2020-06-30, 02:35:

I confirm that on the laptop 486 DX2 50Mhz fps increased by 1.52 (from 17.62 to 19.20) using Dos Benchmark Pack config for faster PC.

Can you post your laptop specs? I'm analyzing which are the major bottlenecks in Doom depending of the hardware, so i can focus in those bottlenecks.

leileilol wrote on 2020-06-30, 08:37:

I'm assuming NukeYKT reverse-engineered their own DMX-like given their prior work on the Doom OPL3 Windows MIDI driver.

This port is using NukeYKT sound library from PCDoom-v2, i don't know if it's the original version, a reverse-engineered one or custom made. My idea it's to replace it complitely to a custom one, so the sound cache problems can be fixed and make the tickrate control internal instead of depending in the sound library.

ViTi95 wrote on 2020-07-02, 10:52:

Can you post your laptop specs? I'm analyzing which are the major bottlenecks in Doom depending of the hardware, so i can focus in those bottlenecks.

CPU: 486 DX2 Mobile 50Mhz
Video: Yamaha 6388 (1Mb)
Memory: 20 Mb

Laptop with 486 DX4 75Mhz cpu, fps increased by 0.9fps (20.09 to 20.99)

specs:
cpu: Mobile 486 DX4 75Mhz
video: unknown, 1Mb
memory: 12Mb

Laptop with Pentium 75Mhz cpu, fps increased by 2.13fps (33.52 to 35.65)

specs:
cpu: Mobile Pentium 100 Mhz
video: Chips&Tech 65540 1Mb
memory: 24Mb

Does FastDoom use chunky or mode X? Just because rendering in the main memory then copying it to the frame buffer by dwords can be significantly faster, especially when a fast CPU meets a slow VGA (like in my 1996/97 system where the AMD 5x86 was seriously held back by a dog slow Tseng ET3000 😁)

alvaro84 wrote on 2020-07-21, 15:40:

Does FastDoom use chunky or mode X? Just because rendering in the main memory then copying it to the frame buffer by dwords can be significantly faster, especially when a fast CPU meets a slow VGA (like in my 1996/97 system where the AMD 5x86 was seriously held back by a dog slow Tseng ET3000 😁)

It uses the original Mode X. Ram access is slow in 386/486 processors so I think it's faster to write directly to the video card than write first to main memory and then transfer to the video card. Anyway i'll try to implement new video modes and check the results.

Another example where chunky mode is faster than modeX is the Cyrix MediaGX, it doesn't have L2 cache and video card memory and ram it's shared. MBF it's faster on that cpu, the original doom runs choppy even for a 300mhz cpu.

Did you see the release of the source code for the SNES port?

I saw some people saying that those optimizations could be useful for older PCs as well because of some of the lookup tables it used, I think?

I set-up a minimalist DOSBox build environment with Borland C++ 3.1's TASM.EXE + OpenWatcom 1.9 for DOS. It also works under Windows 9X or NTVDM.

Can it be integrated in the repo via a pull request (I have a GitHub account) ? Or is it against the license of either products / the policy of the repo ?

HandOfFate wrote on 2020-07-23, 08:09:

Did you see the release of the source code for the SNES port?

I saw some people saying that those optimizations could be useful for older PCs as well because of some of the lookup tables it used, I think?

Yeah, what an awesome release!!. It's completely different from the original source code, and it's also heavily optimized in assembly code (which makes it harder to understand). Maybe it's possible to implement some ideas from that version (such as the rendering of flat visplanes which is already implemented).

xcomcmdr wrote on 2020-07-23, 08:16:

I set-up a minimalist DOSBox build environment with Borland C++ 3.1's TASM.EXE + OpenWatcom 1.9 for DOS. It also works under Windows 9X or NTVDM.

Can it be integrated in the repo via a pull request (I have a GitHub account) ? Or is it against the license of either products / the policy of the repo ?

Well I don't know really much about licensing, FastDoom it's under the GNU GPLv2 because of the original Doom source code and the Apogee Sound System (it's not using the DMX library 😁). The main problem here it's the Borland C++ 3.1, I think it's a licensed product and we can't upload it to GitHub. Maybe it's a good idea to create a separated repo with that build environment.

New release!!

FastDoom 0.4

• Added autorun support (F11 key).
• Added mono sound support. Enabled with "-mono" parameter.
• Added low quality sound support (8000Hz instead of 11025Hz). Enabled with "-lowsound" parameter.
• Fixed Doom 1.9 shareware menu (thanks @MrFlibble !)
• Included sound library into the source code, instead of using a prebuilt library. Sound cache it's still not fixed, but now it's possible to add support for new sound cards, optimizations and fix bugs. May break some sound cards support (untested Gravis Ultrasound and Pro AudioSpectrum 16).
• Optimized build options. Now there are builds for 386 and 486 processors.
• Replaced DOS/4GW with DOS/32A providing a good speedup!
• More small code optimizations

Download link: https://github.com/viti95/FastDoom/releases/tag/0.4
Source code: https://github.com/viti95/FastDoom

I was wondering how FastDoom is compatible with DeHackEd? You need to specify custom offsets for data for each binary provided, is that correct? This is in the context of the possibility of making a DOS binary for REKKR based on FastDoom.

MrFlibble wrote on 2020-07-29, 14:47:

I was wondering how FastDoom is compatible with DeHackEd? You need to specify custom offsets for data for each binary provided, is that correct? This is in the context of the possibility of making a DOS binary for REKKR based on FastDoom.

The executables are different so offsets to functions and data should be different. FastDoom is developed to be as compatible as possible to the original source code, but patches made for the original Doom executables may not work as there are lot's of internal changes to make it faster. I think it's easier to add the changes needed for REKKR onto the code and create a new build made for it.

As I recall, DeHackEd does rely on binary data and offsets, which is naturally different for every different executable, including the different versions of Doom (up to 1.9) and the custom "1.9" builds for Ultimate Doom and Final Doom. So DeHackEd will not modify FastDoom (like it won't any other port). What many ports did was add built-in support for interpreting DeHackEd patches (.DEH) and changing the behavior accordingly.

dr_st wrote on 2020-07-31, 06:43:

As I recall, DeHackEd does rely on binary data and offsets, which is naturally different for every different executable, including the different versions of Doom (up to 1.9) and the custom "1.9" builds for Ultimate Doom and Final Doom. So DeHackEd will not modify FastDoom (like it won't any other port).

The version of DeHackEd that I checked (the latest DOS version as far as I can tell) allows to specify the EXE size in bytes and offsets for data blocks (there are several), so I gather that at least theoretically, it should be possible to apply the patches, unless FastDoom makes changes to the relevant data structures (which I'm not sure if it does). The problem is that I do not know the offsets and have a vague idea of how to find them.

dr_st wrote on 2020-07-31, 06:43:

What many ports did was add built-in support for interpreting DeHackEd patches (.DEH) and changing the behavior accordingly.

I'm aware of this but I did not bring the matter up because it might be well outside the scope of the FastDoom project's current goals.

Hey there's a thread about the project in Doomworld and you might want to join the conversation.
https://www.doomworld.com/forum/topic/116001- … 486-processors/

Does this port implement WASD + Mouse movement controls?

carlostex wrote on 2020-08-02, 10:38:

Does this port implement WASD + Mouse movement controls?

It should be the same as in vanilla Doom I believe.

dondiego wrote on 2020-08-02, 09:05:

Hey there's a thread about the project in Doomworld and you might want to join the conversation.
https://www.doomworld.com/forum/topic/116001- … 486-processors/

Wow this blows my mind, I never expected to gain so much attention! Thank you for notifying me, i'll also write in that forum given that many responses.

carlostex wrote on 2020-08-02, 10:38:

Does this port implement WASD + Mouse movement controls?

Yes, it's exactly the same as vanilla Doom. You can change key bindings with the original setup.exe from vanilla doom.

PS I'll bring back gamma correction support in the next version of FastDoom 😁