Thanks. According to what i've read MinGW-w64 can only target win xp and later. I'm using sjlj, should i switch to dwarf?
I've attached another test version compiled with MinGW-w64 including the dll you mentioned. Still no sound (if it runs at all), i think we need to find a compatible OpenAL version for 98 and recent GZDoom. Linking dynamically libgcc and libstdc++ still pending. The link will be alive only for a few days.

http://www.fileconvoy.com/dfl.php?id=g7bfef29 … e7708d9186a23c2

The MinGW-w64 executable doesn't run on 98, seems libwinpthread requires XP.
I've updated the first link with the noGlib fluidsynth version, the other one gave a runtime error. However that dll doesn't work on 98 either.

From reading the mingw-w64 bug list, and some recollection, there are issues with handling cleanup of C++ objects and with multithreading. The latter is especially problematic with complex code bases. This doesn't mean that these bugs are the issue with gzdoom/mingw64, but it seems difficult to eliminate as the cause, especially since there were extensive efforts to fix these issues.

One test is to obtain debug C++/threading runtimes and link gzdoom to those. Apparently, the C++11 threading in mingw-w64 is implemented by mapping to the win32 threading api and supplementing that with their own mingw-w64 functions. Since gzdoom works in linux/gcc, it does suggest problems in mingw-w64. I would start documenting more specific causes of these bugs and post the findings on their boards.

I would work on the XP version of 32-bit gzdoom/mgw64 first. The next priority seems to workaround the crash bugs (wait until mingw-w64 fixes the C++11 threading if necessary) and make a working openal library. The openal problem should be trivial. Post any issues and I'm sure you will have good replies since it is widely used and simple to make reversions to its code base.

The sjlj and dwarf versions, from what I recall, is for exception handling. Possibly dwarf is better for the mingw32 version, but it is reasonable to test the dwarf version once to see if the crash on exit bug exists (this can be done last, I would think).

Another thing. I agree that you need benchmarking, even if non-exact. If Windows 98 does not typically run on a CPU that is a realistic minimum for gzdoom-v33, then target XP and higher. It may be problematic to port the gcc and mingw multithreading code back to Windows 98 anyways; a guess is that both packages would require recompiling, but this is something to verify and consider. With the other issue being the minimum level of CPU supported in these packages and whether that minimum is feasible in a typical Windows 98 CPU.

An example is the Retroarch project. They have binaries for Windows 95, but that doesn't help if the libretro builds of emulators target SSE or higher instructions. I haven't verified that and assumed that the Pentium 1 is a target, but that is not certain.

Built GZDoom32 with TDM-GCC. Testing with doom.wad. Didn't test sound yet, but no crash on exit issue. It seems to work fine and the building process was simple. I also left the multithreading option as the default.

Testing with doom.wad, the sound worked with the first openal library I tried (version 1.15.1). I may have modified it previously, however.

Sorry but wrong branch i guess, as stated earlier the source is at https://github.com/drfrag666/gzdoom/commits/g3.3mgw
ZDoom32 is an old project and runs fine on win98, i compiled the releases with fmod. That one is based on ZDoom from DEC 03 2016. There's a minor problem with broken portals and mirrors in the GL renderer with MinGW but i suspect undefined behaviour and i don't think it's a problem with gcc itself but with VS.

For GZDoom 3.3 sound works on XP, it's not working on 98. I suspect the crash on exit is a bug in the MinGW C runtime. The crash on exit also happens with the seh 64 bit version.
I chose sjlj since it's the classic and somewhat recommended version. More info: https://wiki.qt.io/MinGW-64-bit
C++11 multithreading is implemented only in the POSIX version using the libwinpthreads library.

I need someone testing the win98 build to know where the framerate timing issues come from (CPU or OS). Also i don't know if OpenAL 1.15 works, i've tried 1.17 and that one works only on XP and later.

Thanks for the updated information. I'll follow those instructions.

I compiled the right branch this time (g3.3mgw). Reproduced the two main issues with the tdm-gcc-32 build:
1. r_multithreaded=0 necessary with true color software renderer
2. crashes on exit regardless of renderer

One possible test for the cause of #1 is to revert commits from the commit history of r_threads.h until that issue does not occur.

Likewise for #2, the commits from the history of vmframe.cpp could be reverted until #2 does not occur.

This assumes that the cause of the issue is related to a commit between the date of the gzdoom32 and the g3.3mgw branches. If those reversions have no effect or are dependent on too many other commits, then it should also be possible to work forward from gzdoom32. Apply commits in blocks of 25 or another large count, then test for #1 or #2 issues after each block. Eventually this should identify the problem commits.

