GZDoom 3.6.0 Released

News about ZDoom, its child ports, or any closely related projects.
[ZDoom Home] [Documentation (Wiki)] [Official News] [Downloads] [Discord]

[Tap Here for Mobile-Friendly Forums]

Moderator: Developers

Re: GZDoom 3.6.0 Released

Postby Wohlstand » Sat Oct 13, 2018 5:54 am

Rachael wrote:Thank you - it's fixed.

Nice! :3
User avatar
Wohlstand
lib[ADL&OPN]MIDI Developer
 
Joined: 17 Dec 2017
Location: Moscow, Russia
Discord: Wohlstand#4881

Re: GZDoom 3.6.0 Released

Postby drfrag » Sat Oct 13, 2018 7:00 am

@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. :lol:
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.
User avatar
drfrag
I.R developer, I.R smart
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain

Re: GZDoom 3.6.0 Released

Postby MartinHowe » Sun Oct 14, 2018 5:42 am

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 :)
Last edited by MartinHowe on Tue Oct 16, 2018 4:25 pm, edited 1 time in total.
User avatar
MartinHowe
In space, no-one can hear you KILL an ALIEN
 
Joined: 11 Aug 2003
Location: Waveney, United Kingdom

Re: GZDoom 3.6.0 Released

Postby Hirogen2 » Tue Oct 16, 2018 6:57 am

I am being told by proxy that fluidsynth output, in a default build, is broken. Just grepping reveals:
Code: Select allExpand 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)
User avatar
Hirogen2
 
Joined: 19 Jul 2003
Location: Central Germany

Re: GZDoom 3.6.0 Released

Postby Graf Zahl » Tue Oct 16, 2018 7:25 am

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???
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom 3.6.0 Released

Postby Chris » Tue Oct 16, 2018 6:41 pm

Hirogen2 wrote: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.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: GZDoom 3.6.0 Released

Postby Hirogen2 » Wed Oct 17, 2018 7:07 am

Chris wrote:
Hirogen2 wrote: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 )
User avatar
Hirogen2
 
Joined: 19 Jul 2003
Location: Central Germany

Re: GZDoom 3.6.0 Released

Postby Graf Zahl » Wed Oct 17, 2018 7:31 am

Hirogen2 wrote: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? :?
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom 3.6.0 Released

Postby Rachael » Wed Oct 17, 2018 9:35 am

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.
User avatar
Rachael
QZDoom + Webmaster
 
Joined: 13 Jan 2004

Re: GZDoom 3.6.0 Released

Postby Chris » Wed Oct 17, 2018 5:21 pm

Graf Zahl wrote: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.

Hirogen2 wrote: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.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: GZDoom 3.6.0 Released

Postby Graf Zahl » Thu Oct 18, 2018 1:08 am

Chris wrote: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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom 3.6.0 Released

Postby Blzut3 » Fri Oct 19, 2018 12:50 am

Graf Zahl wrote: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? :lol: 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.
Blzut3
Pronounced: B-l-zut
 
 
 
Joined: 24 Nov 2004

Re: GZDoom 3.6.0 Released

Postby Corrosion » Fri Oct 19, 2018 11:53 am

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?
Corrosion
 
Joined: 19 Oct 2018

Re: GZDoom 3.6.0 Released

Postby wolfmanfp » Sat Oct 20, 2018 4:54 pm

Corrosion wrote: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.
User avatar
wolfmanfp
 
Joined: 08 May 2017
Location: Hungary
Discord: wolfmanfp#5234

Re: GZDoom 3.6.0 Released

Postby Corrosion » Mon Oct 22, 2018 3:53 am

wolfmanfp wrote: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.
Corrosion
 
Joined: 19 Oct 2018

PreviousNext

Return to ZDoom (and related) News

Who is online

Users browsing this forum: No registered users and 2 guests