Pirate Doom map49 (Modders beware of Gzdoom that will make your mods unplayable to some people)

[obake]

4 hours ago, Graf Zahl said:

Hardware support for that generation is generally still present but you have to remember two things:

 

1. ATIs drivers for this generation of hardware are atrocious, i.e. for some of them this means 'totally broken'. To even make these cards work some workarounds are needed that only increase the performance issues they already have.

2. Mapping in 2019 often takes better systems for granted. This means that with more recent mods you'll be far more likely to have issues.

 

That said, my computer is also from 2012, I only replaced the graphics card last year because I needed one with Vulkan support, the old Geforce 550ti didn't have it.

 

Of course, if you are talking about an Intel integrated chipsets of this vintage, no, sorry, they are not "moderate", they are generally not made for any form of gaming and will even on medium sized maps drop to single digit frame rates. When the GL 2.x support issue came up last year we ran a few benchmarks and  the end the lack of performance here was one of the deciding factors to drop support. What you must not forget is that between 2012 and now average graphics performance of equivalent hardware increased by a factor of 4, and those Intel chips generally are 7-8x slower than a mid-range graphics card of the same vintage. What this normally adds up to is 20-25fps in 640x480 on an average limit removing Boom map.

 

@Graf Zahl I know things are getting heated. But I want to say something. No matter what people say about GZDoom, thank you for making it! Yes, it's probably not perfect. But for a guy like me, who has major troubles even getting things like PrBoom to work, GZDoom is a Godsend. It is incredibly user friendly, and I adore the amount of work put into it.

 

Please don't let a few sour words get in the way of developing more awesome content!

 

 

[ketmar]

59 minutes ago, obake said:

Please don't let a few sour words get in the way of developing more awesome content!

i think that most sourceport devs are somewhat used to such things. when we're doing our... duty ;-) right, people are mostly silent, because there aren't much things to complain about. and when something is not working, some people go very vocal.

[wallabra]

It's called bug reporting, and without it, collaboration and bugfixing would be impaired.

 

Either way, GZDoom is, indeed, amazing. Thank you Graf!

[ketmar]

yet what we've seen in this thread is not bug reporting, it is just a whining.

[wallabra]

Indeed.

[DwarfCleric]

Sorry for the delay, for some reason I'm not getting mail notifications on replies, will fix that... Reading the new posts...

 

edit: Ok, read it... In all fairness and good sport, I behaved like a hateful whining bitch and what I get in return is according to my initial attitude. I may or may not had written in a extra-confrontational manner to invoke a thought-provoking reaction. Of course people who have strong beliefs will deny and lash out at anything that goes beyond these beliefs. Everyone does that, you're doing it and I'm doing it now. Also, some people revealed themselves (pretty quickly too, in a voluntary manner and for free, thanks for the free labour...) that their way of speaking varies according to who they're talking too, even if that means supression of information or denying help to someone who is in need, just because they didn't say "please" or begged in their knees. 

 

Above all, what I'm most happy about is that these specific forums right here (Doomworld) don't suffer the "moderation" and "deleting" problem where posts are deleted or hidden just because the person didn't agree with what you said. And neither they are archived into the "Halls of The Dead > Halls of Unpleasantness" subforums. So freedom of speech still exists around here. (hopefully it keeps like this)

 

If I had told my computer specs from the beginning, it would provide the cheap shot of a quick excuse to point to, and to deny all discussion of the source of the matter. This still stands:

Quote

 

quote: like it or not GZDoom is not made with older PCs in mind. its tries to take advantage of newer more advanced PCs. its not GZDoom problem

 

Quote

 

quote: software designed for modern hardware will never run as well as something that was aimed at older, weaker hardware. Even vanilla maps will run slower in GZDoom versus PrBoom simply because it has a more advanced and demanding render.

 

Quote

 

quote: you don't need a high end PC to play Doom smoothly, but that doesn't apply to GZDoom and their mods.

 

All of these arguments don't hold water when I'm playing such a hardware-intensive map like Hellbound map29 (released 2013) in a computer from 2008. This "other software" (PrBoom+) is backward compatible to older hardware, not a problem there... In fact, PrBoom+ can also run Cryogenics (another hardware-intensive WAD released 2017... although the slowdowns are more noticeable in this one, but not game-breaking slow...) and Eviternity (a slightly-heavy WAD released 2018) This defies everything that you guys are saying.

 

