Suggestion : Overhaul revision of gzdoom

[Illasera]

Solutions will be offered (They will be specific to simplify things but should be broaden to EVERYTHING in the project)

Binary size - Current version of gzdoom 3.7.2 x86_64 for NTFS is standing on 8.5MB, How on EARTH did the developers let such a thing happen?
With each extra byte , You are killing the chances of most parts to land in L3 cache, Let alone you are causing the processor to keep fetching data from system memory.
The issue is, You don't need to , Its due to bloatware of unneeded features.

Question : When people load the game or any mod, how much of a percentage of it is using normal map textures in the game and other EXTENDED functionality?
And yet the methods for using them as well as many other unneeded functionality gets loaded with each launch.

Solution - Modules and Dynamic run-time libraries loading, Put all the "Advanced rendering" methods in a different module to be loaded on runtime.
Multiple rendering options, software and hardware rendering, Again, use a NULL class for it and load on demand for each rendering method
the client chooses (The same way emulators do it, Right now, we have 2 rendering methods loaded in memory).
(This needs to be extended to EVERY optional (Non-core) functionality, By decoupling anything that isn't a part of the software core functionality.
(Changing to a decoupled module-based design will help other developers commit code in a more efficient way, by reduced dependency from the core software)

Bloated actors - Is there a reason as to why we have "Doubles" (IEEE 754 double-precision) for a game didn't support FPUs when it came out?
(You don't need such high resolution of calculations, let alone you won't have any "GAME CHANGING" round-off errors with single-precision floating point numbers.
L1 cache abuse (Double can be faster to COMPUTE based on the architecture but slower to fetch, due to cache line size)
How many cache lines does it take for a modern CPU to swap and mark dirty?
just to handle ONE ACTOR? consider how BIG each actor is (any kernel cache algorithm will be lost, by not knowing which part of the actor to cache).

Solution - Get rid of "Doubles", internally unite many member fields of the actor structure, Look for things to be rid of as well.
(This may cause issues with zscript so emulate the behavior of the fields removed)
(Unite member fields by bit-shiting many fields and using bitfields)
Example :"Score" and "Bounce-count" both 32-bit signed integer can be united into 1 integer named "Aux1" split into high-order and low-order.
(I doubt score and bounce-count will extend (2^16)-1 value. (This needs to be extended to all integer-type members of "Actor" class).

Shaders : OpenGL supports for a long time the ability to store compiled binary shaders as an external stream (file) on a storage device.
There is no need to recompile it on every load, However, You do want to add into the file the driver version, operating system version and GPU model in case of changes in the architecture on the client's machine.

https://www.khronos.org/registry/OpenGL ... binary.txt

Zscript : No need to recompile it on every-run, if ACS managed to store pre-compiled script programs, Zscript should as well.
(Let alone it can also improve performance, some operating systems store manifests of frequently used files in a temporary folder)

Zscript : The inability to over-extend the actor class itself without creating a class on top that inherits from it, Still suffers from limitation due
to the native function of an actor require actor classes and can not access extended classes.
Solution : Add 3 "Reserved" integers and floating point fields to the actors. ("Args" are already in-use)

Zscript : Actors need a hashed or serialized uID (unique ID), you can't access all actors by TID and doing a lookup is almost impossible
in the engine itself, you can access objects by pointers, actors require the equivalent unique ID for scripting access.

Future Edits :
* Removed the issue regarding GLSL lighting in vanilla game.
Thanks in advance.

[_mental_]

You will implement all these improvements, right?

[Rachael]

How on EARTH did the developers let such a thing happen?

Simple: We aren't prBoom. If you want a small "Doom" executable that's relatively static in features, that's probably the best one. And it has a very wide compatibility gamut compared to GZDoom, and is much closer to Doom the way it was originally designed, rather than GZDoom's goal of being Doom for modern systems.

That being said, many of the issues highlighted in this post are framed in such a serious way when I really don't consider them that major. But that's just my opinion.

You will implement all these improvements, right?

^^ Yes, this too. ^^

[phantombeta]

Bloated actors - Is there a reason as to why we have "Doubles" (IEEE 754 double-precision) for a game didn't support FPUs when it came out?
(You don't need such high resolution of calculations, let alone you won't have any "GAME CHANGING" round-off errors with single-precision floating point numbers.
L1 cache abuse (Double can be faster to COMPUTE based on the architecture but slower to fetch, due to cache line size)
How many cache lines does it take for a modern CPU to swap and mark dirty?
just to handle ONE ACTOR? consider how BIG each actor is (any kernel cache algorithm will be lost, by not knowing which part of the actor to cache).

I very much doubt this will happen.

Solution - Get rid of "Doubles", internally unite many member fields of the actor structure, Look for things to be rid of as well.
(This may cause issues with zscript so emulate the behavior of the fields removed)
(Unite member fields by bit-shiting many fields and using bitfields)
Example :"Score" and "Bounce-count" both 32-bit signed integer can be united into 1 integer named "Aux1" split into high-order and low-order.
(I doubt score and bounce-count will extend (2^16)-1 value. (This needs to be extended to all integer-type members of "Actor" class).

Cannot be done. It would break a fuckton of mods and require so much compatibility code that GZDoom would run a billion times slower.
It won't help, anyway. Even if you made the Actor class as small as possible, it'd still be too big to cache.
There's also the fact that merging completely unrelated fields like that is an absolutely awful coding practice.

Shaders : OpenGL supports for a long time the ability to store compiled binary shaders as an external stream (file) on a storage device.
There is no need to recompile it on every load, However, You do want to add into the file the driver version, operating system version and GPU model in case of changes in the architecture on the client's machine.

https://www.khronos.org/registry/OpenGL ... binary.txt

GZDoom already has built-in shader caching for drivers that don't have it built-in.

Zscript : No need to recompile it on every-run, if ACS managed to store pre-compiled script programs, Zscript should as well.
(Let alone it can also improve performance, some operating systems store manifests of frequently used files in a temporary folder)

The ZScript bytecode cannot be cached. It uses memory addresses directly everywhere.

Zscript : The inability to over-extend the actor class itself without creating a class on top that inherits from it, Still suffers from limitation due
to the native function of an actor require actor classes and can not access extended classes.
Solution : Add 3 "Reserved" integers and floating point fields to the actors. ("Args" are already in-use)

Something much better than such an awful solution is planned.

Zscript : Actors need a hashed or serialized uID (unique ID), you can't access all actors by TID and doing a lookup is almost impossible
in the engine itself, you can access objects by pointers, actors unique ID for scripting access.

How is this even useful?

[Matt]

We look forward to the.... "improvements".
(I accidentally forked GZDoom while trying to take this screenshot, it's that easy)

[Kinsie]

If ACS managed to store pre-compiled script programs, Zscript should as well.

If you make changes that allow people to distribute compiled ZScript without the source code (resulting in mods that can't be altered or fixed in the future), I will find your dog and I will hurt its feelings with barbed comments about its physical appearance. Just to be clear, I will give your dog a persecution complex if you make this happen.

[Rachael]

I'm closing this. It was humorous while it lasted.

About the doubles vs floats - doubles is better, especially with cross-architecture portability. ARM and Intel chipsets do not handle floats the same and this breaks determinism and would cause the two platforms to be incompatible.

And as phantom pointed out we already have a shader cache. The driver almost universally handles it on its own for non-Intel GPU's.

Also - about the size thing. GZDoom is nowhere near the monster a modern game is. Have you ever even seen Fallout 4? Christ. You're complaining about GZDoom's size? Give me a fucking break.

[Illasera]

Many of the suggestions made by me here are considered hacks, The reason for that is practicality, As i do not wish for breaking backward compatibility for existing modes.

My suggestions - resorting to some hack'ish practices.

There is a need to redesign much of the code but let's face facts, its not practical.
Fundamental errors were made at the core that can not be fixed but bypassed.

The intention was to prompt a debate and consider what can be done.

[
It won't help, anyway. Even if you made the Actor class as small as possible, it'd still be too big to cache.
There's also the fact that merging completely unrelated fields like that is an absolutely awful coding practice.

I wasn't implying for it be in ONE cache line but as little as possible, As far as margin unrelated fields as awful practice, I will have to agree but it got merits if done correctly.

[Rachael]

There is a need to redesign much of the code but let's face facts, its not practical.
Fundamental errors were made at the core that can not be fixed but bypassed.

That may be, but introducing more hacks is hardly a viable solution.

As has been suggested - if you feel like taking this on, do PR's, but do separate PR's for each point, and go point by point with it. But otherwise this feels more like a "LET ME TELL YOU HOW TO PROGRAM I AM BETTER THAN YOU AND I KNOW WHAT I AM TALKING ABOUT HURR HURR HURRRRRRRRRDKSHJGBHROHRJORERE GARBLE GARBLE" than it does actually offering helpful advice.

[leodoom85]

@illasera
Are you sure that resorting to hacks will make the engine better when the engine is already optimized and done correctly by fixing bugs and not adding hacks whatsoever?

[dpJudas]

Always cute to read pro tips from armchair developers.

[Graf Zahl]

How on EARTH did the developers let such a thing happen?

Simple: We aren't prBoom.

PrBoom is also 7.5 MB, all 21 DLLs included. Let's not forget that a lot of stuff that is in those DLLs in in GZDoom.exe, like the module replayer, multiple MIDI softsynths, the entire system backend and other stuff I'm too lazy to list. Oh, and let's not forget that 64 bit executables are roughly 15-20% larger because of all the unwinding metadata they need.

Always cute to read pro tips from armchair developers.

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

[leodoom85]

You know what Illasera?
Implement your solutions in an exe and give it to me. See if it runs better than the official build...

[Kinsie]

PrBoom is also 7.5 MB, all 21 DLLs included. Let's not forget that a lot of stuff that is in those DLLs in in GZDoom.exe, like the module replayer, multiple MIDI softsynths, the entire system backend and other stuff I'm too lazy to list. Oh, and let's not forget that 64 bit executables are roughly 15-20% larger because of all the unwinding metadata they need.

Could always be worse, too.

[YukiHerz]

lol