Nice! :3Rachael wrote:Thank you - it's fixed.
GZDoom 3.6.0 Released
Moderator: GZDoom Developers
-
- Posts: 73
- Joined: Sun Dec 17, 2017 3:22 am
- Graphics Processor: nVidia with Vulkan support
- Location: Moscow, Russia
Re: GZDoom 3.6.0 Released
-
- Vintage GZDoom Developer
- Posts: 3154
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
Re: GZDoom 3.6.0 Released
@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.

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.
-
- Posts: 2052
- Joined: Mon Aug 11, 2003 1:50 pm
- Location: Waveney, United Kingdom
Re: GZDoom 3.6.0 Released
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 
EDIT: Went for NVidia GTX-550Ti. 1GB model by, er, Gigabyte


Last edited by MartinHowe on Tue Oct 16, 2018 3:25 pm, edited 1 time in total.
-
- Posts: 2033
- Joined: Sat Jul 19, 2003 6:15 am
- Operating System Version (Optional): Tumbleweed x64
- Graphics Processor: Intel with Vulkan/Metal Support
- Location: Central Germany
Re: GZDoom 3.6.0 Released
I am being told by proxy that fluidsynth output, in a default build, is broken. Just grepping reveals:
Some distributions are on libfluidsynth.so.2 already. (Looks like it can be worked around with building with -DDYN_FLUIDSYNTH=BOOL:FALSE)
Code: Select all
13:56 a4:../gzdoom/gzdoom > git grep fluidsynth.so.
src/sound/mididevices/music_fluidsynth_mididevice.cpp:#define FLUIDSYNTHLIB1 "libfluidsynth.so.1"
-
- Lead GZDoom+Raze Developer
- Posts: 49194
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 3.6.0 Released
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???
What's the point of versioning if the old version cannot be installed if something needs it???
-
- Posts: 2958
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: GZDoom 3.6.0 Released
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.Hirogen2 wrote:Some distributions are on libfluidsynth.so.2 already.
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.
-
- Posts: 2033
- Joined: Sat Jul 19, 2003 6:15 am
- Operating System Version (Optional): Tumbleweed x64
- Graphics Processor: Intel with Vulkan/Metal Support
- Location: Central Germany
Re: GZDoom 3.6.0 Released
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.Chris wrote:Which distributions?Hirogen2 wrote:Some distributions are on libfluidsynth.so.2 already.
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.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 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 )
-
- Lead GZDoom+Raze Developer
- Posts: 49194
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 3.6.0 Released
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?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.

-
- Posts: 13854
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: GZDoom 3.6.0 Released
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.
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.
-
- Posts: 2958
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: GZDoom 3.6.0 Released
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.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?
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.
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).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.
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.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.
-
- Lead GZDoom+Raze Developer
- Posts: 49194
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 3.6.0 Released
Looking at the PR, there actually is a change in the ABI.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).
-
-
- Posts: 3188
- Joined: Wed Nov 24, 2004 12:59 pm
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: GZDoom 3.6.0 Released
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.Graf Zahl wrote:What's the point of versioning if the old version cannot be installed if something needs it???
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?

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.
-
- Posts: 2
- Joined: Fri Oct 19, 2018 10:45 am
Re: GZDoom 3.6.0 Released
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?
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?
-
- Posts: 80
- Joined: Mon May 08, 2017 11:44 am
- Graphics Processor: nVidia (Modern GZDoom)
- Location: Hungary
Re: GZDoom 3.6.0 Released
Menu Dim is not a new feature to GZDoom, and it have always behaved like this. For me, to be exact.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.
-
- Posts: 2
- Joined: Fri Oct 19, 2018 10:45 am
Re: GZDoom 3.6.0 Released
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).wolfmanfp wrote:Menu Dim is not a new feature to GZDoom, and it have always behaved like this. For me, to be exact.
Anyway DL on voxels for 64 version interesting me more than that.