Your performance results are helpful in finding the bottlenecks. I've tested with different optimizations, but zdoom isn't robust to these changes. One possible reason is that the math precision has not been thoroughly tested. Another concern is the conversion of integer math to doubles throughout a lot of the code. During my limited testing, this led to errors and I isolated one of them to a commit using doubles for textures and hud scaling.

The c/c++ runtimes are also used by the multimedia shared libraries.

I haven't verified whether the many zdoom mods are archived at a permanent site along with the the community wiki which provides reviews of them. Ideally, the wiki would also document the specific features in zdoom, point to the code additions, and categorize the mods by which features they use. The commits are not organized in a way to do this.

Winmm versus directsound: noted less startup delay in running zdoom v220 (fmod3) with snd_output=winmm (waveout driver) instead of directsound output. Tested in emulation with snd_buffersize=40 and snd_samplerate=48000; likewise in hardware with snd_buffersize=20. Reportedly openal-soft does not support the winmm, even though the code is present. Tested, too. This is an advantage of the fmod audio scheme.

There was no performance difference with no rendering interpolation, seems that it's disabled automatically when frame rate is low. On the p2-233 was always @36. Changing column renderer mode didn't make any difference either.
Now a new empty folder called save has appeared.
Music slowdown with 2.2.0 was there on the pentium even @11025 but was less noticeable.
I've edited the previous post since sample rate was not actually 11025, i think i deleted the ini and changed to default, it was @44100 so i've retested on the pentium. Good news is now runs slightly faster. EFX should be disabled by default.
I've found a little problem on the pentium: video mode is not saved, only the previous mode you set earlier. So to save 320 you need to select another one after it. Crazy.
Any ideas on how to fix the console output?

Edit: Have you decided a name for the project? How about ZDoomLE (legacy edition) or VZDoom (vintage ZDoom)?
Are you going to fork this officially? You should register at the ZDoom forum and according to one of the moderators you could have your exes released at the home page.
https://forum.zdoom.org/viewtopic.php?f=4&t=54983&start=30

The rich edit control 2.0 has that behavior in Win95 and the zdoom code is now dependent on it. It is possible to maximize it on zdoom startup by a right click on its task on the taskbar, and then choose maximize.

The saved games from the vanilla game should save to that directory. I haven't tested those particular code changes that well yet.

I uploaded the code for your use and the original poster leilei. You both may take ownership of the code changes and do as you wish. I would like your community to have a simple way to compile zdoom so that development is democratic. That is the spirit of open source.

The current code has a convenient backtrace that is not mingw friendly in Win95, although perhaps gdb will work on real hardware. It is possible to extend the code toward this goal and it would make debugging much easier.

blue-green-frog wrote:

The rich edit control 2.0 has that behavior in Win95

Are you talking about the console? I don't see any text output. What is this RTF thing for?

blue-green-frog wrote:

I uploaded the code for your use and the original poster leilei

Let's wait and see if leilei accepts the challenge, LZDoom then?

The text outputs to the zdoom console, but doesn't duplicate the text to the Win95 rich edit control. This behavior is different than in recent Windows versions.

I think i've found it:
https://github.com/rheit/zdoom/commit/c ... 4b64edb885
From the discussion here:
viewtopic.php?f=7&t=49042&start=15
Seems the local buffer is not being printed in old windows versions.

Attached updated zdoom binary for the above "zdoom28-oal-mingw-95-5.zip" package. Updated for non-unicode console output along with the corresponding source code patch. User accepts sole responsibility for use.

Well done! It works fine. Obviously i was wrong and that was not the problem.
I still think you should fork this, leilei doesn't look interested and my c++ knowledge is limited and at least for now i just want to get the low detail modes back (easy with the commit i mentioned earlier) and add the quad horiz and double vert mode.
Another thing to do is increase version number may be to 2.8.1a and give the project a name.
I want to test this on a pentium mmx but one of them had the cdrom screwed and after changing it seems that the hdd is dying. Another one has win95 but the cdrom is bad as well.

It would be interesting to revert the use of doubles throughout the code, too.

At low screen resolution, is a zdoom gl renderer expected to be much faster than the software renderer?

