GZDoom 4.2.1 released

[axredneck]

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.

[Enjay]

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.

[Graf Zahl]

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.

[PlayerLin]

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... )

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".

[Graf Zahl]

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.

[TheMafla]

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.

[Cherno]

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 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.

[messkatonic]

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.

[Kamil]

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]

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.

[drfrag]

People has been complaining about lack of optimization on amd/ati since the beginning, specially on doomworld.

[Graf Zahl]

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?

[messkatonic]

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.

[Caiuz]

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

[_mental_]

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?