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

Large grid of building placements lags #1472

Open
jacobguenther opened this issue Apr 26, 2024 · 2 comments
Open

Large grid of building placements lags #1472

jacobguenther opened this issue Apr 26, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@jacobguenther
Copy link

There is already a BAR issue for this but I believe it is an engine optimization problem. When you use shift+alt to make a large grid of buildings the game goes to 1fps.

@jacobguenther jacobguenther added the bug Something isn't working label Apr 26, 2024
@jacobguenther
Copy link
Author

jacobguenther commented Apr 30, 2024

By commenting out various parts of drawMapStuff I found that unitDrawer->ShowUnitBuildSquare is the slowest part. Perhaps a new function ShowUnitBuildSquares could be introduced which takes a vector of buildInfos and draws all of them at once. Even A naive approach could be beneficial.

  • We wouldn't have to change shaders as often.
  • We would only have to set gl_depth_test, blend, etc once
  • We could use the render buffer to draw them in fewer draw calls

I'm not sure what facilities the engine has for instanced rendering but with instanced rendering we could reduce the amount of processing on the cpu and data that we send. Instead of calculating each vertex for each square on the cpu that could be done gpu side. We could send just the quad for a square and as instance data a offset(vec3) and type(int) which can be mapped to a color.

@jacobguenther
Copy link
Author

jacobguenther commented Apr 30, 2024

I also found some redundant or unused things.

unitDrawer->ShowUnitBuildSquare is used in an if else statement where each branch has glcolor4f(...) but glcolor4f wouldn't do anything there.

buildColors gets cleared and reserved but isn't used for anything.

The constructor for BuildInfo makes sure buildFacing is valid by using the % operator. In FillRowOfBuildPos the % is used again to make sure buildFacing is valid. I think a copy constructor for BuildInfo could be added that doesn't check buildFacing.

In GetBuildPositions buildInfos gets clear() and reserve(16) called on it and then we find the max size it could be with xnum and znum. There is also a comment // circle build around building. I haven't seen that in a game.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant