LZDoom 3.88b 02/26 released

[drfrag]

It's a problem with your system i think and hardware_concurrency() fails, it should return 2. Don't know why 4 is assigned when it returns 0, dpJudas knows.

[dpJudas]

Someone at a C++ committee decided it should be the application developers problem if a C++ standard library implementation was so poor that it couldn't even inform the caller how many hardware threads a system has.

When it returns zero I have to make a guess without any information about the system I'm running on and chose 4 as a number that isn't too small and isn't too big. I honestly didn't expect anyone to have this piss-poor implementation on a mainstream OS and only added a check at all for compliance. The real problem is that it returns zero to begin with - on my system 4 threads is a way too conservative number.

[_mental_]

I've hooked the continuous integration services and LZDoom doesn't compile on MacOS since "- fixed mouse cursor positioning in menu for Cocoa backend".

Code: Select all

/Users/travis/build/drfrag666/gzdoom/src/posix/cocoa/i_input.mm:487:30: error: no member named 'GetTrueHeight' in 'DFrameBuffer'
        outEvent->data2 += (screen->GetTrueHeight() - screen->VideoHeight) / 2;

This codebase is from before the merging of the renderers.
@_mental_: What should i do? Just revert it?

I fixed it in 6efd03b.

[Graf Zahl]

Someone at a C++ committee decided it should be the application developers problem if a C++ standard library implementation was so poor that it couldn't even inform the caller how many hardware threads a system has.

Let me guess: MinGW?
Seriously, this compiler should be banished in hell, if its makers never manage to get shipping a working C++ standard library with it.
That said, the survey code has a code fragment which tries to read the true number of cores, this could serve as a fallback on Windows.

[dpJudas]

Let me guess: MinGW?
Seriously, this compiler should be banished in hell, if its makers never manage to get shipping a working C++ standard library with it.
That said, the survey code has a code fragment which tries to read the true number of cores, this could serve as a fallback on Windows.

It isn't that I don't know how to use platform specific functions for the same deal, but rather other people (MinGW?) not doing their jobs. A C++ standard library on Windows really has no excuse for returning zero.

As far as I'm concerned it is MinGW that is broken, even if they are technically standards compliant. IMO the only reason this function is allowed to return zero is for platforms where the whole question has no meaning (exotic supercomputer hardware). My personal solution to the problem would be to stop using a broken compiler when there's a perfectly functional one for that same platform.

[Graf Zahl]

I fully agree. MinGW has a very bad history concerning compatibility with the operating system it's supposed to run on. The dependency on that truly ancient msvcrt.dll is just one issue - this one's from Visual C++ 6.0 times, it's very inefficient and partially buggy and AFAIK the only reason it still gets distributed with Windows is not to break MinGW-based software.

There's reasons why I spend no effort trying to make GZDoom compile on it.

[drfrag]

I fixed it in 6efd03b.

WOW! Thanks very much, this was completely unexpected. So it still runs on Mac OS...

Let me guess: MinGW?

He is using the "official" VS 2015 build. MinGW uses the shitty winpthreads library, it was good until they pretty much stopped maintaining it, not enough workforce it seems.

As far as I'm concerned it is MinGW that is broken, even if they are technically standards compliant.

AFAIK he hasn't even compiled the code and he's using the VS 2015 build, MinGW crashed on 64 bit systems until i fixed it a couple of days ago. But hey if it works it works. I guess performance would be abysmal anyway with MinGW.
I could try to add that fallback, something is wrong with his system.
I'm thinking about making the switch to the Unicode API here too and adding a few character manipulation functions, i don't think D3D and DDRAW would be much of a problem.
I don't know what randi would do and you know less "randiism" it's no good here.

Edit:

The dependency on that truly ancient msvcrt.dll is just one issue - this one's from Visual C++ 6.0 times, it's very inefficient and partially buggy

They extended it with the MinGW CRT, but yes crashes on exit galore that's why i had to add some hacks.

[dpJudas]

