Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sort of a bug/feature... wondering if anything can be done to help the bottlenecks in mods like Blade of Agony featuring large open areas #1476

Closed
1 task done
RichardEllicott opened this issue Oct 2, 2021 · 4 comments
Labels

Comments

@RichardEllicott
Copy link

RichardEllicott commented Oct 2, 2021

GZDoom version

BOA stand alone (4.6.0)

Which game are you running with GZDoom?

Other

What Operating System are you using?

Windows 10

If Other OS, please describe

No response

Relevant hardware info

AMD Ryzen 7 3750H 2.30 GHz + GeForce GTX 1660Ti (mobile)

Have you checked that no other similar issue already exists?

  • I have searched and not found similar issues.

A clear and concise description of what the bug is.

This is between a bug and a feature

I get pretty bad performance issues with Blade of Agony despite having just upgraded my machines. I get the impression it's to do with the culling, that clearly works just fine in tunnel sections but really struggles in large open areas, like "C1M3 Operation Overlord" for example being the first major one..... C2M3 later having an outdoor farm and buildings etc

I was wondering if anyone was engineering on this.... is it not that the Doom occlusion system (the BSP tree system that calculates what sectors are visible) is breaking down with all this insane detail?.... that if the GzDoom engine could be forced to just draw everything (a distance based occlusion)... it might actually work better for this type of game

i'm also a coder so i was looking for something interesting to look at, i enjoyed seeing all the amazing work in this mod and i felt that maybe it's a slight injustice if more people can't experience it, especially if they have a slow machine

thanks, anyway, please direct me to somewhere else if need be

Steps to reproduce the behaviour.

Simply playing a map designed like C1M3 C2M3

Your configuration

No response

Provide a Log

No response

@coelckers
Copy link
Member

The "bottleneck" here is a mod that refused to take the necessary optimization to get better performance. There's little that can be done in the engine here,, unfortunately.

@RichardEllicott
Copy link
Author

RichardEllicott commented Oct 11, 2021

The "bottleneck" here is a mod that refused to take the necessary optimization to get better performance. There's little that can be done in the engine here,, unfortunately.

what steps do you believe the mod team could have taken then to avoid these problems?

all i can see at the moment, is the levels are too big. since people like big levels... i can only see that addressable with GZDoom itself.

GzDoom is dissapointing as it should perform great, in many ways it does for older style content, however as it had increased in popularity, seems you'll simply have more and more people making mods that don't work decent on anything that can't just brute force the issue with a super fast clock speed

i thought well you might want to look at that, but i do understand the codebase is likely so large and fragmented that not a great deal of people actually know how it works

@Gaerzi
Copy link
Collaborator

Gaerzi commented Oct 14, 2021

Basically the BSP system used by Doom since 1993 allows to very quickly and efficiently find which areas should be rendered and which ones shouldn't. The problem with wide open levels is that the category "which areas should be rendered" becomes "all of them".

Doom is not a good engine for large open worlds. It doesn't have any of the tricks that engines written for large open worlds have, such as simplified LODs (BOA tries to implement this, but it's done through actor code so it adds a lot of overhead) or having a distance cutoff for rendering, or using a dynamic cell system, or so on. Those BOA maps that give poor performances are kind of like a worst-case scenario for the engine.

@RichardEllicott
Copy link
Author

RichardEllicott commented Oct 15, 2021

yeah that was the sort of thing i thought was the case

based on my experience however with 3D engines though i actually would guess no LOD would not be much of a problem here.... most things in BOA are not really that detailed

what could be done perhaps is someone could skip the BSP system entirely, use an octree (i feel this is the easiest to code) or other method to create a distance based rendering (need a way of finding the nearest polygons).

I don't think actually that this approach would be a problem with such a low poly game as BOA.... i guess i have no personal experience with the GZDoom code i just wanted to see if that's the sort of thing someone whos worked on it might think is possible

i mean i'm not trying to actually preassure anyone cos i have far too much of my own coding to do anyway so i get like, yeah i could do it myself .... it started to strike me as ironic how the old bsp system is being pushed and it's now a detriment... you see actually people now like to draw lots of sectors also, whereas in the old days a sector would more-or-less represent a room without too many smaller details. That must have increased the sector count dramaticly

Thanks anyway

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants