Attached archive of binaries built from maintenance branch of zdoom (4/18/16). Included patches to compile zdoom and openal by mingw32/gcc46/nasm208/dx8. Changes were made to adapt software to Win95. Latest changes include modifications to zdoom configuration handling and gzdoom patches, such as removal of movie code and minor self-documenting code bits. User accepts sole responsibility for use of these unsupported binaries.

The libsndfile v1.0.25 and and mpg123 v1.19 binaries were built from unmodified source code. The libsndfile distribution has instructions for including flac, ogg, and vorbis (configure without largefile support).

Testing in modern Windows and an emulator running Windows 95 OSR2 (with riched20.dll). If testing in an emulator, set display option "rendering interpolation" to off and replace the default openal32.dll with the high latency version. However, if testing on real hardware with a modern CPU, then the high quality version has lower latency. The zdoom binary is a debug build for better compatibility with emulation, so instead use zdoom binary from "zdoom28-oal-mingw-95-5.zip" for optimized performance. The multithreaded audio library does not seem fully compatibility with emulation (tested with fmod4 and openal), so the debug build and high latency openal seems to workaround some of this issue. However, ideally zdoom would run entirely on a single thread for this kind of use (zdoom-v220/fmod3 is preferred but not compatible with latest mods).

I've been reviewing your patches and i'm wondering why you've changed the handling of paths for config files. I see you've switched from GetUserFile to PROGDIR, was there any problem before? On the movie code i guess it didn't work, right?

In emulation of Win95, the main configuration file was not always loaded by mods, so I reverted changes wherever possible while referring to v220 as a reference. It seems to work better now.

The movie code was removed as suggested by a recent gzdoom commit:
https://github.com/coelckers/gzdoom/commit/15 … 1e88fda093e7465

Also, in emulation the sb16 opl2/3 music device works much better than sb midi out.

It doesn't compile, seems like the makefile is bad. I generate a makefile for codeblocks with cmake but i get a directx error (missing ddraw.h). The reference to DX i get in cmake is DX_dguid_LIBRARY, i'm using dx80_mgw.
I don't know how to add the DX libraries to the makefile.
Edit: it's compiling now, the cmakelists.txt file was bad, i've fixed it changing the D3D_INCLUDE_DIR variable to DDRAW_INCLUDE_DIR (was removed). Trying with -O3, i'm getting some warnings and this is slow.

Edit2: it's not linking, i get some errors:
CMakeFiles\zdoom.dir/objects.a(i_keyboard.obj):i_keyboard.cpp:(.text+0xc6): undefined reference to `c_dfDIKeyboard'
CMakeFiles\zdoom.dir/objects.a(i_mouse.obj):i_mouse.cpp:(.text+0x32f): undefined reference to `c_dfDIMouse2'
CMakeFiles\zdoom.dir/objects.a(i_mouse.obj):i_mouse.cpp:(.text+0x339): undefined reference to `c_dfDIMouse'
CMakeFiles\zdoom.dir/objects.a(i_mouse.obj):i_mouse.cpp:(.text+0x411): undefined reference to `c_dfDIMouse'

I don't recall a missing ddraw.h error in the maintenance branch of zdoom. However, I never installed codeblocks either.

There is a basic tutorial on building zdoom here:
https://zdoom.org/wiki/Compile_ZDoom_on_Windows

I knew that tutorial, finally linked and despite the serious warnings it works but without sound. CMake was trying to link with the system dinput8.dll. I should have built the openal library first but i can't. I need your modified openal library (.a files) since i don't have the DX SDK, it's a big dowload and my internet connection is slow.
Edit: i can't find the dx8 sdk anyway, should work with dx80_mgw but i've added it to the path and cmake still can't find it.

I've downloaded and installed the directx 8 sdk (dx8a_sdk.exe) but i keep getting the building without directsound support message. The sdk is installed in the c:\mssdk folder. Definitely i'll need your help to compile openal with directsound and mingw, i'd like to know how you've done it. I can't find any information on this subject. The included cmakelists.txt is supposed to use the environment variables.
Edit: building mpg123 will also be a problem.

Never mind, i linked directly against the dlls and it works now. Only thing that intrigues me is i linked to libdinput8.a instead of dinput8.dll becouse i got those undefined references. May be there is a wrong version of dinput8.dll in my system, i don't know what i was supposed to do. So am i linking dinput8 statically now and not dynamically?
Fluidsynth doesn't work, i think this is normal for openal.

It's released @GitHub, i've started a new thread.
ZDoom LE (Legacy Edition)
Edit: in the end compiling with -mtune=586 made a big difference, about 40% performance increase, on the pentium 90 the framerate went from 16 to 22 fps.

Usually -mtune doesn't do much for me. You might also want to try -flto

-march=native or pentium; also might make sense to try the -O option

Attached Zdoom v117c binaries for DOS (music is not available). Built by djgpp v203, gcc/gpp v295-3, and nasm v098 (instructions in the archive); and also attached the PTC v073 library. The build is dependent on these third-party libraries: PTC graphics, MIDAS sound, and Allegro v30 (although I didn't try building without it). Patches included in instructions.

These binaries are untested and unsupported. User takes responsibility for their use.

It may be possible to merge the v117c DOS subsystems with a later version of Zdoom.

Built a zdoom v117c binary with the sound library used in the MBF Doom port (DOS). However, it is not working yet. This shows one possible way for music support.

Also, the Eternity DOS port seems to use the same sound engine as the MBF port. The Eternity engine is more recent than zdoom v117c, so it may be an interesting alternative for testing against popular map packs.

The attached difference file is between zdoom v117c and v122. It shows the refactoring of the code and additional features. However, file names have been changed between versions, so the difference file will not apply with the Patch tool. Instead it provides a reference for porting features.

Attached a patch for building Eternity v3.31.10 for DOS. The source is available here:
https://www.doomworld.com/idgames/source/ee33110s

Depends on Allegro 3.x. Tested with Allegro 3.0, but the DOS build is not yet functional even though there is video and audio output.

The Eternity DOS binaries for v3.31-beta7 work, however: http://eternity.mancubus.net/ee-old/ee331b7-dos.zip. That archive also has non-executable files that the eternity port depends upon (probably they use a slightly different version, but sufficient for initial testing).

The above Eternity DOS build (v3.31.10) seems to work fine. The issue was the non-executable files. This version is newer than v3.31-beta7, so the files should be copied from the v3.31.10 archive here:
http://www.gamers.org/pub/idgames/source/ee33110w.zip

The attached archive includes the Eternity binary and the required non-executable files. These binaries are untested and unsupported. User takes responsibility for their use.

Attached difference file between Eternity v33110 and v33302. Will serve as a reference in porting the changes to DOS.

Attached Eternity DOS build (v3.33.02). Includes a patch. The binary is built by djgpp and the non-executable files are from the win32 release. These binaries are untested and unsupported. User takes responsibility for their use.

Goal is to test further before trying this dos sound subsystem in zdoom.

Eternity v33302 (DOS) will load Back to Saturn X megawad after making this change to the wad's EDFROOT file. The file may be edited in SLumpEd.

1--- EDFROOT-Orig	2017-04-23 01:44:46 -0400
2+++ EDFROOT-Eternity	2017-04-23 01:43:51 -0400
3@@ -1,5 +1 @@
4 stdinclude("root.edf")
5-
6-gameproperties {
7-	credit.background FWATER15
8-}

hail-to-the-ryzen wrote:

Attached Eternity DOS build (v3.33.02).

Interesting. I'll try it, thanks.

It works well but i can't get music in dosbox with any of the options. No music with official beta either.