Okay if its VS 2015 then its that compiler that is shit instead. In any case, the solution is still the same: upgrade to a compiler that works (VS2017 or VS2019).

If you for some specific reason can't use that for LZDoom (dunno if it needs some legacy feature of the older compiler) then you could solve the problem by calling the Win32 API equivalent:

Code: Select all

int GetCPUThreads()
{
    SYSTEM_INFO info = {};
    GetSystemInfo(&info);
    return info.dwNumberOfProcessors;
}

[drfrag]

Thanks, that function would return double the cores with hypertreading. But no one has ever reported such a problem and he is claiming he's experiencing it on two different computers. Must be something else, on my amd laptop i can't disable vsync with D3D. I could change to VS 2017, in fact i'm using 2017 with the 2015 toolset.
I think i will fallback to two cores and print a warning if the function returns 0.

[dpJudas]

It is meant to return double the cores (for HT CPUs) - otherwise it wouldn't take advantage of hyperthreading.

I don't know why the other function returns zero on his computers. If I remember correctly VS2015's C++11 support arrived slowly bit by bit, so it might be a matter of not having installed the latest service pack for it. Or maybe his hardware somehow broke his OS (not sure which he runs). Either way, it involves debugging issues related to an old compiler.

That's one of the reasons I'm so reluctant to support old stuff - it locks me in a time bubble that is essentially a losing proposition for me in exchange for others saving money. Naturally I can't drop support for all software and hardware older than my own, but my patience grows increasingly thin as things age. The only rationale for using older C++ compilers on Windows for GZD I can think of is either laziness (CBA to upgrade) or a desire to support Windows XP: a computer OS that was released in 2001. Ultimately I don't want to pay the price for that when its all a hobby. I know your financial situation isn't too good so you may not have a choice, yet I don't want to invest more time in this than providing general advice.

Anyway, if that function I provided doesn't solve it I guess you guys will have to debug why.

Edit: about AMD and vsync on Direct 9, upgrading the compiler there won't make a difference. I don't know what could be wrong except maybe a AMD driver overriding D3D9. Generally we are back to the same problem: old graphics API (D3D 9 is from 2002), old OS and old hardware. Investing time here is nothing I can use professionally in 2019.

[Graf Zahl]

The only rationale for using older C++ compilers on Windows for GZD I can think of is either laziness (CBA to upgrade) or a desire to support Windows XP: a computer OS that was released in 2001.

Not even that is an excuse. For once, Visual Studio does not even work anymore on XP, so for a self-compiled EXE it's probably not relevant anymore and second, even with VS 2019 the legacy toolset can still be installed. But when it comes to compiler deficiencies that cripple the engine under VS 2015 I'd clearly declare the compiler unsupported. I'd rather say to use VS 2019 or else...

Whatever happens here is in all likelihood a combination of various old things getting in the way of each other. Well, too bad. Not my problem.

[drfrag]

I have the latest v140_xp, i doubt is a compiler problem. He's on win 7 x64, probably it's something completely different may be one of those recent security updates.
On this machine i have VS 2017 installed on windows 10, it's not my problem either (thanks to Blzut3 who donated me a cheapo laptop some months ago for development).
I was compiling this with VS 2015 becouse i thought it was faster on 32 bit.
Thanks anyway, i've set it to 2 and added a Printf.

I know your financial situation isn't too good so you may not have a choice

It's very bad, tinnitus is still strong and i haven't met the target for the fund rising campaign yet (i rose it slightly to pay important bills this month) and it's complicated to develop anything. But i don't even play doom anymore save for testing the legacy builds.

[drfrag]

Fun fact, i was using VS 2015 only for 32 bit builds, the x64 version is a VS 2017 build so it's not a compiler problem.

[dpJudas]

Just checked std::thread::hardware_concurrency on my computer (Windows 10 64 bit) and the function returns 64 (32 cores + hyperthreading). So it works here.

[dpJudas]

After thinking about this for a little bit I decided your solution is probably the best one. If it can't get the number of cores it warns the user and turns off multi-threading with the assumption it is some old system where even 4 was probably too high a number.