My original intent with the thread remains, so hopefully people who are struggling will stumble upon this in their google searches and realize there's nothing wrong with their computer, they can still experience the joy of playing Doom mods without anyone telling them the opposite...

Quote

 

quote: Unzipped the old 2011 version. Loaded Hellbound (software mode) and warped to map29. No slowdowns whatsoever...

So the fault isn't in my hardware. This "old" piece of software from 2011 is perfectly able to render Hellbound map29.
Something (redacted by me...) is happening at the core of the GZdoom's renderer. (my whining redacted...)

I just wanted to put this out there for people who were having problems. 
No, you don't have to spend big bucks upgrading your machine to play Doom maps. No!

 

 

Edited December 4, 2019 by DwarfCleric

[seed]

You yourself said that your graphics card is not OpenGL3+ compatible in another topic, and GZDoom requires 3.2 at minimum (4.5 or 4.6 recommended, which, by the way, is basically taken for granted in 2019). Also, a 2008 PC trying to run the new GZDoom will do nothing but struggle with it because it simply doesn't meet the requirements. It seems you miss the point here, or just don't want to understand it. PrBoom has no issues with your hardware because it uses a GL render based on version 2.1, and ZDoomLE and other ports by drfrag also use older versions, or Direct3D.

 

Considering your "epic" part about "free speech" and your antagonistic attitude, at this rate I think you're just a troll. I'm done wasting my time.

[DwarfCleric]

The focus of this is not and never was OpenGL or opengl versions... The focus is sourceport comparisons using the same hardware. (by the way, all these tests I'm talking about were done using the SOFTWARE renderer with dynamic lights turned off, because it's obvious that openGL will not work for me, and I never liked the looks of openGL to begin with...)  But even when I select "software renderer" in newer versions of GzDoom, it doesn't let me even start, so it is not purely "software" in reality, is it?  (thank god for the existence of LZdoom... or better, thank the hard work of a generous man... and thank god it's a forked port, so no one can claim ownership over it or suppress changes)

 

I also forgot to mention before that the prBoom+ version I'm using is from 2016, so according to you guys logic it should not be working on my "obsolete hardware" from 2008. "All logic is defied, the ground disappears from below my feet, oh no what I'm gonna do"...

 

new update to the list: I just tested the Avactor WAD (again: software renderer only...) Gzdoom lags at the start and lags on the room near the start, where the pyramid is, slow to a point of being unplayable... prBoom+ works just fine (not even slowdowns like I notice in Hellbound map29)

So if we are to be focused in this single map, focusing on logic and present the technical arguments to the table, what is about this initial Avactor map that makes the renderer poop its pants? Is it the amount of linedefs/sidedefs/sectors? Is it something else? Is it both? What is it? I'm talking about this specific map, not in a general broad sense. (the problem with this is that people will perform this test on their newer super-powered core i7 NASA machines... so the slowdown won't even be noticed... open to suggestions on alternative methods...)

It's a fairly large file to download, if you want to provide the same information for Hellbound map29, fine, it's a smaller file but the same issues exist there. Or any other mod that you might have on hands...

[Graf Zahl]

1 hour ago, DwarfCleric said:

The focus of this is not and never was OpenGL or opengl versions... The focus is sourceport comparisons using the same hardware. (by the way, all these tests I'm talking about were done using the SOFTWARE renderer with dynamic lights turned off, because it's obvious that openGL will not work for me, and I never liked the looks of openGL to begin with...)  But even when I select "software renderer" in newer versions of GzDoom, it doesn't let me even start, so it is not purely "software" in reality, is it?  (thank god for the existence of LZdoom... or better, thank the hard work of a generous man... and thank god it's a forked port, so no one can claim ownership over it or suppress changes)

 

Even a software renderer needs a way to access the graphics card, and GZDoom now requires OpenGL 3 for that, that's why the split between modern and legacy was done after all. What you have to understand is that OpenGL 2.x is totally incompatible with how modern graphics cards work, so it is simply not possible to support these and Vulkan at the same time. And considering that the user share on Vulkan compatible hardware is about 25x higher than the user share on OpenGL 2 the decision was to separate development of legacy support from development for modern hardware, so that both can be served best.

 

