Can't Launch Game (Windows 10)

[KMG1]

I recently dug up an old copy of D64EX and I couldn't get it to launch (sits in background chewing up ~2MB of memory and nothing else). I tried the latest versions (both from the WordPress link and the latest daily build) and generating the IWAD from a different ROM but the same thing occurs. I tried to do some debugging on my end, but I'm unfamiliar with MSYS2/CMAKE so I'm having difficulties getting the mingw makefiles generated.

Unfortunately I can't provide anything other than these vague statements, as I can't seem to find a logfile that could point me in the right direction. Here is some additional information on my system if that helps:

OS: Windows 10 16299.30 CPU: AMD Ryzen 1800x GPU: EVGA 1070 SC

Any ideas and/or tips for getting the code to build on Windows?

[pinkwah]

Hey, thanks for the bug report.

I recently figured out the reason behind the ridiculous amounts of errors in Microsoft's own headers, so MSVC support isn't far away. I just commited some fixes that lets me compile the project. Sadly the program crashes immediately on launch.

I'll keep you posted.

[KMG1]

Thanks, when you get MSVC support added in I can do some digging around on my own as well to try and see where the issue is coming from.

[KMG1]

Did you have to do anything beyond what's contained in the release you uploaded a few days ago to get it to build? I got CMAKE to generate me the Visual Studio 2017 files but I am getting a ridiculous amount of errors from Microsoft standard headers (8415 to be precise). Upon further inspection I believe it may be caused by the usage of C-headers such as stdio.h and stdlib.h instead of their C++ equivalents.

[pinkwah]

While it's bad manners to use stdio.h instead of cstdio, it doesn't really affect anything. The real problem is sal.h, which apparently is included by default for some reason. I've removed it on the latest commit.

Otherwise I'm still not getting it to run. I'll probably have some time tomorrow to debug.

[pinkwah]

Well, I did some debugging and managed to find a deadlock in fluidsynth-lite that only happens on Windows with win32 threads.

This shouldn't affect the Wordpress version, so that's still a mystery. My copy of 2.5 seems to work fine.

[KMG1]

Gotcha, I switched over to cloning the repo instead of this release and that fixed the header issues. I'm now getting a bunch of linker/library errors relating to fluidsynth-lite despite the fact that the compiler is looking at the lib file I generated (I'll have to dig into this more, probably an issue with compiler/linker flags).

And yeah I'm not sure why this issue is happening in 2.5 since from what I can tell there are people running it using Windows 10. Coincidentally I noticed Prboom+ is behaving in the same manner, but if I recall correctly D64EX was based on a non-BOOM port and the only similarities between the two would be the usage of SDL.

[KMG1]

So I managed to get the game running the other day after sorting out some issues:

• The free() call on Line 230 of i_system.cc was throwing a heap corruption exception. I commented it out as quick/dirty work-around.
• The call to getenv on line 1320 of net_client.cc threw an exception (can get the details on that later)
• When the engine attempted to decompress files from the pk3, code on line 246 of ZipWad,cc would always be -2. Got around this by removing all files from the pk3, which I imagine is going to cause game breaking issues.

Anyway, is the deadlock you're seeing the same one I'm getting from the call to fluid_mutex_lock on line 277 of fluid_defsfont.c ? Upon inspecting cached_sampledata_mutex it didn't look like all of its members were initialized, and a call to fluid_mutex_init managed to get the deadlock to go away. But as soon as the introduction credits fade out the game locks up on me, which may or may not be related to the other issues I was having (particularly with the pk3).

[pinkwah]

The deadlock is due to me using incorrect functions in the fluidsynth fork. It should be fixed, although I will need to take another look at it at some point.

The version built with MSVC crashes in a few random locations. Not fun.

Here's a version built with MinGW. Mind giving it a try?

[pinkwah]

Ugh. Got it to run with VS. Apparently inflateInit2 expects a bunch of variables to be initialised prior to being called. 🤷‍♂️

[KMG1]

Yes, that appears to have done the trick. Seems to be running correctly now, thanks! I'm noticing a few off things, but I'll save that for future investigation/issue posts.