That would be a lot of work and i don't think it's worth. I think opengl gives pretty much the same performance or even worse. More on this later.
Finally i've tested on windows 95 and a pentium mmx, reinstalled windows on the dodgy hard drive becouse on the 'new' computer win95 refused to boot anymore.
This is a 200 mmx with 32 mb, s3 virge/dx 2mb and sb awe64 on win95c.
First, riched20.dll was already there but there's no console on both 2.2 and 2.8 but that's fine.
The game runs incredibly slow with rendering interpolation on, almost you can't even navigate the menus. This should be disabled by default. The saving video mode problem is there and i've noticed 2.2 has it as well, on the p2 it was not.

Now on the results:
2.2.0 34(@640) 60(@320) 60(NS) 61(LD)
2.8.1a 14(@640) 36(@320) 36(NS)

Note that RI is disabled. This is the old version without the console fix.

Not much C++ is required. Mainly setting up the compiler. MinGW32 is available here: https://sourceforge.net/projects/mingw/files/. It has the setup file to select and install the environment for compiling software. It would be simplest to start with zdoom v2.2.0 and fmod3 since it requires few library dependencies. This would allow robust testing on the code and performance of zdoom.

Attached openal binary specific for modern Windows and may be used instead of the Win9x version in the above "zdoom28-oal-mingw-95-5.zip" package. Builds in mingw32 with the corresponding source code patch (openal-soft github version 2-9-17). User accepts sole responsibility for use.

The 9x version runs fine on modern windows as well, am i missing something? Official 2.8.1 also did.
I've got dev-cpp 5.11 with tdm-gcc. A guy on the zdoom forums, he's the ecwolf author, has made modifications on his own to allow gzdoom compiling on mingw and running on 98 and probably will include your console fix in his next build.

On the floating point rewrite there was a failed attempt some time ago. If i'm not wrong this allows the renderer to be more precise showing less errors but it wasn't still complete at that point. But the gamelogic still uses fixed point, the main problem is doom uses inefficient algos and data structures, they are not adequate for big levels with lots of stuff in them but were fast then. And it's a 20 year old design with a lot of global variables.
IMO a pentium 120 could be considered the minimum requirement for vanilla levels, once you play bigger levels i don't think floating point matters that much. A P6 gives the same performance as 2.2 at low resolution and at hires the difference is minor. On a pentium mmx at lowres this runs fine.
So i don't think is worth and you could end up with a broken engine.
After retesting openal was not slower than fmod. The problem with openal is no hardware midi on modern windows, software wavetable could be slow on P6.

The video mode change not being saved on pentiums is strange, may be could be interesting reverting to the old behavior of 'press D to make <res> the default current default is <res>' of ancient versions like in quake.

Continued testing of the v2.8.1-maintenance zdoom code. I've started testing the reversion of double variable types in favor of integer math in the software renderer. Also, isolated (most of) the exception errors in Win95 emulation to the zdoom audio (regardless of backend) even though the built-in zdoom debugger does not seem reliable inside an emulator. Currently testing changes to s_advsound.cpp with the Dark7 mod.

However, a workaround for the in-emulation errors in the BrutalDoom mod (and others) is to build zdoom as a debug build (-g), exclude the debug specific code (-DNDEBUG), and then strip the symbols from the binary (strip -s). This seems to avoid errors in emulation where audio is on.

Ideally, a long-term goal would be to further compartmentalize the zdoom code by game function which would avoid simple changes from having many upstream and downstream effects. Other projects could then incorporate features more easily and expand their compatibility with mods.

IMHO this doesn't need to run well on an emulator, you know emulation is not perfect and has its limitations. I guess you're using pcem, it's the emulator the one should support ZDoom and fix the problems.
About the floating point rewrite i'm not confident it's going anywere.
But fixing the video mode change and save on pentiums would be nice, may be the change default setting helps.
I still need to compile this. How do i apply diff patches? Using git? Patch for windows?

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. Building of the other libraries is described in a previous post in this thread. Changes were made to adapt zdoom to Win95 inside an emulator. User accepts sole responsibility for use of these unsupported binaries.

