GZDoom 3.6.0 Released

[Wohlstand]

Thank you - it's fixed.

Nice! :3

[drfrag]

@MartinHowe: you should replace the fan and soon then. Here at Cex with luck you can get a low-end nvidia card for 20€ and it would be better than your current one. Now thanks to Blzut i have a GT 710 and it costs only 36€ new, it's bottom of the barrel but i get 4x the performance of my old radeon hd 4650 in GZDoom and GL 4.6. Here it's a bit expensive (1/10 of the typical salary) and it's regarded as a good card for serious gaming.
Edit: you could try decreasing the core clock using CCC (AMD overdrive) or another tool. Try setting the core to 600 MHz if possible and check temperature, of course you'd lose quite a bit of performance. Decreasing voltage as well would be far more effective but it's not possible with that tool AFAIK.

[MartinHowe]

OK, thanks. I am still thinking it all over, but will consider what you've said.

EDIT: Went for NVidia GTX-550Ti. 1GB model by, er, Gigabyte OpenGL4.6 supported 100% Should future-proof me for a while

[Hirogen2]

I am being told by proxy that fluidsynth output, in a default build, is broken. Just grepping reveals:

Code: Select all • Expand view

13:56 a4:../gzdoom/gzdoom > git grep fluidsynth.so.
src/sound/mididevices/music_fluidsynth_mididevice.cpp:#define FLUIDSYNTHLIB1    "libfluidsynth.so.1"


Some distributions are on libfluidsynth.so.2 already. (Looks like it can be worked around with building with -DDYN_FLUIDSYNTH=BOOL:FALSE)

[Graf Zahl]

Behold the dependency hell Linux is suffereing from.
What's the point of versioning if the old version cannot be installed if something needs it???

[Chris]

Some distributions are on libfluidsynth.so.2 already.

Which distributions? On Debian, the latest is 1.1.11 in testing and unstable, which is still libfluidsynth.so.1. I can't say I read anything about a breaking ABI change in fluidsynth. Also noteworthy that on Debian, the package is libfluidsynth1. If there was such a version bump, I'd expect a separate libfluidsynth2 package that could be installed side-by-side.

I do recall that some flavors of BSD have a hair-trigger on .so version bumps. With OpenAL Soft, for instance, by default and on all Linux distros I'm aware of, it's libopenal.so.1 as it has been since the project started. One of the BSDs, though, is currently bumping that to libopenal.so.3 or something, for whatever reason.

[Hirogen2]

Some distributions are on libfluidsynth.so.2 already.

Which distributions?

That would be openSUSE. Now that you mentioned it, I looked at Gentoo and Arch, and am surprised to not find 2.x there yet, because I remember that community to be generally quick. 2.x came out a month ago, Sep 14 2018.

On Debian, the latest is 1.1.11 in testing and unstable, which is still libfluidsynth.so.1. I can't say I read anything about a breaking ABI change in fluidsynth. Also noteworthy that on Debian, the package is libfluidsynth1. If there was such a version bump, I'd expect a separate libfluidsynth2 package that could be installed side-by-side.

While you can have them installed side by side, the old one is, in general, subject to eviction by the package manager, since nothing depends on it. "dlopen" calls do not constitute a hard dependency; only the DT_NEEDED entries in the ELF program header are, i.e. what `ldd /bin/ls` outputs.

