GZDoom 3.5.1 Released

[Enjay]

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:

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.

[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]

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.

[Graf Zahl]

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]

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.

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.

[dpJudas]

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

[Rachael]

Post-mortem download stats:

[YasuoProjectX]

Sir i have problems about version of 3.5.1

---

Execution could not continue.

Unsupported OpenGL version.
At least OpenGL 3.3 with framebuffer support is required to run GZDoom.
For older versions of OpenGL please download the vintage build of GZDoom.

This version is for only Winodws 7? or should i download Framebuffer Support?
(btw sorry for grammar instead)

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