ZDoom

This particular case has nothing to do with GZDoom. If you pass 10000 different draw calls to OpenGL it will just take longer. The actual C code is only a small part of the issue, most waiting is spent waiting for the driver/GPU to finish all the drawing.

For sprites this is particularly bad. They need more setup on the CPU side and there's very little the driver can do to optimize because so much render state is changing each frame.

Why don't you see this in PrBoom? Well, simple: There are no mods like Brutal Doom for it which do this kind of sprite overkill. You got to draw several 1000 of sprites and at the same time change some specific state values to see the slowdown.

I know we've heard this discussion before, but again, why does GZDoom have trouble with this kind of thing when something like PrBoom can run intensive maps with tons of sprites without hiccup?

[quote="babul"]
Honestly, one should *not* run mods like Brutal Doom with maps counting over 4 thousand monsters[/quote]

Correct. That won't mix well.

Thanks for explaining this.

Out of curiosity, I tried launching Project Brutality on that map.. after firing two rockets, I instantly got super low FPS (over 15k sprites).

Good spot seems to be around 1000 sprites, to mantain 60 fps (I'm getting around 90 fps with ~500 sprites). There's no setting to prevent new sprites from spawning, if they exceed X amount, is there? Would be nice if possible.

Honestly, one should *not* run mods like Brutal Doom with maps counting over 4 thousand monsters, so it's my bad.. but then, I don't see much reason to use 64 bit version, if it basically behaves the same as 32bit under high load. I will still stick to it though.

Thanks again for your time and help :)

14000 sprites? Yes, that alone explains why it gets slow. This is a nightmare scenario for the graphics driver which needs to feed the GPU with rapidly changing render state.
Not only does this block the main game thread (which is why that core is only partially utilized) but it also creates frequent stalls between the GPU feeding thread and the GPU itself because they may often have to wait for each other.

This is probably the single worst use case for modern GPUs.

Oh, also this screenshot I just linked was made using latest dev version (gzdoom-x64-g3.3pre-39-g2f45218), if that helps. Thought it might change something, but game behaves exactly the same as with stable version.

(Not sure why my posts are still needing mod approval, would edit the previous one instead).

[url]https://i.imgur.com/kSVKdFb.png[/url] - here you go, thanks for taking your time to look at it.

Hm. I was more expecting an AMD card with those characteristics.

Can you go to the same scene and enter 'stat rendertimes' and 'stat renderstats' and make another screenshot? That gives more information about where the engine spends its time.

Intel Core i7-7700K
MSI GTX 1070 Gaming X (8 GB);
16 GB RAM (DDR4);
Windows 10 Pro;

What's your hardware specs?

Hey guys,

Wanted to test my new rig with Chillax + Brutal doom.

I started with Zandronum, but got bad fps on bigger maps, so I figured I should use 64 bit source port. Installed Gzdoom 3.2.1 64 bit, but still it seems that my resources aren't being used fully.

[url]https://i.imgur.com/A1yvEyx.png[/url] - here you can see the results. Both my GPU and CPU are having low % usage (note that the numbers in the corner is *total* usage, not only Gzdoom usage; CPU5 seems to be most strained during gameplay, it never goes above 80% though).

I already tried gl_renderbuffers=false, it improved things only very slightly in that particular case.

Any suggestions? It really feels like resources usage is being limited by something.

Thanks in advance!