Well, may be x64 edition's 64 bit performance wasn't great either, but probably it's a MinGW thing.
There was another problem, the -iwad parameter didn't work properly (bad iwad search path) with MinGW so iwads could not be launched with ZDL if not in the GZDoom folder but it's fixed now.
Actually that was discussed in the ZDoom thread linked earlier. I removed thread_local from VMFrameStack GlobalVMStack as Graf suggested and still crashed. That __declspec(thread) thing is for VS and it won't compile with __thread either since that object needs to be allocated dynamically.
So i didn't mention it was a thread local variable in the bug report. Something similar happened with the FMaterial destructor in the old GL renderer (gzdoom32 branch).
But it is fixed now or not?
I forgot to mention the GL renderer won't run on win95, there are a lot of win98 function calls, only ancient versions did.
Today i found a tower near a trash container, k6-2 500 on a gigabyte ga-5ax board with a sis 6326, sb pci and a dead hdd. Perhaps i could test there. 😀
Edit: perhaps the crash is cpu speed dependant.
1I see that you are not linking against winpthread like the upstream mingw. How exactly does this work? 2 3Boost.Thread calls the Win32 API directly. I don't know how GCC's thread_local implementation works; possibly they're directly calling the Win32 API too, even as libstdc++ wants to call pthreads. 4 5AFAIK the mingw64 upstream uses gcc's emutls which result in some calls to pthread_key_create and friends, and that is quite buggy. 6 7And that's why I run away screaming from pthreads wrappers. 8 9Which flags do I need to pass to gcc to get whatever configuration you have? 10 11See mingw-w64+gcc.sh on GitHub. 12https://github.com/StephanTLavavej/mingw-distro/blob/master/mingw-w64%2Bgcc.sh
Removing thread_local won't help here. Also that boost solution is not acceptable in GZDoom (neither the hack) but could be in a fork. Anyway that's a 64 bit unofficial build (or repackage) and that's not the recommended way of creating 32 bit executables.
Also the crash on exit in the FMaterial destructor in the GL renderer almost certainly is still there.
Edit: no, that one is gone.
I don't think using a non standard C++ library is a good idea anyway, it would compile only with that distro.
Thanks, but i was kidding when i said it was an elegant solution. 🤣 It's just a quick hack to prevent the crash.
Also i've just fixed a couple of bad merges. 😵 I haven't pushed the hack yet becouse i'm waiting for the MinGW-w64 devs but i don't actually think they'll look into it, also i think that thread_local thing is hopeless at least for now.
No problem debugging here but i use Code::Blocks mostly. I usually compile from the command line since the IDE most times won't catch the -j2 parameter.
You don't need MSYS at all, i use Code::Blocks but compile from the windows command line increasing the buffer for cmd for convenience.
It's better to debug from the IDE. Just remember that in tdm-gcc the debugger is called gdb32 and not just gdb.
Of course i added the path to the MinGW binaries to the system path (editing Path in advanced system properties).
Also i've got MSYS2 installed for MinGW-w64 (but it's not required either).
The DirectX libraries are included in the MinGW package.
I wrote a couple of mini-guides @ https://forum.zdoom.org/viewtopic.php?f=4&t=60338
I think the code below is the cause, or at least one of the causes, of the thread_local issue in mingw-w64. This code is in the libc++ library which then references the libc function __cxa_thread_atexit. Some untested changes are below to instead use a different code path for testing. LLVM handled it with a different solution: https://reviews.llvm.org/D21803.