But in the end, since you yourself admit that your computer is more than 10 years old, prepare for more trouble down the line. You literally depend on developers who consider developing for old hardware a worthwile endeavour, nobody shooting for modern hardware support will consider your system even remotely relevant anymore.

 

All that said, Pirate Doom is a mod that does not really work well without hardware rendering at all, so it is not surprising it's slow on such an old and obsolete system, especially with a software renderer.

 

 

[Master O]

18 minutes ago, Graf Zahl said:

 

Even a software renderer needs a way to access the graphics card, and GZDoom now requires OpenGL 3 for that, that's why the split between modern and legacy was done after all. What you have to understand is that OpenGL 2.x is totally incompatible with how modern graphics cards work, so it is simply not possible to support these and Vulkan at the same time. And considering that the user share on Vulkan compatible hardware is about 25x higher than the user share on OpenGL 2 the decision was to separate development of legacy support from development for modern hardware, so that both can be served best.

 

But in the end, since you yourself admit that your computer is more than 10 years old, prepare for more trouble down the line. You literally depend on developers who consider developing for old hardware a worthwile endeavour, nobody shooting for modern hardware support will consider your system even remotely relevant anymore.

 

All that said, Pirate Doom is a mod that does not really work well without hardware rendering at all, so it is not surprising it's slow on such an old and obsolete system, especially with a software renderer.

 

 

 

Speaking of Vulcan, is that basically 100% supported in GZdoom now?

[Graf Zahl]

The Vulkan renderer is for the most part working, except for one driver-side issue causing problems: From the looks of it the memory management tends to be a bit broken. Some drivers simply lock up when the game tries to allocate video RAM but the hardware cannot provide it. That normally only happens when using 4x upscaling or higher on resource intensive maps. When playing with normal low-res assets everything looks fine.

 

 

[m8f]

@DwarfCleric, if it's still not clear what's happening, here is an analogy:

 

Vanilla WAD <-> ASCII .txt file

Limit-removing WAD <-> UTF-8 .txt file

GZDoom WAD <-> OpenOffice/LibreOffice .odt document with fonts, formatting, embedded images, etc.

 

doom.exe <-> Notepad in Windows 95

prboom+ <-> Notepad in Windows 10

GZDoom <-> recent LibreOffice

 

It's like you try to open a .txt file with LibreOffice under DOS, fail to do so, and wonder why it doesn't work/doesn't open. It's still your original file from 1993, but older machine struggles opening it with more demanding software, because that software can do so much more with that file than vanilla did. And to be able to do these new things with old files, it needs to convert them internally into new data structures and formats that ultimately take more memory and processing power.

[DwarfCleric]

Oh, look at the kiddos, they love to gang up, daddy proud. Come here, puppy, here's a snack for you, good puppy :)

 

Ok let's try again with the question... 

 

Quote

So if we are to be focused in this single map, focusing on logic and present the technical arguments to the table, what is about this initial Avactor map that makes the renderer poop its pants? Is it the amount of linedefs/sidedefs/sectors? Is it something else? Is it both? What is it? I'm talking about this specific map, not in a general broad sense.

Avactor map01 (room at the start with the pyramid on it), pirate map49 (right at the start when you are still on the boat, looking to the castle), Cryogenics map01 (drop down and step into the teleporter) Hellbound map29 (right at the start when you go outside)

Can anyone provide explanations to why any of this list of maps cause slowdown? Let's see if we get a proper answer instead of going into a tangent. But of course that will not be done, because that would require actual work, and why give validation to someone else. This is getting quite entertaining because you guys end up validating all that I'm saying when you act exactly as I want. Let's take advantage that the programming master is in the house and let's see if he can provide some technical answers.

[seed]

I told ya you should not feed this troll.

 

If there was any doubt about that, now there's none. Nice show, "kid".

[Graf Zahl]

It's only your thoroughly underpowered computer. I only tested Pirate Doom MAP49. That map's initial view is > 4000 linedefs and >1000 sectors. My system from 2007 would have folded on that one as well and that one was probably a lot better than what you are using right now.

 

For that map you need something better than a system that was "adequate" 10 years ago, and trying that map with the software renderer doesn't even work that well on my system, merely showing 22 fps as opposed to 130 fps with the hardware renderer (both in 1920x1080.) Like I said: Pirate Doom was made for the hardware renderer, it contains things that make the software renderer totally throw up.