GZDoom 3.5.1 Released

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

[Tap Here for Mobile-Friendly Forums]

Moderator: Developers

Re: GZDoom 3.5.1 Released

Postby Enjay » Sat Sep 22, 2018 4:19 am

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
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 3.5.1 Released

Postby Rachael » Sat Sep 22, 2018 4:47 am

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).
User avatar
Rachael
QZDoom + Webmaster
 
Joined: 13 Jan 2004

Re: GZDoom 3.5.1 Released

Postby dpJudas » Sat Sep 22, 2018 7:11 am

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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoom 3.5.1 Released

Postby Graf Zahl » Sat Sep 22, 2018 7:54 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: GZDoom 3.5.1 Released

Postby anotak » Sat Sep 22, 2018 12:56 pm

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 1:30 am, edited 1 time in total.
anotak
 
Joined: 06 Dec 2016

Re: GZDoom 3.5.1 Released

Postby dpJudas » Sat Sep 22, 2018 1:35 pm

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?).
dpJudas
 
 
 
Joined: 28 May 2016

Re: GZDoom 3.5.1 Released

Postby Rachael » Fri Oct 12, 2018 3:04 am

Post-mortem download stats:
User avatar
Rachael
QZDoom + Webmaster
 
Joined: 13 Jan 2004

Re: GZDoom 3.5.1 Released

Postby YasuoProjectX » Wed Oct 31, 2018 4:42 am

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
YasuoProjectX
 
Joined: 09 Oct 2018
Location: Ionia
Discord: BartLegend255

Re: GZDoom 3.5.1 Released

Postby Graf Zahl » Wed Oct 31, 2018 4:49 am

You need to get the vintage build if that message appears. It means that your graphics hardware is too old for the modern build.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Previous

Return to ZDoom (and related) News

Who is online

Users browsing this forum: No registered users and 2 guests