ZDoom running in Windows ME! 0.o

[Danfun64]

Speaking of w64, you never mentioned whether you got a fix for this issue working or not.

The good news is that I finally managed to compile 100%...the bad news is that it CTD.
After failing with a Release build, I compiled a Debug build (log here). When loading the Debug EXE in GDB, the game manages to load, but goes back to the Desktop five seconds into every time i try to open the fullscreen ZDoom tab.

---

Code: Select all

c:\zdoom>gdb zdoom
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from zdoom...done.
(gdb) run
Starting program: c:\zdoom\zdoom.exe
[New Thread 5720.0x11b0]
warning: `C:\WINDOWS\SYSTEM32\ntdll.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: `C:\WINDOWS\System32\wow64.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: `C:\WINDOWS\System32\wow64win.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
warning: `C:\WINDOWS\System32\wow64cpu.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
[New Thread 5720.0x1c4]
[New Thread 5720.0x109c]
[New Thread 5720.0xc18]
[New Thread 5720.0xbcc]
[New Thread 5720.0x1c80]
[New Thread 5720.0x1ae8]
[New Thread 5720.0x1f38]
[New Thread 5720.0xab4]
[New Thread 5720.0x1d3c]
warning: Couldn't read file zdoomstat.txt
[New Thread 5720.0x20f4]
[New Thread 5720.0x1d98]
[New Thread 5720.0x1bb8]
[New Thread 5720.0x1cf0]
[New Thread 5720.0x2028]
[New Thread 5720.0x120]
[New Thread 5720.0x2088]
[New Thread 5720.0x1aac]
[New Thread 5720.0xa6c]
[New Thread 5720.0xd90]
[New Thread 5720.0xc9c]
[Thread 5720.0x20f4 exited with code 0]
[Thread 5720.0x1d98 exited with code 0]
[Thread 5720.0x1bb8 exited with code 0]
[Thread 5720.0x1cf0 exited with code 0]
[Thread 5720.0x2028 exited with code 0]
[New Thread 5720.0x11b4]
[New Thread 5720.0x1ea0]
[New Thread 5720.0x8fc]
[New Thread 5720.0xe3c]
[New Thread 5720.0x22cc]
[New Thread 5720.0x1a88]
[Thread 5720.0x2088 exited with code 0]
[Thread 5720.0x1aac exited with code 0]
[Thread 5720.0xa6c exited with code 0]
[Thread 5720.0xd90 exited with code 0]
[Thread 5720.0xc9c exited with code 0]
[New Thread 5720.0x1950]
[New Thread 5720.0x16d0]
[New Thread 5720.0xd3c]
[New Thread 5720.0x229c]
[New Thread 5720.0x4c]
[Thread 5720.0x1ea0 exited with code 0]
[Thread 5720.0x8fc exited with code 0]
[Thread 5720.0xe3c exited with code 0]
[Thread 5720.0x22cc exited with code 0]
[Thread 5720.0x1a88 exited with code 0]
[New Thread 5720.0x18f4]
[New Thread 5720.0x1da8]
[New Thread 5720.0x1970]
[New Thread 5720.0x1014]
[New Thread 5720.0x1c8c]
[Thread 5720.0x1950 exited with code 0]
[Thread 5720.0x16d0 exited with code 0]
[Thread 5720.0xd3c exited with code 0]
[Thread 5720.0x229c exited with code 0]
[Thread 5720.0x4c exited with code 0]
[New Thread 5720.0x1524]
[New Thread 5720.0x2340]
[New Thread 5720.0xb4]
[New Thread 5720.0x23bc]
[New Thread 5720.0x290]
[Thread 5720.0x18f4 exited with code 0]
[Thread 5720.0x1da8 exited with code 0]
[Thread 5720.0x1970 exited with code 0]
[Thread 5720.0x1014 exited with code 0]
[Thread 5720.0x1c8c exited with code 0]
[Thread 5720.0x1524 exited with code 0]
[Thread 5720.0x2340 exited with code 0]
[Thread 5720.0xb4 exited with code 0]
[Thread 5720.0x23bc exited with code 0]
[Thread 5720.0x290 exited with code 0]
[Thread 5720.0x11b4 exited with code 0]
[Thread 5720.0xab4 exited with code 0]
[Thread 5720.0x1d3c exited with code 0]
[Thread 5720.0x120 exited with code 0]
[Thread 5720.0x1ae8 exited with code 0]
[Thread 5720.0x1c80 exited with code 0]
[Thread 5720.0xbcc exited with code 0]
[Thread 5720.0xc18 exited with code 0]
[Thread 5720.0x109c exited with code 0]
[Thread 5720.0x1c4 exited with code 0]
[Thread 5720.0x1f38 exited with code 0]
[Inferior 1 (process 5720) exited normally]
(gdb)

