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

Improve Performance of Debug Drawing #3164

Open
Geokureli opened this issue Jun 4, 2024 · 8 comments · May be fixed by #3168
Open

Improve Performance of Debug Drawing #3164

Geokureli opened this issue Jun 4, 2024 · 8 comments · May be fixed by #3168

Comments

@Geokureli
Copy link
Member

Using an OpenFL graphic to draw bounding boxes causes terrible performance, what if we have a secret debug camera that draws everything, instead?

Note: This will introduce major breaking changes to nearly everything, and should probably be done in tandem with this change: #2715

@Cheemsandfriends
Copy link
Contributor

This is due to the lines in OpenFL being CPU wise causes REALLY shitty perfomance, it's not even funny
it doesn't help if your sprite is really big, but I don't think it should break anything? just have a 1x1 white square, colorTransform it to whatever and adjust it

@Geokureli
Copy link
Member Author

Geokureli commented Jun 4, 2024

it's a major breaking change because every class has debug draw functions that take a openfl.display.Graphic instance, and we're gonna gut those out. also any custom debug draw logic that draws to gfx is gonna break

@Cheemsandfriends
Copy link
Contributor

Why? Why would you do any of that?
the only reason why it breaks is because of a badly ported Graphics rendering where the rectangle is being rendered as a rectangle has a linestyle outline, making the thing switch to CPU, making it perform like absolute shit (see this line)

You're convoluting and trying to make a whole ass system that could be fixed with 4 simple commands
FlxCamera.debugLayer has no fault at all, it's just OpenFL fucking up. one solution would be fixing that for the GPU rendering of the graphics, and another is just this workaround

@Geokureli
Copy link
Member Author

I don't understand what you're suggesting

@Cheemsandfriends Cheemsandfriends linked a pull request Jun 5, 2024 that will close this issue
@Cheemsandfriends
Copy link
Contributor

Just 4 commands of drawing a rectangle with a color, it's simple as that lmao

@ninjamuffin99
Copy link
Member

I think for this we can definitely poke into Austin East's graphics work that he had in a branch from a while ago

https://github.com/AustinEast/flixel/tree/dev

of course, it was not entirely finished, and might have some old incompatible code, but I think it might be a decent move towards some more broad rendering overhauls #2915

@ninjamuffin99
Copy link
Member

one in particular might be the FlxDraw class, dev...AustinEast:flixel:dev#diff-316245ef29780b5a5d892c4299aea8f089710d05158e733574d543f599ce4dbd

which extends FlxStrip, which uses GPU drawing. However of course, more changes here would be some FlxStrip changes, along with general broad rendering changes. Food for thought since on the topic of rendering

@Geokureli
Copy link
Member Author

Geokureli commented Jun 15, 2024

I keep getting conflicting accounts of whether we should be using triangles or quads, in many of my experiences, quads seems to win.

One thing I will absolutely bet on, if we could render all the debug drawing stuff at once in either a quad batch or a triangle batch I think it would be a ton faster (or about as fast as quad batching is for normal FlxSprites) since the draw order of debug drawing doesn't matter, and they need to draw on top of everything for each camera, could we simply defer drawing them all until the after the entire draw phase?

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

Successfully merging a pull request may close this issue.

3 participants