I'm no software developer but I am interested in a legacy Win9x compatible zdoom.

I'm down

zdoom 2.4.0 builds with cmake and mingw/gcc46, but has a dependency on Fmod (v42416 for win32) which is not compatible with Win95. Attached patch to remove dependency on directx9 and xinput so that directx8 (dinput8, ddraw, and dxguid) is the dependency. However, compiling assembly files with nasm.exe leads to a binary that is not working. Tried with more recent builds but there are additional dependencies on more recent Windows API. I also created traditional makefiles for this version, although not fully tested.

Instead, the zdoom 2.2.0 binary release is Win95 compatible. The last version compatible with Win95 is r788. It is dependent on Fmod v3. Moreover, these versions have mingw makefiles.

One strategy is to build a working binary from r788 and then identify mods of interest that are dependent on versions later than v2.2.0. The commits are on github, so it would require less debugging work to find the relevant commits and patch the r788 version. A complementary approach is to create a difference file between r788 and a recent version, and then carefully apply changes which do not impact the Win95 compatibility of the audio and other win32 systems. This way a zdoom 95-compatible binary can be developed in parallel with others, and tested easily, along with a simple way to revert issues. It also provides a simpler way to edit the known working makefiles.

Demonsteele
DoomRL Arsenal
Mayhem Mansion
Reelism
Samsara
TheAdventures of Square
Wadsmoosh

i think those are enough mods of interest, just to name a few.

zdoom v2.7.0 may provide satisfactory compatibility with most mods. That is ~5 year gap from v2.2.0 and around 2700 unique commits. Perhaps apply commits and parts of commits that don't affect the win32 directory, at least initially. A build could be tested for error every 20 commits. It would require time and help, but it would result in a working build with some level of capability. It also shouldn't require extensive knowledge of the zdoom engine. If there are issues along the way with the Windows API, then ptitseb's branch may be used as a reference to correct it.

Attached zdoom v271 built by mingw32/gcc46, included binaries and patch to remove directx9 and xinput dependencies in zdoom v271 source code. Instead, mingw32 dx8 headers and libraries are used. The cmake system has a GUI based tool to create the makefiles. Currently dependent on fmodex, but the commit that follows zdoom r788 is a reference to revert from fmodex to the Win95 compatible fmod library.

This looks pretty interesting, reminds me of ECWolf legacy version. ZDoom 1.7.1 is capable of running recent mods (at least runs BD 20) and was stable, on the other hand 2.8.1 had the broken chainsaw. We need to get ultra low detail back as well.
I've been testing 2.2.0 in windows 7 and runs fine, the lowest resolution i can get is 320x240 but it's okay.

I had this version stored for Windows 98: gzdoom.exe version 1.0.21.340, 03-10-2006. The reason being a regression regarding the midi music: Midi Playback Failure (Windows 98). I disassembled most of my systems for recapping, so I cannot really test it. Wonder if the issue is still there...

Attached openal branch of zdoom (approximately v271) built by mingw32/dx8/gcc46 -- included binaries along with the patch which was applied against the openal branch. The included openal binary requires "SHGetSpecialFolderPath". That function is available in shell32.dll, reportedly v4.71+. That should require IE4 with active desktop in Win9x.

The openal binary was downloaded from that linked location. Also, modified code so that cache directory is in program directory in all cases; and originally was the default for Win9x only. User accepts sole responsibility for use of these binaries.

gerwin wrote:

I had this version stored for Windows 98: gzdoom.exe version 1.0.21.340, 03-10-2006. The reason being a regression regarding the midi music

I've tested GZDoom 1.3.17 (based on ZDoom 2.3.1) and it works on win 98 with old graphics cards (requires OpenGL 1.2). The issue with system midi is still there. GZDoom 1.4.08 shows an error message in chinese! and crashes but should work with KernelEX. Old versions of GZDoom can still be downloaded.

blue-green-frog wrote:

Attached openal branch of zdoom (approximately v271) built by mingw32/dx8/gcc46

Great, i guess going back to Fmod was not that easy. Getting rid of the SHGetSpecialFolderPath requirement should not be complicated right? And getting r_detail back should be pretty straightforward.

"SHGetSpecialFolderPath" Looks like OpenAL uses that for the config file.

Anyone object to getting rid of the requirement?

If it's not needed then removing it would remove the requirement for active desktop on 95 and NT4.

Attached binaries of openal branch of zdoom (~v271) built by mingw32/gcc46. Same patch as in previously posted archive, but configured with midi only. User accepts sole responsibility for use of these binaries.

Built openal-soft-1.12.854 and attached binaries along with zdoom. Sound and midi work in Win95, but openal is not very stable in an emulator because of a presumed dependence on multithreading. Once the sound is initialized, then the video mode shouldn't be changed.

On starting zdoom, I follow these steps in order:

1. Under sound options, change "midi device" by pressing right arrow (probably once) to change fmod (not installed) to a working device such as: Creative Music Synth [220]

2. For playback device under "openal options", change default to "directsound software". Also, turn off "enable efx".

User accepts sole responsibility for use of these binaries.

@blue-green-frog: Thanks, have you modified OpenAL to remove that requirement? And how?

So is anyone going to fork this? In case someone's interested the commit when r_detail was removed is the following one (i think some changes would need to be reverted in v_video.h, v_video.cpp, r_draw.h, r_draw.cpp and m_options.cpp).

https://github.com/coelckers/gzdoom/commit/dd … 4539918aca44aa3

I think may be sound defaults should be changed (where are they?) and the FMOD menu option removed.
So how i compile this damn thing? I've got Dev-C++ 5.11 with TDM-GCC 4.9.2, openal-soft and cmake 2.8. Do i need something else? How do i apply diff patches? It's been years since i coded something and i don't know a shit about Git by the way.
Edit: i downloaded dx80_mgw.zip and NASM 2.10 as well.

dondiego wrote:

The issue with system midi is still there.

Thanks for checking!

Great idea to make ZDoom more backwards compatible, I won't miss the modern dependencies.
As for me; I committed myself in some degree to the MBF 2.04 port, and failing to find time for that already: I won't be doing much with ZDoom besides then playing it.

Attached binaries of openal branch of zdoom (~v271) built by mingw32/gcc46. Included previously posted patch for zdoom; and a second zdoom patch with changes to openal default settings and removal of unused menu items from the sound menu. These changes may provide some additional stability to zdoom while openal is loaded. User accepts sole responsibility for use of these binaries.

On starting zdoom: under sound options, change "midi device" by pressing right arrow (probably once) to a working device such as: Creative Music Synth [220].

The openal binary (v1.12.854) was built from unmodified source code.

Edit: the active desktop requirement seems to extend beyond the shell32 dependency. Also, suggest that video card has 4 mb of ram, otherwise there is less stability in zdoom, particularly where changing video resolution. In addition, suggest that system ram is at 192 mb or higher.

Thanks again. I never install the desktop update on win 95. Have you tried any older version of OpenAL like 1.9? (i don't know the requirements of openal versions).
That video memory requirement seems strange, is not stable with less ram even @320x200? And that's a lot of system ram for win 95. I still need help to compile this.

The memory requirements are suggestions since another Win95 system may show a different result.

As for music devices, OPL Passthrough might me interesting to pursuit as Zdoom's default OPL emulator is a huge CPU choker.