I switched the openSUSE package to just use -DDYN_xxx=OFF so it gets a link rather than dlopen, after which the dependency magic of a Linux distro can do its thing. (Leading to a suggestion to just always do that anyway - https://github.com/coelckers/gzdoom/pul ... -430599320 )

[Graf Zahl]

While you can have them installed side by side, the old one is, in general, subject to eviction by the package manager, since nothing depends on it. "dlopen" calls do not constitute a hard dependency; only the DT_NEEDED entries in the ELF program header are, i.e. what `ldd /bin/ls` outputs.

Why can't this be done in a sane fashion? What's the point of 'dlopen' if the system can delete this stuff at a whim?

[Rachael]

I'm actually kind of confused at what is really trying to be accomplished here. The only thing I can guess is Hirogen is trying, somehow, to support FluidSynth 2.0 for whatever distro/system he is using, and is throwing every quick or easy solution at the issue to see what will stick, without giving much regard to how this affects people using distributions that he isn't using.

I'd really just prefer it if we supported both libraries. And for the sake of the precompiled executables, we could either distribute our own copy of libfluidsynth.so, or statically link the library so that it's embedded anyhow. Does it depend on anything else that isn't included by default in distros? I'd really rather not include half of a Linux distro for every release just to solve this one issue.

[Chris]

Why can't this be done in a sane fashion? What's the point of 'dlopen' if the system can delete this stuff at a whim?

It's entirely up to the packager. As long as the gzdoom package has a dependency on libfluidsynth1, it's required to install gzdoom regardless if it's using dlopen or DT_NEEDED. If libfluidsynth1 is uninstalled while gzdoom is installed, the package manager will yell at you that gzdoom is broken. If gzdoom is instead installed as a "shrink-wrapped tarball", it's the user's responsibility to have and keep the necessary dependencies installed, just like Windows. If the user "manually" installs the dependencies through the package manager, it will know they're there at user request and will not remove them unless the user says otherwise.

The only difference between dlopen or DT_NEEDED is dlopen will return failure if the library isn't found when the call is made, while DT_NEEDED will fail at load time. Anything beyond that is up to the package manager, packager, and/or user, and the package manager behaves sanely here.

That would be openSUSE. Now that you mentioned it, I looked at Gentoo and Arch, and am surprised to not find 2.x there yet, because I remember that community to be generally quick. 2.x came out a month ago, Sep 14 2018.

Note that FluidSynth 2.x does not necessarily mean the library becomes libfluidsynth.so.2. The so version follows semantic versioning rules; the major version only changes on breaking ABI changes. The project version may be separate from that (semantic versioning is relatively useful for side-by-side library installs, but kind of dumb for project versioning).

I switched the openSUSE package to just use -DDYN_xxx=OFF so it gets a link rather than dlopen, after which the dependency magic of a Linux distro can do its thing.

It may be important to figure out what exactly changed with libfluidsynth.so.2. Linking to it is only part of the story, if the library interface had a breaking change GZDoom may need to update how it uses the library too.

[Graf Zahl]

Note that FluidSynth 2.x does not necessarily mean the library becomes libfluidsynth.so.2. The so version follows semantic versioning rules; the major version only changes on breaking ABI changes. The project version may be separate from that (semantic versioning is relatively useful for side-by-side library installs, but kind of dumb for project versioning).

Looking at the PR, there actually is a change in the ABI.

[Blzut3]

What's the point of versioning if the old version cannot be installed if something needs it???

Honestly this is the reason I like Ubuntu. While most other distros (especially rolling ones) like to assume you can rebuild the world the whim Ubuntu actually keeps old libraries around. They screw up occasionally, but overall I've had less issues than even Debian (see libjpeg). Generally it seems they keep old ABIs around until the last LTS version that used that ABI is EOL (5 years or so) which seems pretty reasonable especially since the libraries we use don't change ABI often.

Distros like Arch probably have AUR packages for old versions, but the users sure like to complain if you depend on the old version. Yeah I get the security argument, but at the same time Ubuntu will still be patching the old ABI so is it my problem? This was especially the case for Zandronum where we depended on an "old version" of OpenSSL but the truth was Ubuntu just decided they wouldn't break ABI and didn't even offer the newer ABI for awhile.

All that said fluidsynth is a "universe" package (i.e. community maintained) so it's possible the old ABI won't stick around. We'll just have to see. Fluidsynth 2 didn't release early enough to make 18.10, so it'll be awhile before it's a concern to me. Even if they do remove it it will be some time before "grab the package libfluidsyth1 from the old distro version and install it" won't work since it will be possible to side by side install it.

In short though I really do wish Linux distros would start taking long term ABI support seriously. It actually amuses me how they came up with a great solution to the ABI problem and then generally choose not to actually take advantage of it for political reasons.

As for the dependency problem, that's entirely a packaging issue. All package managers that I'm familiar with definitely allow you to specify run time deps manually. The GZDoom debs do have fluidsynth as a recommended package so in theory it shouldn't go automatically uninstalling, but at the same time it's not required for the package to be installed.

A quick look at the fluidsynth API suggests they forgot to include a way to query the version. That said one can use TOptProc to check for one of the removed symbols in the worst case, so should be pretty simple to support both versions at run time.

[Corrosion]

Got some questions about new version.
1. About new feature in 'Display Options' menu: Menu Dim. On first start up it was set to -1 and my menu used default/my mod dim color and intensify.
When I moved slider it's minimal position become 0 and menu havent dim at all. So if I want to return default game based (or mod based) dim I haven't another option than switch it to -1 in gzdoom.ini? Would be nice if it has -1 as minimal value for default settings.
Same question I have about menu blur - it was -1 until I tryed it out. Have it switch something in same way or it was just issue?
2. My second question about dynamic lighting, version difference and voxels. In legacy version voxels are affected by DL, but not in 64-bit (they just black at 0 sector brightness regardless DL). Same was in previous 3.5.1 and earlier versions (up to 3.3.2, where it was ok).
I'm using Reikall's Heretic Voxels, I also tryed my own voxels, I tryed same config file on both port versions, I tryed default setting by deleting config file - all the same.
Why is this happening and would it be fixed later?

[wolfmanfp]

1. About new feature in 'Display Options' menu: Menu Dim. On first start up it was set to -1 and my menu used default/my mod dim color and intensify.
When I moved slider it's minimal position become 0 and menu havent dim at all. So if I want to return default game based (or mod based) dim I haven't another option than switch it to -1 in gzdoom.ini? Would be nice if it has -1 as minimal value for default settings.

Menu Dim is not a new feature to GZDoom, and it have always behaved like this. For me, to be exact.

[Corrosion]

Menu Dim is not a new feature to GZDoom, and it have always behaved like this. For me, to be exact.

True, it wasn't new. Don't know how I was avoiding this option all the time, but I still feel it like uncompleted feature, where you can't back to default dim (maybe I miss something again).
Anyway DL on voxels for 64 version interesting me more than that.