GZDoom 4.2.1 released

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

[Tap Here for Mobile-Friendly Forums]

Moderator: GZDoom Developers

Re: GZDoom 4.2.1 released

Postby axredneck » Sun Sep 15, 2019 7:43 am

EDuke32 devs already altered some physics, now Duke doesn't fit some vent shafts in some community maps. So i believe Graf will refuse to do the same with GZDoom.
User avatar
axredneck
excuse me for my bad English
 
Joined: 11 Dec 2017
Location: Russia
Github ID: axredneck
Operating System: Other Linux 64-bit
Graphics Processor: nVidia with Vulkan support

Re: GZDoom 4.2.1 released

Postby Enjay » Sun Sep 15, 2019 7:58 am

I'm pretty sure Graf would never implement it as a universal-can't-switch-off option, but perhaps it's something that could be an option set in MAPINFO or similar for maps specifically designed for that kind of collision. That is, of course, assuming that it could even be added without cluttering things up and causing a maintenance headache.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: GZDoom 4.2.1 released

Postby Graf Zahl » Sun Sep 15, 2019 3:04 pm

The first rule of source port development always needs to be "don't break shit!" The only exception would be cases where keeping the broken behavior would be far worse.
Sadly, ZDoom has neglected this in the past on occasion. No idea about EDuke breaking some maps, but I think it has taken a steep nosedive over the last half year (all owed to Ion Fury), and one of the reasons why I have chosen to stick with an older version is the altered collision code.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom 4.2.1 released

Postby PlayerLin » Fri Sep 20, 2019 11:08 am

Graf Zahl wrote:Sadly, ZDoom has neglected this in the past on occasion. No idea about EDuke breaking some maps, but I think it has taken a steep nosedive over the last half year (all owed to Ion Fury), and one of the reasons why I have chosen to stick with an older version is the altered collision code.


As I know, the devs want to fix the old Duke3D bug -- the buggy engine hacks and odd behaviors in the clipping system of Build/Duke3D engine code...(like those glitches make player clip through some walls/sectors/sector over sector, and then skip large part of level or get squished, as a Duke3D hardcore player, I HATE this shit happens, because 90% of time when this glitch happens, my Duke will be killed in pieces... :evil: )

At least the vent shafts problems still in-fixing, but sadly, it may still make more break changes when EDuke32 devs still try to change/fix these "original behaviors they think they're buggy".
User avatar
PlayerLin
 
Joined: 11 Nov 2007
Location: XinZhuang, XinBei/New Taipei City(Former Taipei County), Taiwan.

Re: GZDoom 4.2.1 released

Postby Graf Zahl » Fri Sep 20, 2019 12:13 pm

In that case, the RedNukem fork may be more to your liking, aside from being able to play Redneck Rampage it removed lots of demo breaking additions from EDuke and since it's supposed to be demo compatible will still have all the old glitches. I really hope that NukeYKT eventually upgrades its feature set without gratuitously breaking things. Judging from some of the recent commits it looks ike EDuke has chosen the road to hell anyway, that port is heading in the entirely wrong direction, if you ask me.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom 4.2.1 released

Postby TheMafla » Mon Sep 23, 2019 5:24 pm

I have a question, if textures can be scaled, will it be possible in the future that the textures of the walls can be rotated and skewed?

And by the way, I hope they fix that bug soon with the flat sprites where any actor who passes over it looks like it's underneath.
User avatar
TheMafla
 
Joined: 20 Jun 2018
Discord: None
Twitch ID: None

Re: GZDoom 4.2.1 released

Postby Cherno » Mon Sep 23, 2019 8:15 pm

TheMafla wrote:
And by the way, I hope they fix that bug soon with the flat sprites where any actor who passes over it looks like it's underneath.


Oh wow, and here I am wondering why this happens in my mod :D Thanks for bringing this up, so it's not me messing up my actors which is causing this behavior :)

In the meantime, I will use flat models for these sprites.
User avatar
Cherno
 
Joined: 06 Dec 2016

Re: GZDoom 4.2.1 released

Postby messkatonic » Thu Sep 26, 2019 1:22 pm

The improvement to Vulkan support's already been noticeable. With the first release it was reliably slower than OpenGL, but having tested 4.2.1 on both an Intel HD 630 with a Core i7 7700 and a GTX Titan X with a Core i9 7940x, there's a notable advantage over the vanilla GL renderer. Wonderful work! If I've got time tonight I'll test on my Xubuntu-running Ryzen 1700 with a Vega 56 too.
messkatonic
 