For use in an emulator, zdoom's rendering interpolation is now disabled by default. Also, the zdoom and openal binaries were statically linked with the c/c++ runtime libraries. Compiler flags in zdoom were set for a debug build but the debug code in zdoom was not enabled, and the exception handling was also disabled. Finally, symbols were stripped from the binaries.

The debug build should result in slower performance, but it seems to avoid the majority of errors in zdoom while audio is active, at least during limited testing. This was mainly tested in dosbox-x, but also in pcem, since both have support for Win95. Also, tested the non-debug builds (release type) with "gcc stack-protection" and "fortified source = 1" to help determine the cause of the issue -- why the debug build avoids (most of) the errors that the release build does not. Those compiler flags didn't lead to any insight into the issue.

So, the next test was to determine whether multithreading was the cause of the issue, possibly related to timing since the emulation will run the zdoom audio much slower than real hardware. Furthermore, there was a report of this kind of error with real hardware with an atypically slow audio setup. However, gcc46 does not support fsanitize=thread and fsanitize=undefined for a casual evaluation of a threading issue. But the use of high latency openal audio does help in avoiding the zdoom errors. So, even though I could not yet test whether multithreading is the cause of the issues, I attached the zdoom pseudo-debug build and an openal binary with high latency. Other minor changes are described in the patches.

I wonder where video settings are stored in order to disable rendering interpolation.
For now i've been investigating the video mode change issue in pentiums checking vid_defwidth and vid_defheight in the console. This only happens when changing mode from high resolutions becouse these computers are too slow, the mode is set but the default is not changed, it's changed when you set another mode like a pending event.
I think 320x200 should be the default resolution again, it's safe becouse anyway the lowest available is chosen.

I've been looking at the code and it's not pretty, moreover it's poorly commented. I don't know why but setting the default mode depends on a timer. BTW the old code in 1.23 beta is very different.
In videomenu.cpp we find "testingmode = I_GetTime(false) + 5 * TICRATE;"
and in d_main.ccp "if (testingmode == 1) M_SetDefaultMode ();"
Testingmode surprisingly is a timer to store tics and is set to 1 in M_SetVideoMode() in videomenu.cpp but is also used as bool. I find this confusing (?).

The above issue with the highly rated Dark7 map pack was that I had version 1.3. It was posted at a main archive for doom maps: https://www.doomworld.com/idgames/levels/doom … Ports/d-f/dark7. The date of the pack shows 2002 and the readme suggests a compatible game engine: ZDoom 2.0.63a or higher. However, I was unable to run it on the early Windows versions of zdoom and it was problematic in emulation. And the archived map pack showed file dates of 2007 and later; and is described as a "special edition" having "fixes". I am unable to confirm that the original author uploaded this special edition.

Instead, Dark7 v1.2 worked on the older zdoom engines: http://www.doomwadstation.net/2006/dark7/. The mission pack 1 is available there, too.

The community should archive as many versions of map packs as possible, particularly when there is a gap of several years between the readme file and the uploaded version. This would help preserve compatibility with ports on older systems, including in dosbox.

For older systems, suggest trying zdoom 1.17c for dos: http://zdoom.sourceforge.net/download.html. Or zdoom 2.0.96 (fmod3) for Windows/9x, also at that web site, and shows a file date of 2004. The later version of zdoom, v2.20/2008/fmod3, has added compatibility with mods, but its performance may be compared against v2.0.96. These suggestions were from surveying many doom ports by their compatibility with vanilla doom and with popular single player map packs from that era.

I've edited the previous message, what a mess. In the old code the default was set after changing video mode.
Edit: i think i've found the obvious solution, creating a new boolean global variable and setting it to true in M_SetVideoMode() and false in M_RestoreMode () and M_SetDefaultMode () checking it in D_ProcessEvents (void).

It may be worth verifying that "FGameConfigFile::FGameConfigFile" in gameconfigfile.cpp searches for zdoom.ini in same place as "GetUserFile" in m_specialpaths.cpp.

Perhaps these lines could be modified in the former for testing:
SetValueForKey ("Path", "$HOME", true);
SetValueForKey ("Path", "$PROGDIR", true);