ZDoom

Darkcrafter wrote:As you said before it's because a doom map must contain one-sided linedefs to leave redundand things behind and cut them from the rendering pipeline. The maps I play have almost zero one-sides and heaps of 3d floors and they naturally don't block anything.

"Doctor, it hurts when I do this."

phantombeta wrote:Brutal Doom and Project Brutality are terribly coded and horribly unoptimized, so that's not surprising at all.
Here's a thing to think about: Doom ticks at 35 Hz. Most modern games tick at far less than that. The more often you tick the game and update the actors, doors, lifts, etc., the less time you have to render frames. That's already one issue right there.

Doom's level geometry is also highly dynamic. Every sector can move up and down in it. The reason Quake is so much faster is because the actual level geometry is *completely static*.

While that is certainly true, one should never forget that Quake's original levels are also rather small. If you factor out the lightmaps they look really, really bland.
But as things stand, preparing Quake's geometry for being rendered is a lot less complex than Doom's. It's not just that the geometry is dynamic. Another issue is that textures can basically change at random. In Quake even a switch is an entity so even considering texture animations you normally know up-front if parts of the level mesh may change. There's no chance to do this with Doom, especially when scripting needs to be considered.

All things considered, Doom is probably one of the most GPU-hostile games that ever got a hardware accelerated renderer because none of 1993's design concepts translate well.

Graf Zahl wrote: All things considered, Doom is probably one of the most GPU-hostile games that ever got a hardware accelerated renderer because none of 1993's design concepts translate well.

It would be very interesting to know a bit more about this, i suspected something was up when the software renderer gave me +45 fps in nuts while hardware only managed around 12 fps and even worse, i have also noticed the same thing using project brutality and brutal doom mods when i rendering actors and since it "went away" when using software rendering or at least was 4-6 times faster 5-12(open gl) vs 45-65(software) fps, what could be done to improve this, i assume vulkan could only do so much unless you could "fix" the sprite rendering issue i read about here.

I hope we get a "ray tracing" version when it become more mainstream, im not sure how software is so different from gpu rendering but i understand that doom lacks the proper "3d" to utilize modern hardware as i understand it (ie polygons and such) im guessing a better renderer could be made but that would brake mod and backwards compability.

The hardware renderer shouldn't be that slow, unless you got a low level graphics card.
The one exception to this is dynamic lights. On Nuts, having lights active can easily kill all performance. Normally, Nuts runs faster for me with hardware rendering than with software rendering.

Graf Zahl wrote:The hardware renderer shouldn't be that slow, unless you got a low level graphics card.
The one exception to this is dynamic lights. On Nuts, having lights active can easily kill all performance. Normally, Nuts runs faster for me with hardware rendering than with software rendering.

Not only nuts but other maps iv made and tried playing with brutal doom derivatives are also very slow with hardware on all 3 of my computers.
My best Best GPU is a Radeon r9 280x, the newest a Geforce 960 4GB and the laptop uses a Geforce 850 Mobile.

I had all types of lights disabled and everything else demanding or advanced disabled too.

Graf Zahl wrote:That's not 3D. That's just two planes.

A little bit late answer, but...
Originally I thought that lights works in a way like "check if squared distance from light actor to sector vertexes greater than squared light radius; if yes, light sector in some radius around self; if no, check what lines it meet and then check if this line one sided or no" and then iterate over all neighbor sectors until first condition, that with squared distance, does not return true.
But look like lights use BSP data from renderer to determine what it can light. And since it have map data only in XY plane format, my suggestion would wont work.

Darkcrafter wrote:...I'm sorry, but should I indeed get GTX 1080 to play THIS?...

No, you should get I7 8800. GZDoom with Brutal Doom becomes CPU-heavy, not GPU-heavy.

axredneck wrote:

Darkcrafter wrote:...I'm sorry, but should I indeed get GTX 1080 to play THIS?...

No, you should get I7 8800. GZDoom with Brutal Doom becomes CPU-heavy, not GPU-heavy.

True in general but not when it comes to sprite rendering unless Open GL rendering gives the CPU 4 times more work compared to software rendering when it comes to sprites so the CPU needs to work overtime to convert game data for the GPU in realtime due to how the engine works.

Can anyone confirm this?

Elias79 wrote:

axredneck wrote:

Darkcrafter wrote:...I'm sorry, but should I indeed get GTX 1080 to play THIS?...

No, you should get I7 8800. GZDoom with Brutal Doom becomes CPU-heavy, not GPU-heavy.

