search

HaxeFlixel / flixel

Free, cross-platform 2D game engine powered by Haxe and OpenFL
https://haxeflixel.com/
MIT License
1.92k stars 427 forks source link

Improve Performance of Debug Drawing #3164

Open Geokureli opened 4 weeks ago

Geokureli commented 4 weeks ago

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: https://github.com/HaxeFlixel/flixel/issues/2715

Cheemsandfriends commented 4 weeks ago

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 commented 4 weeks ago

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 commented 4 weeks ago

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 commented 4 weeks ago

I don't understand what you're suggesting

Cheemsandfriends commented 4 weeks ago

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

ninjamuffin99 commented 2 weeks ago

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 commented 2 weeks ago

one in particular might be the FlxDraw class, https://github.com/HaxeFlixel/flixel/compare/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 commented 2 weeks ago

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?