[Blzut3]

That's still on the plate to address. If you want, open up a ticket on the new bug tracker and I can keep you updated there.

[Rachael]

@ Blzut3: I noticed one issue with the build you provided.



I didn't even notice it until I just randomly looked at it - but is gzdoom.exe really supposed to be that big? o.o

Even for a debug build - that's a bit hefty.

[ibm5155]

If that salad.exe gaves me 10+ fps I'm into it.

[Blzut3]

I didn't even notice it until I just randomly looked at it - but is gzdoom.exe really supposed to be that big? o.o

Yep. GCC's debugging symbols are pretty big.

[drfrag]

@Blzut3: What is zdoom9xtest.zip?

[Blzut3]

At almost a year old, I don't remember any more. I regularly built ZDoom and played with it on Windows 98 and either that was uploaded by request or it was simply the easiest way to get a build on the machine I was testing it on.

[leileilol]

In an emulated context zdoom 2.8.1 works well in a japanese Windows ME even. No change on the blank log window however

The emulated CPU here's a Pentium MMX 200 and runs ok ONCE you start forcing 11khz and not use the OPL emulation at all.

@blzut3: I stirred a bit of fork interest elsewhere and suddenly someone's also making mingw builds (albeit of older versions)

[Blzut3]

@blzut3: I stirred a bit of fork interest elsewhere and suddenly someone's also making mingw builds (albeit of older versions)

Cool. Although I don't follow how they got to sticking with ZDoom 2.7.1 instead of 2.8.1. Also no need to use MinGW for those versions. 2.8.1 was compiled with VS2005 which can target 95 with the hack to resolve the missing symbol you see in the error messages you posted earlier. We just removed the hack since there's no point keeping 95 compat if there's no sound. (Just to not give any false impressions: no we won't accept any patches on this, but it's cool to see interest in a fork.)

Making it easier to compile with MinGW without needing Cmake

Please don't make this a real goal. Learn to use CMake. It's really not hard at all once you do it a few times. As I believe I stated to you with Engoo with a not very old version of CMake it can even generate VC6 projects so there's really no reason to hand generate project files these days. It really does make things easier for other people since hand generated project files are almost always selfish (that is to say they depend on some part of the original author's system setup).

Worth noting that the GZDoom build I did wasn't much more than just selecting MinGW Makefiles in the GUI and picking the compiler binaries (I have multiple MinGW installs so the latter part isn't necessary). I think there was a bad DirectX import, which is something I can look into fixing generically. I may or may not have modified some of the MinGW headers since it's been a long time since I did the from scratch setup. Will do another from scratch setup whenever I get a new laptop for Windows development.

Edit: Oh probably worth noting that I believe I fixed NT 4.0 support in 2.8.

[drfrag]

Cool. Although I don't follow how they got to sticking with ZDoom 2.7.1 instead of 2.8.1. Also no need to use MinGW for those versions.

That's the Dosbox forum but mostly deals with vintage hardware. ZDoom 2.7.1 was a nice and stable version and can run most mods, 2.8.x are buggy and specially the broken chainsaw bug rose his ugly head recently (actually all melee weapons were and this was a critical one IMO). BTW releasing the latest SVN as 1.8.2 final could be a good idea. Moreover 2.8 requires MMX and the assembly was removed recently. Seems like MinGW executables require less memory and it's a free environment.

The target machine for this, i think, should be a pentium with win95 (pentium ii machines mostly run win98). It's derived from the openal branch after the release of 2.7.1, openal seems to be faster than fmodex and worked on 95. Apparently there's a desktop update (IE4) requirement which must be removed (SHGetSpecialFolderPath), before installing that update which sucked i'd go with win98 directly. Unfortunately at that time the openal branch had serious issues with sounds in mods.
I'd like to get r_detail back as well, could be useful to get lower resolutions on modern machines and that was how doom looked back then, you know there are other ports trying to mimic vanilla doom (as a side note quadrupling horizontally while doubling horizontally could actually be playable).
So for this vintage ZDoom we would need a good codebase with working openal, assembly, no mmx and no severe bugs.

About your GZDoom 98 version i'm looking forward to it. A pentium ii on win 98 is a fine target ,most computers could play multiplayer games. Updating an older GZDoom to the latest ZDoom SVN while keeping the old renderer would be also nice for older machines (i had the idea a while back) but i don't think it's feasible and could not run GL mods of course, but at least you could have OpenGL on old cards.

[Rachael]