Joined: 26 Sep 2019
Discord: @messkatonic#9338
Twitch ID: messkatonic
Operating System: Debian-like Linux (Debian, Ubuntu, Kali, Mint, etc) 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: GZDoom 4.2.1 released

Postby Kamil » Thu Sep 26, 2019 3:20 pm

I finally tried the new GZDoom and was pleasantly surprised. I got such results. OpenGL 60-130 fps. Vulkan from 150 fps and up. I tested Project Brutality with maximum settings
Kamil
 
Joined: 21 Sep 2019
Discord: @Kamil#8122
Operating System: Windows Vista/7 64-bit
Graphics Processor: ATI/AMD (Legacy GZDoom)

Re: GZDoom 4.2.1 released

Postby Kamil » Sat Sep 28, 2019 10:33 am

Hi Graf. Excellent update. Vulkan rendering works fine on my computer. Open GL only gave 80-150 fps. Vulkan from 150 and more. I tested Project Brutality 3.0 with all the effects turned on. Sorry that I mistakenly thought badly about you. I thought you didn’t care about optimization. But it turns out to be a problem in old AMD video cards. I am very ashamed. I believe that GZDoom will become better and better.
Kamil
 
Joined: 21 Sep 2019
Discord: @Kamil#8122
Operating System: Windows Vista/7 64-bit
Graphics Processor: ATI/AMD (Legacy GZDoom)

Re: GZDoom 4.2.1 released

Postby drfrag » Sat Sep 28, 2019 12:54 pm

People has been complaining about lack of optimization on amd/ati since the beginning, specially on doomworld.
User avatar
drfrag
I.R developer, I.R smart
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain

Re: GZDoom 4.2.1 released

Postby Graf Zahl » Sat Sep 28, 2019 1:20 pm

AMD driver performance has been crap since the first benchmark I had run, approximately 10 years ago - and the specific problem they had never got fixed.
Before that there was another problem with ATI and fog in OpenGL 2. Somewhere in the transformation pipeline vertices weren't clipped to the screen and as a result fog looked totally broken.
They never ever fixed that bug - if was only when shaders became available that I could do something about it.

So, even though their Vulkan performance is fine, who knows when they do a big screwup again and then don't care?
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom 4.2.1 released

Postby messkatonic » Tue Oct 01, 2019 1:01 pm

Graf Zahl wrote:AMD driver performance has been crap since the first benchmark I had run, approximately 10 years ago - and the specific problem they had never got fixed.
Before that there was another problem with ATI and fog in OpenGL 2. Somewhere in the transformation pipeline vertices weren't clipped to the screen and as a result fog looked totally broken.
They never ever fixed that bug - if was only when shaders became available that I could do something about it.

So, even though their Vulkan performance is fine, who knows when they do a big screwup again and then don't care?


As you know OpenGL on Windows has been treated as a necessary evil by pretty much everybody that isn't Nvidia. AMD likes Vulkan because it's a simpler driver stack for them to maintain, and because their GL codebase is a huge pile of code left impenetrable by staff turnover and internal issues. They're pushing Vulkan as hard as anybody, and I really do think their support for the API will remain solid. At least, here's hoping.

To prove that Vulkan isn't a magic band-aid, I did notice on Intel's latest Win10 Vulkan drivers for the HD 630 that trying to set GL_NEAREST_MIPMAP_LINEAR in the menu resulted in incorrect linear filtering being applied, though I couldn't tell at a glance whether it was trilinear or bilinear. Nearest neighbor filtering sans mipmapping worked as expected. I assume Intel's mishandling something in the driver, but that might be pessimistic of me.
messkatonic
 
Joined: 26 Sep 2019
Discord: @messkatonic#9338
Twitch ID: messkatonic
Operating System: Debian-like Linux (Debian, Ubuntu, Kali, Mint, etc) 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: GZDoom 4.2.1 released

Postby Caiuz » Tue Oct 08, 2019 2:21 pm

hi graf,
I have not found where to put my idea on githb.
my idea is to insert a command in the console to record demos in doom to "record file" and "play file" from the console ~. for youtuber and gamer thanks
User avatar
Caiuz
 
Joined: 28 Oct 2016

Re: GZDoom 4.2.1 released

Postby _mental_ » Tue Oct 08, 2019 2:27 pm

Caiuz wrote:my idea is to insert a command in the console to record demos in doom to "record file" and "play file" from the console ~.

Do you want these commands?
_mental_
 
 
 
Joined: 07 Aug 2011

PreviousNext

Return to ZDoom (and related) News

Who is online

Users browsing this forum: No registered users and 2 guests