True in general but not when it comes to sprite rendering unless Open GL rendering gives the CPU 4 times more work compared to software rendering when it comes to sprites so the CPU needs to work overtime to convert game data for the GPU in realtime due to how the engine works.

Can anyone confirm this?

Nope. Slowness with mods like Brutal Doom has nothing to do with rendering, it's because those mods have to use actors for effects like gore and casings, and actors are extremely expensive. For example, the time taken by the sector-relinking code alone very likely far outweighs the time taken up by rendering all the sprites in the map. Remember, GPUs are made to draw millions of polygons.
GZDoom is CPU-bottlenecked by things like the sector relinking code and the BSP. Unless you enable things like shadowmaps, or have thousands of dynamic lights at once, the GPU barely does anything while the CPU does a ton of work.

phantombeta wrote: Nope. Slowness with mods like Brutal Doom has nothing to do with rendering, it's because those mods have to use actors for effects like gore and casings, and actors are extremely expensive. For example, the time taken by the sector-relinking code alone very likely far outweighs the time taken up by rendering all the sprites in the map. Remember, GPUs are made to draw millions of polygons.
GZDoom is CPU-bottlenecked by things like the sector relinking code and the BSP. Unless you enable things like shadowmaps, or have thousands of dynamic lights at once, the GPU barely does anything while the CPU does a ton of work.

Well if this is true, why did someone say that the Open Gl renderer is very very inefficient compared to the software renderer and when i have tested brutal doom etc on a self made map and got more than double the fps in software mode compared to hardware, and while you may be right
to 99% even if the GPU was nearly unused i wrote that the CPU had to work MORE when using the GPU due to having to convert data and prepare it for the GPU, if i misunderstood then please correct me but i know from my own test that software always is faster using some mods, my assumtion is the CPU overhead using the hardware mode as the GPU can't handle doom raw data.

TLDR: Open GL creates more work for CPU

Elias79 wrote:Well if this is true, why did someone say that the Open Gl renderer is very very inefficient compared to the software renderer and when i have tested brutal doom etc on a self made map and got more than double the fps in software mode compared to hardware, and while you may be right
to 99% even if the GPU was nearly unused i wrote that the CPU had to work MORE when using the GPU due to having to convert data and prepare it for the GPU?

TLDR: Open GL creates more work for CPU

In other words: "La la la, you're stupid, I can't hear you because I'm always right even though I know absolutely nothing about programming!"



Good show.

Rachael wrote:I can't hear you because I'm always right even though I know absolutely nothing about programming!"

I never claimed i did, and i never claimed i was right either, why are you attacking me? i just NEED a explanation for my results.

EDIT: I apologize if this was the incorrect place for this discussion, i just want to understand things better.

Like most performance things the truth is complicated. For vanilla/boom style maps the typical bottleneck is the CPU where generating the data for the GPU is more expensive than what the GPU does.

For GZDoom mods it gets a lot more complicated. Some mods suffer from inefficient scripting (CPU work), some from too many dynamic lights (GPU work), excessive amounts of particles, decals and sprites (both CPU and GPU).

On my computer I haven't seen the software renderer ever beat the GPU (my GPU is always very high end). But perhaps on sufficiently low end GPU's it might. On this MacBook Pro (2014 model with Intel GPU) the hardware accelerated version clearly does not like dynamic lights one bit. I haven't compared it to the software renderer's dynlights, but its plausible it could outperform it.

Elias79 wrote:i just NEED a explanation for my results.

EDIT: I apologize if this was the incorrect place for this discussion, i just want to understand things better.

OpenGL is entirely single-threaded and chances are you're using an AMD GPU which is known to handle this quite horribly. All the draw calls on an AMD happen in sequence with the BSP walking and culling and other setup that GZDoom does, which causes a frame cycle to take quite a bit longer with OpenGL, especially with more complex maps, especially with scenes that have a ton of sprites in them.

This is made worse by the fact that no geometry in GZDoom is static - both the fact that sectors can move up and down, as well as the possibility of polyobjects, makes it so that GZDoom has to regenerate the geometry every single frame - which adds to this mess.

NVidia handles this a little more gracefully by executing a completely separate thread for all this fuckery, so that GZDoom can set up the next frame in tandem while NVidia/drivers/GPU execute the current one.

Thanks very much just the type of info i needed, and yes my best gaming PC uses a r9 280x AMD GPU, while the others a mobile Nvidia Geforce 850m and my older rig a Nvidia Geforce Gtx 960, the mobile GPU is also slower tho.