GZDoom 3.7.0 Released
Moderator: GZDoom Developers
-
- Posts: 13720
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: GZDoom 3.7.0 Released
It seems like for the Linux builds, that the "libjpeg-turbo8" package is required to run this. That seems to be a consequence of using a more modern build setup with newer libraries than was originally used to build the archives before.
I will have to fix this tomorrow - I can't do that right now. If you install the packages I have posted here, please remember to grab libjpeg-turbo8 with apt-get.
I will have to fix this tomorrow - I can't do that right now. If you install the packages I have posted here, please remember to grab libjpeg-turbo8 with apt-get.
-
- Posts: 4
- Joined: Sat Dec 29, 2018 4:06 am
Re: GZDoom 3.7.0 Released
Is this referring to sector light mode? The release notes say "add" but a vanilla option is present in previous builds. Is this something new or a change of previous behavior?add vanilla lightmode that behaves exactly as Doom's original light did
-
-
- Posts: 3109
- Joined: Sat May 28, 2016 1:01 pm
Re: GZDoom 3.7.0 Released
Yes, it is the new vanilla sector light mode. It is new for this release, but of course if you compare up against nightly builds it has been there for a little while.
-
- Lead GZDoom+Raze Developer
- Posts: 49130
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 3.7.0 Released
We'll have to do a point release next week anyway, there have been two major bug fixes since the release already.Rachael wrote: I will have to fix this tomorrow - I can't do that right now. If you install the packages I have posted here, please remember to grab libjpeg-turbo8 with apt-get.
-
- Posts: 13720
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: GZDoom 3.7.0 Released
That's probably for the best, then.
-
- Posts: 13720
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: GZDoom 3.7.0 Released
I fixed the 3.7.0 .deb packages. They now list the libjpeg-turbo8 dependency.
-
- Lead GZDoom+Raze Developer
- Posts: 49130
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 3.7.0 Released
Since there have been several bugs reported and fixed since the release, expect a point release addressing those on New Year.
-
- Posts: 6
- Joined: Thu Dec 21, 2017 9:29 pm
Re: GZDoom 3.7.0 Released
Hey guys, thanks for this new version of GZDoom. Has anyone posted a demonstration of "Destructible Geometry" feature yet?.
Well, since you guys were dicussing about the support of Vintage hardware, i'm wondering, does the modern version comes with a Software renderer? Because, instead of separating the sourceport in two version, wouldn't be possible to add vintage support through the Software renderer? As i understand, the Software renderer doesn't use any sort of OpenGL features or shaders, right? And, back in the day, i remember that previous version of GZDoom let you choose from the beginning between Hardware renderer (OpenGL) and Software Renderer.
Well, since you guys were dicussing about the support of Vintage hardware, i'm wondering, does the modern version comes with a Software renderer? Because, instead of separating the sourceport in two version, wouldn't be possible to add vintage support through the Software renderer? As i understand, the Software renderer doesn't use any sort of OpenGL features or shaders, right? And, back in the day, i remember that previous version of GZDoom let you choose from the beginning between Hardware renderer (OpenGL) and Software Renderer.
-
- Posts: 13720
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: GZDoom 3.7.0 Released
I honestly don't expect the vintage version to stay around in any form whatsoever, not software or otherwise, by the first of January 2020. That's not to say it'll definitely be gone by then, but that if you're sitting on hardware that is pre-OpenGL 3.3 you're sitting on a quagmire in terms of support. This is the major drawback of living in an era where technology innovates at such a rapid pace - your computer simply isn't the stove your grandma had for the last 50 years that still works. It just doesn't work like that.
If it were *actually* *easy* to support such dated hardware - rest assured, no matter what appearances Graf or any other developers give - it would be done. There comes a time in every project where a cost-benefit analysis must be done in order to see if dropping old code would be worthwhile to supporting newer things. And these days, GZDoom typically favors newer hardware for its newer features which in turn allows GZDoom users to enjoy newer features, as well. This isn't the first time that's happened.
If you want to write an OpenGL wrapper that simplifies the support needed for older hardware and drivers using the newer code - by all means, have at it. But at this point, especially with progressively changing standards with newer hardware, it is simply infeasible for the developers to do so, themselves. And before you all go "you lazy bastards, fuck you, assholes for not supporting my 20 year old toaster" - just remember that NOTHING would even be here if the developers didn't enjoy doing it.
So what it really comes down to - the world moves on, with or without you. If you want to keep up then you're just going to have to upgrade the hardware. Otherwise, expect 3.7.x to be the last major series to support your ancient device.
If it were *actually* *easy* to support such dated hardware - rest assured, no matter what appearances Graf or any other developers give - it would be done. There comes a time in every project where a cost-benefit analysis must be done in order to see if dropping old code would be worthwhile to supporting newer things. And these days, GZDoom typically favors newer hardware for its newer features which in turn allows GZDoom users to enjoy newer features, as well. This isn't the first time that's happened.
If you want to write an OpenGL wrapper that simplifies the support needed for older hardware and drivers using the newer code - by all means, have at it. But at this point, especially with progressively changing standards with newer hardware, it is simply infeasible for the developers to do so, themselves. And before you all go "you lazy bastards, fuck you, assholes for not supporting my 20 year old toaster" - just remember that NOTHING would even be here if the developers didn't enjoy doing it.
So what it really comes down to - the world moves on, with or without you. If you want to keep up then you're just going to have to upgrade the hardware. Otherwise, expect 3.7.x to be the last major series to support your ancient device.
-
- Posts: 7402
- Joined: Fri Oct 22, 2004 9:22 am
- Graphics Processor: nVidia with Vulkan support
- Location: MAP33
Re: GZDoom 3.7.0 Released
The feature request thread has a simple test map at the bottom.DoomFan25 wrote:Hey guys, thanks for this new version of GZDoom. Has anyone posted a demonstration of "Destructible Geometry" feature yet?.
The software renderer still exists, but as I understand it, it uses OpenGL to actually draw each software-rendered frame onto the screen.DoomFan25 wrote:Well, since you guys were dicussing about the support of Vintage hardware, i'm wondering, does the modern version comes with a Software renderer? Because, instead of separating the sourceport in two version, wouldn't be possible to add vintage support through the Software renderer? As i understand, the Software renderer doesn't use any sort of OpenGL features or shaders, right? And, back in the day, i remember that previous version of GZDoom let you choose from the beginning between Hardware renderer (OpenGL) and Software Renderer.
-
- Lead GZDoom+Raze Developer
- Posts: 49130
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 3.7.0 Released
The software renderer sits on top of the 2D drawer, and the 2D drawer uses the OpenGL backend to render stuff.
So if the new backend was solely for 2D - sure, it could be added. But let's not forget that according to our surveys last year the user share of such low systems was 2.5% last summer and rapidly shrinking. It is simply not worth investing more time here, especially for the software renderer, which doesn't receive all new render features.
Considering that we are now shortly past Christmas I think we can assume that a considerable portion of these old systems has been retired and current user share is even lower.
Checking the 3.5 survey's late-coming info it is evident that after the 3.6 release the number of old machines reporting dropped even further and is very quickly approaching the line where it will become irrelevant.
XP is already there, and the only reason it is still supported is that the effort for doing so is basically zero. Were it not, it'd be discontinued right away.
But the effort for supporting OpenGL pre 3.3 is not free of effort - it will require a completely separate render path because its use of shaders is far more restricted and an essential feature like uniform buffers does not exist. The latter point alone makes it virtually impossible to write code that runs on modern OpenGL while using its features and at the same time support legacy hardware.
So, sorry. Any work invested here would be a dead end. At some point you will have to accept that if you run an old computer you may be restricted to older versions of some software.
So if the new backend was solely for 2D - sure, it could be added. But let's not forget that according to our surveys last year the user share of such low systems was 2.5% last summer and rapidly shrinking. It is simply not worth investing more time here, especially for the software renderer, which doesn't receive all new render features.
Considering that we are now shortly past Christmas I think we can assume that a considerable portion of these old systems has been retired and current user share is even lower.
Checking the 3.5 survey's late-coming info it is evident that after the 3.6 release the number of old machines reporting dropped even further and is very quickly approaching the line where it will become irrelevant.
XP is already there, and the only reason it is still supported is that the effort for doing so is basically zero. Were it not, it'd be discontinued right away.
But the effort for supporting OpenGL pre 3.3 is not free of effort - it will require a completely separate render path because its use of shaders is far more restricted and an essential feature like uniform buffers does not exist. The latter point alone makes it virtually impossible to write code that runs on modern OpenGL while using its features and at the same time support legacy hardware.
So, sorry. Any work invested here would be a dead end. At some point you will have to accept that if you run an old computer you may be restricted to older versions of some software.
-
- Posts: 342
- Joined: Mon Feb 12, 2018 12:26 am
- Graphics Processor: Intel (Legacy GZDoom)
- Location: Australia
Re: GZDoom 3.7.0 Released
When are you planning to do the next hardware survey, and definitely ensure that code isn't in the last vintage build version.
-
- Lead GZDoom+Raze Developer
- Posts: 49130
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: GZDoom 3.7.0 Released
If 3.8 still has a vintage build, I think that's the right time to do another one. Enough time since Christmas will have passed so that it'd properly reflect what people are using. It'll be very interesting to see how much the number of such old systems got reduced, and even more, how 32 bit fares. Last time 32 bit was at 4% with a disproportionately high amount in the vintage build.
With the JIT only available in 64 bit, the future of 32 bit builds doesn't really look that great - it is clear that they cannot profit from future work on making the VM faster, which also means that as more code gets scriptified, they will suffer even more in the future.
Regarding 32 bit, what really puzzles me is that there's users around that have a modern high end graphics card but a 32 bit OS. With nearly all current games being 64 bit exclusive I wonder what's the point of such a setup.
With the JIT only available in 64 bit, the future of 32 bit builds doesn't really look that great - it is clear that they cannot profit from future work on making the VM faster, which also means that as more code gets scriptified, they will suffer even more in the future.
Regarding 32 bit, what really puzzles me is that there's users around that have a modern high end graphics card but a 32 bit OS. With nearly all current games being 64 bit exclusive I wonder what's the point of such a setup.
-
- Posts: 2113
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Re: GZDoom 3.7.0 Released
Some people (who clearly don't know enough to be making such claims) claim 64-bit is slower and uses more RAM, for some reason. There's likely also non-computer savvy people who either installed 32-bit Windows because they didn't know better, or asked someone (who very likely weren't very computer-savvy either) to install their OS.Graf Zahl wrote:Regarding 32 bit, what really puzzles me is that there's users around that have a modern high end graphics card but a 32 bit OS. With nearly all current games being 64 bit exclusive I wonder what's the point of such a setup.
And also probably a very small amount of people who somehow still have some ancient 32-bit CPU. But I bet there's barely any of those in the numbers.
-
- Posts: 13720
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: GZDoom 3.7.0 Released
Truth be told, with 2 GB or less, you're better off installing 32-bit Windows. 64-bit will run for shit and you will indeed get no benefits from running 64-bit applications.
The same is true of Linux at about 1 GB or so. You can have the best most state of the art processor in the world, but unless you have the RAM that can handle all the extra baggage that comes with modern operating systems it's all moot anyhow.
Mac OS X 10.4 ran just fine at 2 GB of RAM and it is a 64-bit OS. I haven't tested Linux with this configuration, yet, but Windows 64-bit is absolutely abysmal on it - but 32-bit Windows is just fine.
So there is some truth to it, but only with RAM-starved machines. Once you get to about 4GB or greater, then in all operating systems 64-bit provides a huge benefit - even if it's not obvious at only 4 GB.
The same is true of Linux at about 1 GB or so. You can have the best most state of the art processor in the world, but unless you have the RAM that can handle all the extra baggage that comes with modern operating systems it's all moot anyhow.
Mac OS X 10.4 ran just fine at 2 GB of RAM and it is a 64-bit OS. I haven't tested Linux with this configuration, yet, but Windows 64-bit is absolutely abysmal on it - but 32-bit Windows is just fine.
So there is some truth to it, but only with RAM-starved machines. Once you get to about 4GB or greater, then in all operating systems 64-bit provides a huge benefit - even if it's not obvious at only 4 GB.