Suggestion : Overhaul revision of gzdoom

[Illasera]

Armchair developer indeed. It was hard reading through that tirade with the vast majority of it just showing a profound lack of understanding.

Understanding of what, exactly? Let's break it down here , Maybe we can get somewhere, I have done my best to make the initial post descriptive, May as well get descriptive
replies, as i did get from a few post , But most replies were summed to : "Not an issue", "Others made it worse" and "Do your own thing".

To summarize the issues in the initial posts are mostly considered with zscript, memory footprint and performance that i do believe that can be improved.

1.)I do think its an issue -> therefor i took time to write it.
2.)Other made it worse -> irrelevant
3.)Do your own thing -> The best i can offer right now is to debate and see if we can improve the current core if others will agree there is a need for.

(I see this is not the case, I will stick to bug-reporting when needed, The best i can offer is an opinion to things i have considered to be issues that nobody expressed interest in)

[Rachael]

We're not interested in a debate. If you cannot prove that your suggestions work better, then they're all absolutely moot and pointless. Please don't waste your time trying to debate "the best way to do things" when GZDoom has been spending the past 2 years SPECIFICALLY dissociating itself from optimization hacks like folding actor structures onto itself to save space.

It's terrible for code readability, it's terrible for an open project that accepts contributions from people of all levels of programming, and it's terrible practice in general. If you're still doing that professionally, don't tell me what work you've published because I want no part of that! It sounds like a clusterfuck and the principles you are applying are why there is so much buggy shit out there today.

[JadedLexi]

But most replies were summed to : "Not an issue", "Others made it worse" and "Do your own thing".

Probably because they think this whole thread is a joke.

[Illasera]

It's terrible for code readability, it's terrible for an open project that accepts contributions from people of all levels of programming, and it's terrible practice in general. If you're still doing that professionally, don't tell me what work you've published because I want no part of that! It sounds like a clusterfuck and the principles you are applying are why there is so much buggy shit out there today.

And make good money out of it, Anyway, It seems like i got an answer, I guess we can move on.

[dpJudas]

Understanding of what, exactly?

Off the top of my head:

1) Operating systems work with pages, which are swapped in and out. Parts of an executable not used are not part of the working set of the executable. Thus, splitting things into a DLL does not really help on anything if the problem is that performance critical parts of a program gets swapped out of the L1 and L2 caches. In fact, splitting things into DLLs can worsen the situation as the compiler is unable to inline across DLL boundaries which means memory locality may be hurt.

2) Saying GLSL can't do light with some odd description of light calculations in sRGB space vs linear space is just plain nonsense. All games between 1995 to 2005 that did dynamic lights did it this way because the GPU's weren't fast enough. Not that you really offered any improvement beyond "duurrr remove the feature", which is already implemented because you can just turn it off..

3) Clueless statements like "just don't use doubles". No real developer would make such a statement on an existing codebase because... I really shouldn't have to explain this, but just as a simple example try do a Find in Files for the word "double" in the codebase and get an idea of how many lines are affected by your one-liner "solution".

3.)Do your own thing -> I can not allocate time, but i can allocate time to debate and see if we can improve the current core if desired.

Opinions are like assholes - everyone has one. Armchair developers trademark is that they, surprise surprise, can't commit any time themselves, but they are all too busy trying to explain how everyone else should do it.

[Rachael]

And make good money out of it, Anyway, It seems like i got an answer, I guess we can move on.

Like I said - PLEASE don't tell me what programs you've published - because that means those are programs I can't consciously use. If these terrible programming practices are your idea of the proper way to do things - and mind you you're not the only one - it is the very reason why there's so much garbage out there. The human mind cannot keep track of every little nook and cranny in a code, especially as it gets much more complex, and there are things you will inevitably overlook. And if you forget "I did X or Y hack for Z code" you make a critical error that causes program crashes, or worse, security issues.

This rubbish might have worked in the 90's. But now that we have technology that can handle, as you call it, "bloated code" - things can be made much more carefully and can avoid a lot of those errors.

[Graf Zahl]

It's not about being descriptive but that nearly everything you posted is entirely misguided and won't improve anything - all it'd do is make development harder because instead of a single coherent project you end up with a scattered, hard to maintain mess that ultimately does not make anything faster, at least not in measurable degrees. It's even far more likely that things will become SLOWER, because offloading too much stuff to external libraries will restrict the compiler's optimizer's effectiveness.

Don't ever think that the code isn't frequently profiled. I recently reordered the sector structure to be supposedly more cache friendly to the renderer - the result was zero, despite reducing its size by 10% and grouping its content for better access by the renderer. I think you are grossly underestimate CPU caches here.

I also checked floats vs. doubles: No difference in performance could be observed whatsoever, so precision won out.

And I could go on responding to the rest - the result would come back the same.
I've been programming professionally for 24 years and let me tell you that if I have to choose between an obfuscating to-the-metal optimization and keeping the code readable, I'll always keep the code readable.

On the other hand: Since the code base is relatively clean it was no problem to add some simple multithreading to the renderer, having the BSP traversal decoupled from the render list generation. That was a 15-20% performance improvement. Hacking the code would have made such a thing impossible because this depended on the code being clean.

[kevansevans]

Always cute to read pro tips from armchair developers.

"Software Engineer" I think we found the problem here.

Scathing comment aside, OP your whole argument reads like you have absolutely no idea how this engine works or why any of the decisions were made working on this source. On top of that, you can't seem to actually show you know what you're talking about, because any programmer worth their salt understands the fundamental principle of "Do it yourself or shut up".

[Rachael]

I think what needs to be said has, at this point, been said. I am locking this topic for two reasons: A) I think it serves as an excellent example of why you don't tell programmers how to program. If the quick and plentiful backlash isn't enough of a deterrent, then maybe the embarrassing comments from the people who know how to counter your points will. And B) I don't want this to devolve into a worse mess than it already is.

Just be glad I was talked out of pinning this thread exactly for A's reference point. I was told of how mean that would be - but it is important in case other people want to try that bullshit, too.