[Wolfenstein: Blade of Agony] v3.1 released (p204)

[Tormentor667]

Will this ever be configured for support for Zandro 3.0 Dev Builds?

This solely depends on the programmers of Zandro 3.0 and if they implement all the new features available in latest GZDoom builds.

[Graf Zahl]

Thanks for making gzdoom 2.2 branch OpenGL 2.1 compatible, I have gained few fps on my old machine (I posted in this thread several months ago, see there for details).

BTW, I think that gzdoom has the same problem with rendering as zandronum - see https://zandronum.com/tracker/view.php?id=1541 and run gzdoom.exe treetest.pk3. Observe that if you look in the direction of the wall which is lower than the other three then the performance drops (use "vid_fps true" in the console to see the framerate).

Sorry for hijacking this thread, but is this problem still as pronounced in more recent 2.x builds? I can see a drop in frame rate on my system, but it's from 550 fps to 370 fps with both values obviously posing no problem at all.
One of the major changes in 2.x is how models are being rendered, using a vertex buffer for all static models and using a significantly more streamlined method to process interpolation.

[drako]

Thanks for making gzdoom 2.2 branch OpenGL 2.1 compatible, I have gained few fps on my old machine (I posted in this thread several months ago, see there for details).

BTW, I think that gzdoom has the same problem with rendering as zandronum - see https://zandronum.com/tracker/view.php?id=1541 and run gzdoom.exe treetest.pk3. Observe that if you look in the direction of the wall which is lower than the other three then the performance drops (use "vid_fps true" in the console to see the framerate).

Sorry for hijacking this thread, but is this problem still as pronounced in more recent 2.x builds? I can see a drop in frame rate on my system, but it's from 550 fps to 370 fps with both values obviously posing no problem at all.
One of the major changes in 2.x is how models are being rendered, using a vertex buffer for all static models and using a significantly more streamlined method to process interpolation.

Thanks for your reply. I use the newest build 2.2pre 1799 x32 from Jul 09. On the treetest I get drop from 52 to 8 fps

---

treetest 8fps

treetest 52fps

.

In BoA I get 7 fps in c1m2 at the same location I tested several moths ago and described in this thread

---

c1m2 7fps

. When I rotate 90 degrees to the right I get 21 fps.

[Graf Zahl]

I looked up your specs in an older post. It is obvious that using vertex buffers is not really helping performance here, it looks like the driver emulates them in software because the hardware has no support for them. This is a well known problem with older Intel hardware - the actual hardware is close to feature-less, it's all done in the driver. But when it comes to a feature like using vertex buffers for high-polygon items like models that kind of approach will inevitably break down completely.
On modern hardware with true buffer support, rendering a detailed model is no more expensive than rendering a sprite. On the CPU side it is one draw call and overall GZDoom is so much CPU bottlenecked that there is enough time to send all those vertices through the vertex shader without stalling everything.

The reason for this handling of hidden actors is that Doom's visibility clipping is done in 2D so there is no way the trees in the hidden sector can be easily discarded. To be more precise, if some part of the sector can be seen, all sprites in it will be processed - 'seen' is to be considered in a 2D context here.

[Ozymandias81]

@drako
Did you ever tried the GitHub version of BoA?
I added several options in order to scale the distance of rendered things, like grass, 3d scenery and 3d trees specially.
There are also more options too.

[Mav3rick]

using version 1799 on map c1m2 *line 3029's right edge is unconnected* and *line 3050's right edge is unconnected*

[drako]

I looked up your specs in an older post. It is obvious that using vertex buffers is not really helping performance here, it looks like the driver emulates them in software because the hardware has no support for them. This is a well known problem with older Intel hardware - the actual hardware is close to feature-less, it's all done in the driver. But when it comes to a feature like using vertex buffers for high-polygon items like models that kind of approach will inevitably break down completely.
On modern hardware with true buffer support, rendering a detailed model is no more expensive than rendering a sprite. On the CPU side it is one draw call and overall GZDoom is so much CPU bottlenecked that there is enough time to send all those vertices through the vertex shader without stalling everything.

The reason for this handling of hidden actors is that Doom's visibility clipping is done in 2D so there is no way the trees in the hidden sector can be easily discarded. To be more precise, if some part of the sector can be seen, all sprites in it will be processed - 'seen' is to be considered in a 2D context here.

Thanks Graf for your explanation. It seems to me that indeed it may be a CPU problem. I have observed that the fps is sometimes unstable, that is it jumps to higher for few seconds and then it comes back to low. I discovered that the CPU priority for the gzdoom.exe process is set to low (I use the last build 1814). When I change it to high using the task manager, after switching to gzdoom and then switching back, the task manager shows that gzdoom.exe process has again low priority.
Does the gzdoom.exe changes its priority to low all the time? Is it possible to enforce gzdoom.exe to run on high priority?
That is probably a long shot, but is it possible to make gzdoom multithreaded ? My CPU has two cores so that could improve the performance.

@drako
Did you ever tried the GitHub version of BoA?
I added several options in order to scale the distance of rendered things, like grass, 3d scenery and 3d trees specially.
There are also more options too.

Thanks for letting me know about that. I downloaded the version from GitHub and it set all the options to minimum. However, it seems that this did not help (at least in the location which I test in c1m2. I did not have time to look at other maps/locations).

[Ozymandias81]

using version 1799 on map c1m2 *line 3029's right edge is unconnected* and *line 3050's right edge is unconnected*

Don't worry we know that... It's just a sector that needs to be closed and which is still WIP.

[Graf Zahl]

That is probably a long shot, but is it possible to make gzdoom multithreaded ? My CPU has two cores so that could improve the performance.

It's not easy. But let's not forget that the sound mixing thread and the graphics driver thread already use up almost an entire code, so even it I managed to make something that actually works, you wouldn't benefit much.

And your main bottleneck is not the CPU it's the underpowered integrated graphics chip you have.

[Tormentor667]

How much of the GPU can GZDoom use anyway in relation to the CPU?

[Wiw]

Not enough, it feels like.

[drako]

Ok, I tested the newest build (1846 Jul 19) and I see some improvement. At "the door location in c1m2"(described by me in previous posts) I get fps jumping between 9 and 21 when enemies are behind the door and between 20 and 51 when all the enemies behind the door are killed (I think there are about 10 enemies). I also observed that when the number of enemies is 5 or more then the fps drops.

If it goes about the treetest.pk3 now I have 18 fps stable when I look in the direction of trees and fps jumping between 100 and 550 when I look in the opposite direction.

[Ozymandias81]

Ok, I tested the newest build (1846 Jul 19) and I see some improvement. At "the door location in c1m2"(described by me in previous posts) I get fps jumping between 9 and 21 when enemies are behind the door and between 20 and 51 when all the enemies behind the door are killed (I think there are about 10 enemies). I also observed that when the number of enemies is 5 or more then the fps drops.

If it goes about the treetest.pk3 now I have 18 fps stable when I look in the direction of trees and fps jumping between 100 and 550 when I look in the opposite direction.

Sorry to sound a bit stupid, but I don't recall your PC specs... can you post there the complete list? I remember you did it before but it seems I can't find anymore that reply, so...

[drako]

My specs: HP G60 Notebook PC: Pentium Dual Core CPU T4300 @ 2.1, GHz 4 GB RAM, Mobile Intel 4 Series Express Series Chipset Family (supports OpenGL 2.1).

[Ozymandias81]

So this one, right? Uhm, those aren't exactly high specs...