But if i'm not wrong you can select system midi in game and opl synth as midi device in windows control panel. BTW have you tried these binaries?
What about using GetEnvironmentVariable instead of SHGetSpecialFolderPath in OpenAL?
If one of the goals is historical preservation of the best zdoom mods, then it may help to archive the different versions of each mod. Also, I couldn't find which zdoom version corresponded to each mod version.
Another major issue is the difference in performance between zdoom 2.2.0 and 2.7.1; and whether it is mainly attributable to the removal of an assembly path. And if it is possible to restore some or all of the assembly path without breaking the more recent zdoom features (much like an addition of colored lighting to Quake 1).
Also, it would be informative to test a zdoom client without multithreading components, particularly for Windows 9x. I don't think the vanilla win32 Quake engines (1/2/3) are highly dependent on this kind of component (I recall that there is an additional thread to handle the Q2 console in Windows, but I'd have to verify). Using multithreading is not ideal for a Win95 target platform.
The issue into the future is that mod authors will develop solely on the gl renderer, such as in gzdoom. This will greatly reduce any chance of preserving those mods on a software renderer.
wrote:But if i'm not wrong you can select system midi in game and opl synth as midi device in windows control panel. BTW have you tried these binaries?
Won't sound the same - music in Doom engine games rely on special timbres.
wrote:Another major issue is the difference in performance between zdoom 2.2.0 and 2.7.1; and whether it is mainly attributable to the removal of an assembly path.
Much of the performance loss is related to new scripting features for modders (and modders would often spam a lot of actors to overcompensate for zdoom's lack of optimized client-side effects systems). There's an even bigger performance loss going from 2.8.1 to 2.9.x as coleckers stripped the ASM out for alleged "multithreading gains"
wrote:And if it is possible to restore some or all of the assembly path without breaking the more recent zdoom features (much like an addition of colored lighting to Quake 1).
As someone who actually shoved in decent colored lighting in Quake1's software renderer before, the assembly for the brush spans is the most important one to keep and they're still used. C functions for building the surfacecache (blending rgb light in 8bpp) and model lighting/drawing had to be done. I intended to ASM it at one point but understanding assembly is one of my big faults. Vavoom (an odd Quake-based doom source port) managed to have full software colored lighting in assembly however.
wrote:The issue into the future is that mod authors will develop solely on the gl renderer, such as in gzdoom. This will greatly reduce any chance of preserving those mods on a software renderer.
QZDoom's supposed to close this gap with an enhanced software renderer, unfortunately eruanna has expressed strong disinterest for Win9x support. No ASM there either. 🙁
wrote:Much of the performance loss is related to new scripting features for modders (and modders would often spam a lot of actors to overcompensate for zdoom's lack of optimized client-side effects systems). There's an even bigger performance loss going from 2.8.1 to 2.9.x as coleckers stripped the ASM out for alleged "multithreading gains"
That is very informative. It may help if people report compatibility issues with v271, but these scripting additions are a problem. Like painters, it would be better if they practiced their art on a reliable medium and not on less portable platforms.
wrote:wrote:And if it is possible to restore some or all of the assembly path without breaking the more recent zdoom features (much like an addition of colored lighting to Quake 1).
As someone who actually shoved in decent colored lighting in Quake1's software renderer before, the assembly for the brush spans is the most important one to keep and they're still used. C functions for building the surfacecache (blending rgb light in 8bpp) and model lighting/drawing had to be done. I intended to ASM it at one point but understanding assembly is one of my big faults. Vavoom (an odd Quake-based doom source port) managed to have full software colored lighting in assembly however.
It would be interesting to analyze the minimum number of cpu cycles per pixel for non-colored lighting versus colored lighting. Do the number of cycles increase exponentially with an increase in colors? Are there any theoretical studies about optimizing the algorithm?
wrote:wrote:The issue into the future is that mod authors will develop solely on the gl renderer, such as in gzdoom. This will greatly reduce any chance of preserving those mods on a software renderer.
QZDoom's supposed to close this gap with an enhanced software renderer, unfortunately eruanna has expressed strong disinterest for Win9x support. No ASM there either. 🙁
There is irony in preserving the visual aesthetics of a 486 era game while arguing for modern only approaches to client modifications.
What about OpenAL performance? Is it faster than FmodEX on P6 machines? And is it fast enough on P5 architecture? Have you tried with -nosound? I guess r_detail would not be very useful but IMO it should be there anyway for nostalgia reasons.
We need to investigate the minimum requirements for this, such as the amount of memory required to run.
Edit: i've tested this for now on win 7 32 bit. Definitely it's slower than 2.2, 117 vs 144 fps. However uses less memory, 16 vs 34 mb of ram.
Zdoom 2.8.1 (the last release) can execute on a PentiumMMX 150MHz on 16MB RAM for starters. MMX is required
Official FmodEx 2.7.1 gives the same performance with -nosound (136 fps), 2.7.1 OpenAL gives 125 fps (vs 117) and FmodEx gives 125 (vs 110) . However this is not very accurate and should be tested on slower machines. So is this playable on a pentium without mods?
Edit: i was testing the official 2.7.1. Considering this is an athlon64 and i've tested @1024 apparently OpenAL is faster than FmodEX. However the Visual C++ version is still faster here.
Retested @640 windowed: OpenAL 149 vs FmodEx 138 vs FmodEx official 198 vs 2.2 210 fps on this machine. So it seems that the big difference comes from compiler optimizations here? Need to test this on a slower machine.
Okay, i've tested this on a p2-233 with a s3 trio3d on win98se and dx8. First as expected no console output and the engine says unknow version. The fmodex version doesn't run, gives an error about missing SHGetFolderPathA, official version did.
Now on the results @640x480 & @320x240:
2.7.1 openal 31 73
2.7.1 official 30 69
2.2.0 ------ 38 73
So it gives pretty much the same performance as the official VC++ version with fmodex. 2.2 is faster but only at high resolutions.
Edit: BTW low detail on 2.2 here has no effect. However i've been playing with doomretro (you can customize low detail mode via config file being hor x ver) and 3x3 would be actually playable and 4x2 as well. Adding a fake ega mode for masochists like that custom palette on top of it could look really retro.
I've tried brutal doom v20 for the sake of it (also on map01) and surprisingly is mostly playable, at 350 mhz since this was an underclocked p2, of course there are slowdowns when there are lots or stuff flying.
Unfortunately this openal branch has serious issues with sounds in mods, most player weapon sounds won't play. This is a showstopper.
Performance @640 is pretty much the same as in the official version.
Edit: all in all openal seems a bit faster and should help pentiums, the renderer is faster with the microsoft compiler but performance will be mostly limited by game logic anyway.
To test fmod3 in zdoom, it should be possible to start with the most recent v271 commit in fmodsound.cpp and step backwards commit by commit (until Mar 2008):
https://github.com/rheit/zdoom/commits/2.7.1/ … d/fmodsound.cpp
During Mar 2008 was the time where fmod3 was changed to fmod4.
Also, testing why the performance in v271 is much less than v220 (Mar 2008) on a slow Pentium. Starting with Aug 2008 (openal branch of zdoom), and compiling every page of more recent commits, then it should be possible to find the set of commits causing it. I am testing the assembly routines first.
But that changes affect many other files, doesn't sound like a good idea (still i don't know how git works).
Is openal faster than fmodex on that pentium? I wanted to test your fmodex exe but i get that SHGetFolderPathA error. The openal branch as i mentioned earlier had serious problems at that stage.
Edit: also i've noticed that official 2.7.1 already worked with directx 8.0. I think your fmodex version was compiled for win 2k.
Attached archive of binaries built from openal branch of zdoom (2-2-15). Also, included patch so source code compiles by mingw32/gcc46/nasm208/dx8 (requires cmake for configuration, too); built with sse=off, asm=on, O2 optimization. User accepts sole responsibility for use of these binaries.
On starting zdoom: under sound options, change "midi device" by pressing right arrow until finding a working device such as: Creative Music Synth [220]. Verify that "sound backend" is openal.
The openal v1.12, libsndfile v1.0.25, 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 where available.
Currently testing. Seems stable so far in modern Windows and in an emulator running Win95 with audio disabled.
wrote:testing why the performance in v271 is much less than v220 (Mar 2008) on a slow Pentium
What are the performance numbers @320 (use vid_fps 1 on the console) and cpu speed? Have you tried with -nosound? Is that an emulator or a real machine?
wrote:Attached archive of binaries built from openal branch of zdoom (2-2-15)
Thanks, sfx now work fine in mods but i get no midi with sound system in win 7 (same as before), i get a midi playback failed error and only the microsoft sofware synth and the opl emulation work. The chainsaw was not still broken at that point.
This is much faster now, i get 163 fps @1024 (vs 117).
Edit: before the sound system option was not there, it works with the official fmodex version but not here. In win 98 the soundblaster synth works, the sound system option does not.
BTW in the p2 @233 the performance is 34 fps @640 and 73 fps @320 (slightly faster only at high resolutions). Now i get an empty config folder.
Attached archive of binaries built from openal branch of zdoom (2-2-15). Included two patches, one to compile source code by mingw32/gcc46/nasm208/dx8 and the other with updates to the openal code in zdoom (mainly from more recent commits to the openal branch). A third patch is for openal-soft v112 and win95 compatiblity. User accepts sole responsibility for use of these unsupported binaries.
On starting zdoom: under sound options, change "midi device" by pressing right arrow until finding a working device such as: Creative Music Synth [220]. Verify that "sound backend" is openal and that a valid "playback device" is selected under "openal options".
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 where available.
Currently testing in modern Windows and in an emulator running Windows 95 OSR2 (with riched20.dll). Removed the dependencies on ie4 and active desktop. If testing in an emulator, set display option "rendering interpolation" to off.
wrote:A third patch is for openal-soft v112 and win95 compatiblity.
Great work! BTW what is riched20.dll?
Got some news, according to one of the developers it would be best to fork from the end of the maintenance branch (https://github.com/rheit/zdoom/tree/maint) to get a solid codebase.
What's more a lot of fixes came after the end of the openal branch. I was wrong and the chainsaw bug was not in 2.8.1, it was introduced later.
On the MMX requirement MMX was used in DoBlending_MMX and Bestcolor_MMX but there were fallback versions and the MMX ones were removed recently since they weren't actually useful.
https://github.com/rheit/zdoom/search?q=mmx&t … &utf8=%E2%9C%93
wrote:BTW what is riched20.dll?
The Rich Edit control, used by many things in Windows that require text editing. The requirement for riched20.dll was not uncommon; it is included with all versions of Windows after Windows 95.
I'll need to download it then. I think compiling with the mtune=i586 option should improve performance on old machines.
I believe those commits restored the intrinsic non mmx versions but there were asm non mmx versions of those functions as well and for now i don't know when they were removed.
Edit: according to another developer MMX was never required, unlike leileilol mentioned earlier. So nothing to do here.
Attached an archive with openal binary and patch to potentially replace the version in the above archive "zdoom28-oal-mingw-95-4.zip". It was built the same way as above.
This replacement has two features for use in emulation. It has higher audio latency where running at slow Pentium level or equivalent performance. The other is that it is <relatively> more stable in emulation.
User accepts sole responsibility for use of this binary.
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. 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.
The earlier instability in an emulator was likely from inability of the Win95 audio buffer to keep pace with both the midi and sound playback. Alternatively tested with the internal opl midi emulation, but that runs slow and doesn't prevent the issue. However, building binaries with no optimization does avoid the divide by zero and access errors, but zdoom will spontaneously close under audio load or show a midi playback error. Another method was to edit the openal code so that the audio latency is high, and even though it runs relatively more stably, it does lead to high latency under load (probably from the buffer overfilling). This same effect was noted on a forum post I recall where Win98se (a slow cpu along with an atypical sound setup) led to midi playback errors involving memory allocation. This is similar or the same as to what occurred in emulation.
I haven't observed any issues on real hardware. For use in emulation, I would recommend zdoom v220 in PCem for testing against the vanilla game and zdoom mods from 2008 and earlier. A mod like Action Doom 2 will run on that version, but it generally has high system requirements.
Thanks again. IMO getting this running on an emulator it's not important, the emulator has the problem.
I've noticed the sound system option for midi has dissapeared again.
I've tested this on a real pentium and true it runs like shit. I thought it had win95 installed but it's win98 fe. The machine specs are pentium 90, 32 mb of ram, 1 mb trident 9440 graphics card and sound blaster vibra16c. Actually is an underclocked pentium 166, i wired the turbo switch to a multiplier jumper.
On the p2 it seems to run faster now but i've tested @350. On the pentium in 2.2.0 music slowed down until i changed sound sample rate to 11025.
p2-350
2.2.0 56(@640) 73(@320)
2.8.2 50(@640) 73(@320)
p-90
2.2.0 10(@640) 33(@320) 45(NS) 40(LD) 56(LDNS)
2.8.2 6(@640) 16(@320) 22(NS)
p-180
2.2.0 19(@640) 54(@320)
2.8.2 8(@640) 23(@320) 33(NS)
I don't think compiling everything with the -mtune=i586 option will make much of a
difference but it's worth a try. The -generic option (which is the default) optimizes for
the most common modern processors. Same with low detail but i'd like to get it back anyway.
The libgcc and libstd dlls shouldn't be there, have you tried compiling with TDM-GCC?
Edit: added some missing results and changed other ones, retested @11025 on the pentium. I forgot to mention this time i tested on E1M1.
