GZDoom 3.5.1 Released

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

Moderator: GZDoom Developers

User avatar
Enjay
 
 
Posts: 26535
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland

Re: GZDoom 3.5.1 Released

Post by Enjay »

Graf Zahl wrote:The interesting thing with that discussion is that people got totally hung up on Nuts, even though that is probably the worst test case imaginable.
Yup, it's this again:
Enjay wrote:I've never really understood why people consider making nuts.wad playable to be some sort of gold standard to aim for. The map is a joke (I mean literally).
I mean, what's the point? No one really wants to play nuts.wad and, as Graf has pointed out, it's not good for making/testing improvements that would have a positive impact in real, actual playable maps.
User avatar
Rachael
Posts: 13608
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: GZDoom 3.5.1 Released

Post by Rachael »

It's people who just want to say GZDoom is terrible because it can't do X or Y. It's the same people who say GZDoom is bad because of lack of proper demo compatibility (although the fact that demos desync between versions constantly is a bit of a fair criticism, but nothing can really be done about that right now).
dpJudas
 
 
Posts: 3051
Joined: Sat May 28, 2016 1:01 pm

Re: GZDoom 3.5.1 Released

Post by dpJudas »

I only really bothered replying to that thread because it was jval asking for feedback. As the author of DelphiDoom he seemed genuinely trying to improve some aspect of his port and I felt it might be useful for him to know my take on the sprite situation in Doom. So I tried to get him to think a bit broader about the problem.

They didn't seem convinced by that. However, I'd still insist that Nuts is a terrible test as it is so atypical that you'll lose out on so many optimization opportunities because you didn't step back a bit and looked at the big picture. A typical Doom map with a large viewable area generally have both a high sprite count as well a large number of segments (visible lines). The way clipping is handled is really inefficient with each visible sprite and segment storing their clipping lists again and again. The searches done to ensure a sprite is clipped correctly is very expensive. The storing of the clip lists is expensive. The attempt to draw segments behinds sprites is a very inefficient design overall. Sprites in real maps are spread across many sectors, not all packed into one big CTF-andACTION style map. Whatever sort algorithm they figure out is the best for Nuts will most likely be a sub-optimal solution to real maps.

It is as if nobody posting in that thread read the first chapter in Zen of Code Optimization. It specifically illustrated how you can waste all your time trying to optimize the current solution to maybe get a 1-2 times speed boost (including hand-coding it in assembler and taking memory caches into account), missing out on the 100 times boost you get by changing the base algorithm for the entire problem.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49094
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 3.5.1 Released

Post by Graf Zahl »

dpJudas wrote:It is as if nobody posting in that thread read the first chapter in Zen of Code Optimization. It specifically illustrated how you can waste all your time trying to optimize the current solution to maybe get a 1-2 times speed boost (including hand-coding it in assembler and taking memory caches into account), missing out on the 100 times boost you get by changing the base algorithm for the entire problem.

I'm not really surprised. While I also believe that jval is genuinely trying to improve things, some of the remaining contributors to that discussion have a history of getting hung up on the details while missing the big picture. And they are repeating the same thing over there again.

We get the same thing over and over again when it comes to REJECT. I already concluded by testing realistic scenarios some 14 years ago that it's a waste of effort, and yet some people to this day insist that it is a must-have optimization that will bring magical performance improvements because, hey, it means that it can keep some code from running at all - never mind that the code in question rarely runs more than a few measly percent of each frame. And you can bet that they never ran a single test to come to that conclusion.
anotak
Posts: 43
Joined: Tue Dec 06, 2016 6:16 am

Re: GZDoom 3.5.1 Released

Post by anotak »

so i was a bit confused why there were some strange posts about nuts.wad in the doomworld thread, only to be told that it was linked here and that's why.

anyway, i stated my position on nuts.wad on dwf. which is, it's a good test wad to have among *many*. it's a poor case to choose to optimize for at the expense of other maps, which i don't think anyone in that thread was even suggesting. the discussion here about nuts was completely different.
dpJudas wrote:It is as if nobody posting in that thread
me and fraggle had a discussion on discord where he said, and i quote "it does seem like a bit of premature optimization".

the bit you quoted from me was *literally* about how i don't think there's much gains to be had in sprite sorting. i went on to post a suggestion for a serious algorithmic improvement for sprite clipping i've been working on immediately after your post. because for software renderers, that certainly is a huge bottleneck on maps like comatose and the given.

so anyway, i'd appreciate if y'all weren't so quick to jump to conclusions; and also be more aware of how this stuff influences people in your community who may come to the other thread and post.
Last edited by anotak on Sun Sep 23, 2018 12:30 am, edited 1 time in total.
dpJudas
 
 
Posts: 3051
Joined: Sat May 28, 2016 1:01 pm

Re: GZDoom 3.5.1 Released

Post by dpJudas »

anotak wrote:so anyway, i'd appreciate if y'all weren't so quick to jump to conclusions; and also be more aware of how this stuff influences people in your community who may come to the other thread and post.
Fair enough, my comments weren't entirely fair to everyone in the thread. I did make the comments this way, though, because I find it somewhat frustrating to have something that in theory could be an interesting discussion (why are sprites slow and what can be done to make them faster) quickly devolve to something I find rather uninteresting (is radixsort faster than mergesort for the Nuts dataset?).
User avatar
Rachael
Posts: 13608
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: GZDoom 3.5.1 Released

Post by Rachael »

Post-mortem download stats:
User avatar
YasuoProjectX
Posts: 183
Joined: Tue Oct 09, 2018 6:37 pm
Graphics Processor: nVidia (Modern GZDoom)
Location: Ionia

Re: GZDoom 3.5.1 Released

Post by YasuoProjectX »

Sir i have problems about version of 3.5.1

Spoiler:
This version is for only Winodws 7? or should i download Framebuffer Support?
(btw sorry for grammar instead)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49094
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: GZDoom 3.5.1 Released

Post by Graf Zahl »

You need to get the vintage build if that message appears. It means that your graphics hardware is too old for the modern build.

Return to “ZDoom (and related) News”