Hey dondiego, can you please compile it with a target of XP x64 for me? The official x64 build doesn not run on XP x64.

Thanks

Thanks. I guess you've compiled the SSE2 version. Actually those issues were not much of a problem and that's not how it works.
For the r_multithreaded crash the winpthreads library was experimental in tdm-gcc, it's not a problem with the code itself. In ZDoom32 r_multithreaded was experimental then and was disabled since it crashed from time to time, now it works well.
On the crash on exit i've reported it as a MinGW C runtime bug but they'll probably close it without looking into it as apparently they usually do.
So i'll have to add a workaround. Also the zscript version uses a more modern virtual machine and the code seems to be fine. So what you're proposing just can't be done.

https://sourceforge.net/p/mingw-w64/bugs/734/

But this morning i've installed win xp on a 1 ghz pentium 3 machine and it's been painful due to a dodgy cdrom and dodgy ram (passed the mem diags with flying colors but there was data corruption in windows). I didn't install the sound drivers but the game runs fine at 60 fps @640 so it was a win 98 thing, it no longer runs well on 98. I was not going to support win 98 anyway since no one was interested.
Now i need to link statically some libraries and do some maintenance.

On the x64 version what for? I guess the 32 bit version runs fine. How much ram? What's your cpu?

dondiego wrote:

On the x64 version what for? I guess the 32 bit version runs fine. How much ram? What's your cpu?

I am getting low FPS with multisampling and AA turned up to maximum. CPU is an L5240 and RAM is 8GB. I'm thinking the x64 version will take advantage of the extra RAM. GPU is a GTX650.

Thanks

May be XP x64 was not very good at running 32 bit executables. More ram won't give you more fps, if you want better performance you'd use a more modern OS and drivers. That said:
http://www.fileconvoy.com/dfl.php?id=g5fc6080 … ac280625a2dcc80

You'll need the missing sound dlls from the official 64 bit release, i don't know if they will work on XP x64. If not you'll need to find them somewhere else.

dondiego wrote:

May be XP x64 was not very good at running 32 bit executables. More ram won't give you more fps, if you want better performance you'd use a more modern OS and drivers. That said:
http://www.fileconvoy.com/dfl.php?id=g5fc6080 … ac280625a2dcc80

You'll need the missing sound dlls from the official 64 bit release, i don't know if they will work on XP x64. If not you'll need to find them somewhere else.

Thanks 😀

It works!

I will have to run some benchmarks.

I need URGENT help with this, it's getting really frustrating.
The following code in version.h doesn't work with tdm-gcc.

1#if defined(_WIN32) && defined(_MSC_VER)
2#include "gitinfo.h"
3#endif // _WIN32

Changing defined(_MSC_VER) for !defined(__MINGW32__) is the same. Only commenting the include works.
WTF is going on here?
Edit: i guess i need to rebuild the project?

Your x64 build for XP x64 is consistently 4 fps faster than the vanilla 32-bit build...

.lmp files do not play back properly with Timedemo (it's out of sync, I am shooting at a wall when it should be a monster), but that doesn't affect the outcome of the benchmark, because it plays back identically in both builds...

Try this in tdm-gcc-32: gcc -dM -E test.c

It will list the defined names used by the compiler.

Thanks, both conditions work fine with a simple test. Well the code looked right. I guess i'd need to rebuild the project. I want to get rid of that dependency introduced not long ago, that forces to recompile some stuff on every commit and it's not nice.

On the timedemo bug have you recorded and played the demo with the official build? Then it's an official bug and i'll report it, does playdemo work? Glad it doesn't crash and it's even faster it seems.

Edit: still the same, i guess i need to regenerate the project with CMake then.

It's hopeless, may be a broken preprocessor?
I'll have to revert that damn thing completely, this commit:
https://github.com/drfrag666/gzdoom/commit/ca … 926b3c7fa81bad2

Ok I ran a couple more benchmarks... I recorded it in the official 32-but build. I'm not sure what happened last time, maybe I didn't wait long enough to start moving after the console receded which caused that sync issue but I have to re-test to exclude your build as being the culprit.

Anyways, this time it played back properly, and I had v-sync disabled.

32-bit build
timed 4848 gametics in 971 realtics (174.7 fps)

your build
timed 3264 gametics in 988 realtics (115.6 fps)

I also noticed that the green transport light that shows at the begining of e1m1 didn't show up when I ran timedemo on the demo in your build.