Instalar Steam
iniciar sesión
|
idioma
简体中文 (chino simplificado)
繁體中文 (chino tradicional)
日本語 (japonés)
한국어 (coreano)
ไทย (tailandés)
Български (búlgaro)
Čeština (checo)
Dansk (danés)
Deutsch (alemán)
English (inglés)
Español de Hispanoamérica
Ελληνικά (griego)
Français (francés)
Italiano
Bahasa Indonesia (indonesio)
Magyar (húngaro)
Nederlands (holandés)
Norsk (noruego)
Polski (polaco)
Português (Portugués de Portugal)
Português-Brasil (portugués de Brasil)
Română (rumano)
Русский (ruso)
Suomi (finés)
Svenska (sueco)
Türkçe (turco)
Tiếng Việt (vietnamita)
Українська (ucraniano)
Comunicar un error de traducción
El autor de este tema ha marcado un mensaje como la respuesta a su pregunta.
Normas y directrices sobre discusión
7 
Denunciar este mensaje
Specs:
RTX 2060 6 gb
I5 8600
16 GB of RAM
2 SSD's (one is a sata and the other is m.2 which is what the game is installed on)
Windows 11.
So what do you mean by the game tanking? What fps?
The only way to fix this would be to recode the engine's way maps are rendered in a modern method. Which could cause compatibility issues? Maybe not if it was converted on the fly, but that would increase loading times. IDK why it's never been attempted, but clearly there are legit reasons which would require a complete engine rewrite.
Multithreading would help if it was possible to multithread the engine. It's just not coded for it. That said, perhaps it's possible to Temple OS style optimize, where you use multi cores to compute a single task. But most programmers aren't Terry Davis, and that's what it would require.
If you use a port like LZDoom, it has forced culling distance options, but this literally removes map distance in a circle. You know how Turok on N64 had "fog", which was really distance culling? That's what this does without having the "fog". This ruins the viewing distance in large maps, maybe even the monster AI. LZDoom also isn't compatible with new GZDoom scripting, being based on older code. It's not always better, just for certain use cases. GZDoom is generally better and faster aside from the cases LZ can "fix".
Mods like Brutal Doom have features like "garbage collection" that delete bodies and debris from the map, which can boost FPS at the expense of visuals, because it's deleting things that need calculating. This is one of the performance hacks I've seen, but it's not a default supported option for most mods.
Large maps like Elementalism also play bad due to the same limitations. I've seen some videos of popular doom content creators getting similar low FPS in their play throughs. You can also bottleneck the engine with monsters, like with the NUTS map.
There is no "fix" anyone experiencing issues can do, aside from overclocking, CPU upgrade, and Vulkan, because vulkan eliminates the CPU overhead of OpenGL.
Maybe if you're a doom mod programmer, you could find all the different performance hacks and mod them into the game, but nobody's gonna do that, and there are visual / gameplay side effects.
Not everything here is entirely correct. Another project I am involved with has a number of GZDoom engine tweaks to aid with performance.
One approached that gave us a lot of additional mileage out of the engine, was to introduce a "sleep" function for actors. This basically means that all actors are completely ignored from the games Tick system if the player is a few units away from an actor. This nearly doubled our performance and basically allows ridiculous amounts of actors to be spawned in a level without too much of a hit. We hope this change will eventually find it's way to stock GZDoom. IIRC, someone is working on it right now. But I cannot confirm.
Multi-threaded asset loading has also been implemented which allows different threads to load assets, removing a lot of stress from the main thread that handles the engine logic. This eliminates the stuttering. Or well, most of them! This will also find it's way into base GZDoom in the future.
There's a lot to optimize in GZDoom. Especially once you learn how to abuse Zscript (something the aforementioned Brutal Doom unfortunatly does not use).
The engine has flaws. A lot of them. But I think the future is bright as far as optimizations are concerned. We're doing our best at least.
No, you can choose to never sleep monsters. If you use the function for decorations, pickups, corpses and such you can save a ton of juice in medium-large levels. Actors usually always do stuff in the background, even if their only reason of existing is to just sit there and do nothing, it's a waste of precious resources!
The sleep function you mention is one of these manual optimization techniques. It's not something default in GZDoom. There's also a LOD (level of Detail) hack that can turn complex decorations into simple decorations at a distance. This is almost a complete necessity for Voxel graphics in big mods, but nobody does this afaik, and adding voxels with no LOD to modern big maps will crawl the engine to single digit performance. Preloading assets is a common enough optimization, and is occasionally used in mods with heavy animation, but definitely not very many. Preloading does not help FPS, it helps reduce stuttering. I am glad to hear this may become part of base GZDoom, as it should have been a default years ago. GZDoom has not always been optimization friendly, as they even REMOVED texture compression support that existed in older builds. There could have been issues with it, but that feature helps low VRAM hardware run HD graphics. Someone needs to tell them to bring it back, especially for Nvidia cards. Maybe they're secretly using a global method now with no indicator, but afaik it's been uncompressed since the removal. Probably the switch from OpenGL to Vulkan.
The Voxel issue is especially bad with CPU use, as I was playing a big map with horrible performance and didn't initially know why. It didn't help that the videocard went into powersaving mode and downclocked itself to like 500Mhz, so I thought it was a graphics driver bug. No, the videocard was just saving power because it had literally no work to do from an Engine CPU bottleneck, and disabling voxels fixed the performance.
You can hack a lot of different things to save CPU cycles, but ultimately it's not capable of fully utilizing even 4 cores for performance, especially with Map/Level Geometry. The doom engine was not designed for high geometry, room over room, curved surfaces, swimmable water, surface marks, etc. GZDoom just hacks graphics over top the old engine with zero render optimizations like geometry culling / hidden surface removal. You're computing the full map 100% of the time. Modders pick a base performance level, and everyone under it is screwed. Sleeping the AI only helps compute the AI, which provides some headroom, but it doesn't fix map computation.
IDK if people remember the Nvidia Tessellation controversy, where sponsored games would tessellate flat objects and water under the map surface to ruin AMD performance, but this is sort of how GZDoom computes big maps, and there is no magic driver hack to fix it, because it's engine limited from the old render method. It's not addressable at the modder/user level, only GZDoom source itself.
So far the only modder hack afaik is making less detailed maps or smaller maps that load in chunks / hub system. It's not sustainable long term, so I hope public pressure motivates the developers to address it. it's mostly been a mindset of "you're doing it wrong", but literally everyone is "doing it wrong" at this point now, which isn't going to change, so the only way GZDoom can sustain the modding community is to fix map performance. Otherwise, it's going to be a non-stop complaint festival from everyone who doesn't understand why the mods run so bad. Perhaps it'll get bad enough that someone will fork the engine or join the existing team to do it directly. All I know is that it's a complex issue that would require changing how the existing engine fundamentally works, so this is why it hasn't been done so far.
It would be great to see progress in GZD's optimization because it can be annoying when a wad chugs. Like I was replaying Skillsaw's Ancient Aliens a while back and it was weird to see how some maps can dip the fps. AA is a good looking wad but it's not exactly this crazy detailed thing so it's weird how handling even that can be a bit of a problem for the engine sometimes.
On the other hand I like Supplice's clean and somewhat sterile looking maps, they remind me of Back to Saturn X and that's always a plus. I just hope there won't be an enemy with the archvile's mechanics because Back to Saturn X sure as hell had some archvile placements that were just cruel. :D I'm like 90% sure that there will be an archvile type enemy though... god have mercy on our souls.
I remember Selaco went under some engine enhancements and is now multithreaded. I'm currently playing the demo. Is the full game any better? I'm still gonna buy anyways. I just simply like it
The biggest thing that affects gzdoom performance is getting an AMD X3D CPU, the extra cache does wonders for FPS. My test spot on E2M3 went from 75~ on a 13600k to 130 on a 9800x3d.
That's not how it works! You can't load it barebones in a different engine and expect to see results right away. That is not the kind of changes we've made.
In our version, actors are practically free. Benefitting from any of these would require migrating every single actor to our approach, and that process will take long when it's not done from the start of development. We added it late, and it took weeks until we converted everything lol
If a Supplice level is heavy on actors (pickups, enemies, decorations etc), the benefits would be very noticeable after the migration.
Unfortunately Supplice modding (which is another person and I) is put into a kind of awkward spot because of a performance regression introduced in 4.12.2 to 4.13. Some sort of culling viewport stuff that I dont understand, but the result being that FPS that used to recover when not looking at these sort of scenes does not when looking away.
I'm extrapolating here but if I was the Supplice dev team, and I had to pick between versions of GZDoom that had security vulnerabilities and ones that can have 100-800% better performance in certain scenes, my answer would be learn to read Zscript if you want to run a mod and trust it.
My point being is I can see why having your own fork for a commercial project is very valuable. I hope I'm not being obtuse and I always appreciate the information Nexxtic