BTW releasing the latest SVN as 1.8.2 final could be a good idea.

You don't know how many times that's been suggested. Randi will not comment one way or the other about this - it's safe to assume this will never happen. (And really, only she is allowed to do that, since ZDoom is her little thing)

About your GZDoom 98 version i'm looking forward to it.

It could even go to Win95 if FMOD support is dropped as you suggested.

I will give such a project my blessing, but I am not going to do any actual work to maintain it. If it really becomes a thing, I'll even offer its binaries as a download alongside the official ones.

[Blzut3]

BTW releasing the latest SVN as 1.8.2 final could be a good idea.

What Eruanna said. It would be a good idea to fork from the end of the maint branch though and cherry pick fixes that didn't make it there. Shouldn't be too hard to get a solid base out of the 2.8 branch.

Outside of retro computing, the 2.8 branch is the end of an era of sorts so it would be very interesting to me at least to see someone maintain that.

Moreover 2.8 requires MMX and the assembly was removed recently.

I'm not certain where the MMX dependency came from. I believe there's only one function which back patches an MMX version and I don't recall anything about that code changing. That said the oldest thing I have is a Pentium 2 so I wouldn't have noticed. The removal of the assembly code is very recent so it wouldn't affect forking at the 2.8 branch.

Seems like MinGW executables require less memory and it's a free environment.

I find the memory thing a little odd, but I suppose being able to use C++11 would make things easier anyway. Just keep in mind that you do lose a few things using MinGW. I mentioned some exception problems earlier in this thread, but MinGW also doesn't support delay loading so unlike the VC++ binaries there's a hard dep on fmod if you compile with it enabled.

Side-note: With C++11 though one could pull in i_module and make having calls like SHGetSpecialFolderPath be optional with minimal boilerplate. 2.8 does have TOptWin32Proc which does similar but not quite as transparent.

The target machine for this, i think, should be a pentium with win95 (pentium ii machines mostly run win98). It's derived from the openal branch after the release of 2.7.1, openal seems to be faster than fmodex and worked on 95. Apparently there's a desktop update (IE4) requirement which must be removed (SHGetSpecialFolderPath), before installing that update which sucked i'd go with win98 directly. Unfortunately at that time the openal branch had serious issues with sounds in mods.

Don't know off hand how many fixes got into the OpenAL code post 2.8, but the good news is that they shouldn't be hard to cherry pick. The sound code should have seen a low rate of change.

I'd like to get r_detail back as well, could be useful to get lower resolutions on modern machines and that was how doom looked back then, you know there are other ports trying to mimic vanilla doom (as a side note quadrupling horizontally while doubling horizontally could actually be playable).

On Windows ZDoom does have -2 and -4 still which is handled at backend, so modern machines are still covered in this regard.

but at least you could have OpenGL on old cards.

So while I currently don't have an AGP OpenGL 2 card, I honestly don't care at all about the OpenGL renderer. (Which is to say that the only reason I have any interest at all in GZDoom is because ZDoom is no more.) Doesn't hurt to have it compiling under MinGW though which means it could in theory work on 98.

[Graf Zahl]

The only MMX dependency is the DoBlending function which exists for various hardware levels. Of course, a non-MMX version also exists because there's non-x86 systems that can't do such things, and that code is always present as fallback.

[drfrag]

For now the guy @vogons has built an executable based on the end of the openal branch, i don't know why but there were sound problems at the previous point. I've suggested him what you said, to base this on the maint branch.
IMO another good point to fork would be at the A_saw bug fix on 4 dec right before the asm removal. I was wrong and the chainsaw bug was introduced actually after 2.8.1 so it was fine, no reason to release another version.
The SHGetSpecialFolderPatch requirement came actually from openal itself but he has already removed it.

The only MMX dependency is the DoBlending function which exists for various hardware levels.

On MMX there was actually another BestColor function but if i'm not wrong both were removed recently and those two commits restored the fallback versions right?

[Graf Zahl]

Right? I did some profiling and the performance advantage of the MMX version was non-existent. I checked on two systems and both functions ran the exact same amount of milliseconds. In such a case it's really not worth keeping.

The story was a bit different for DoBlending: The assembly version that existed was indeed faster than the intrinsic MMX version but had no advantage against the SSE2 version once some design flaws were removed from that. But all became totally irrelevant just by the fact that this function never clocked enough time to ever register as a performance problem. For all intents and purposes the plain C version would be fully sufficient, even though it's 4x slower than the SSE2 version. But since the special versions already existed there was no need removing them.

But the assembly versions of both these functions were proven mostly worthless baggage without any real benefit - they only complicated the compile setup without providing anything of value, so off they went.