Welcome to the ZDoom Forums!

Math actually isn't a strong requirement for maintaining rendering backends unless you're writing a software renderer - most of the math is already done in the HWRenderer (which to avoid confusion, is the first renderer point in GZDoom before the actual GL/Vulkan commands - it was split in 4.0.0 ...

Because GZDoom doesn't know that a folder is supposed to be a loose collection of mods, also this has been argued to death with Graf and he's [No]'d it every time that I can recall. GZDoom treats the folder as a mod itself , so just throwing archives at it doesn't work because it thinks you're ...

The game loads the folder as if it were a .pk3 file, not as if it were supposed to load all the files contained within. So the same rules apply. You can't nest pk3 files, and thus you can't nest them in a folder in this case either. A workaround is to simply name them all .wad (GZDoom only seems to ...

This will eventually be a feature that can be modded in, and would be better if done that way. Eventually once ZScript named pipes/sockets are implemented it will be possible for scripts inside GZDoom to communicate with other processes in the system that can implement this. Then all you need is ...

Pi's have been running GZDoom since the 2nd generation at least, maybe even in the 1st gen. (That's more than 10 years ago) Frame rates are not exactly "fluid" per se, and a lot of it will depend on the native resolution of your desktop (pixel fill rate is a killer on mobile processors), but ...

It actually was deliberately addressed at some point. I can't remember if it was Boondorl or Phinet who sent the patch (I think it was Boondorl) but it was merged pretty quick after, I think it was just changing the order of one of the lines in the startup code.

The next version doesn't have anything planned at the moment, other than distance checks being portal-aware. I suppose I could push that if you really wanted, but otherwise I think outside of maintenance this mod is mostly complete.

Unfortunately, no. Every frame of the animations had to be manually added in and that meant explicitly defining what was there and using it. This mod has a bad track record of compatibility with other mods that affect floor fluid textures, and there isn't much that can be done about that until some ...

That is beyond the scope of this project, which in its current form is trying to be agnostic to any mods that may be loaded. In other words I want this to work even with Guncaster or Brutal Doom or Project Brutality or Russian Overkill or Hideous Destructor or pretty much anything else that you ...

For me, hard drive access was the biggest problem. Whenever large amounts of files needed to be read, performance completely tanked, as an example, a complete GZDoom compile, which on my Windows system back then took roughly 1.5 minutes, took 10 in the VM. A correctly set up VM should be somewhat ...

Not a GZDoom bug, this happens when certain types of mods are loaded. The mods must use the replacement behaviours correctly for map07/e1m8/e2m8/e3m8/e4m8 to function correctly.

Over time we may refactor the actor code and make it more simplified, and things like this can be considered again. If you are using ZScript, you can use a thing iterator and find the closest corpse to your enemy and just set the your_rezzing_enemy.goal to the corpse actor. As far as I know that ...

First of all - that site you linked should positively never be used to find replacement .dll files - much too often, that site, and many others like it, are used to spread malicious files that can compromise your system and steal your information. Second of all - wsock32.dll is a system component ...

This would require a rework of the AI systems to serve a purpose that would be better done with custom scripting anyhow. You can set monster goals or even use proxy actors to make your monsters move in the direction you want towards the corpses. The actor code is too bloated in its current state and ...