Rework & separate renderers

[ACrazyTown]

Here we go, first step towards a renderer overhaul. Looks like a pretty big and scary change but 99% of this is just moving stuff around.

Shout out goes to Beeblerox & Austin East, a lot of this is based on the original renderer overhaul branch, I'm just porting bits and pieces to modern Flixel.

This PR:

• Adds a new FlxCameraView class, accessible via camera.view, which serves as the base for all rendering functionality. Renderer implementations extend it and implement the required methods.
  • The blitting and draw quads renderers have been ported to FlxBlitView and FlxQuadView, respectively. You can use the camera.viewBlit and camera.viewQuad shortcuts to access the camera's view typed as the respective class.
• Moves all of the rendering functionality from FlxCamera into FlxCameraView implementations.
  • Existing methods have not been moved, or deprecated, but rather serve as a shortcut to the corresponding method in the camera view.

I'm opening this as a DRAFT, because:

• This needs to be tested thoroughly to make sure I didn't accidentally break something
• Would be nice to add docs to a bunch of stuff
• I don't know what to do with a bunch of private internal variables in FlxCamera and alike. What's Flixel's way of handling this? Should I simply get rid of them, or deprecate them and make them point to where they were moved?

TODO:

• flixel/addons/display/FlxShaderMaskCamera.hx:222 -- Field fill should be declared with overload since it was already declared as overload in superclass
• Documentation
• Figure out what to do with deprecated private functions/vars
• Better function names?

[ACrazyTown]

I decided to deprecate all the internals and make them point to where they were moved, to avoid breaking anything.

Addons and UI will need to be updated to avoid warnings, I'll get to that in a bit. Addons specifically seems to have an issue because FlxShaderMaskCamera overrides camera.fill(), it'll need to be updated to also add overload extern, hopefully that's not a blocker

I think this is in a good enough of a state now for a review, so I'll undraft

[Geokureli]

Rather than overloading maybe we should define a new fillView() or use view.fill directly?

[ACrazyTown]

I guess that could work. I'm leaning more towards fillView(), I think having a convenience method in FlxCamera would be nice. What about all the other overloaded methods? Ideally I wanted to keep everything working as is, but I completely forgot to account that people might be overriding these methods

[ACrazyTown]

Note to self, this can probably be simplified to just view.display

[ACrazyTown]

Some more notes and thoughts. I'm currently playing around trying to implement an OpenGL renderer to really test the flexibility of this system.

Overloading methods in FlxCameraView won't work:

For stuff like FlxMaterial and FlxTrianglesData, the function signatures of the core rendering functions need to be changed. To avoid breaking changes, I was just going to do this with overloads, but that didn't work out because overloads need to be inlined and you can't override inline functions.

I got around this by deprecating drawPixels() and copyPixels() for draw() and copy() in FlxCameraView, but I couldn't do the same in FlxCamera because it inherits FlxBasic.draw(). I ended up overloading the camera's drawPixels() and copyPixels() to call the new methods in camera view. Pretty gross solution IMO but I can't think of a better way without a breaking change.

Unifying renderBlit with other renderers

I did some work related to this in 3cd97d9, but there's still a couple places where we have to do things differently depending on the renderer, notably drawPixels() and copyPixels():

flixel/flixel/FlxCamera.hx

Lines 743 to 744 in c32ab91

	public function drawPixels(?frame:FlxFrame, ?pixels:BitmapData, matrix:FlxMatrix, ?transform:ColorTransform, ?blend:BlendMode, ?smoothing:Bool = false,
	?shader:FlxShader):Void

When the blitting renderer is used, pixels will be used for the rendering, otherwise frame is used. I wonder if it's somehow possible to avoid this special behavior and just pass in one thing, without having to know what renderer is used. The user should just have to call camera.drawPixels(...); once, and the underlying implementation should take care of any special quirks.

Isolating direct access to renderer

Flixel shouldn't access any renderer implementations directly from common code, it should be done through the renderer abstraction. First thing that comes to mind is that we need to abstract way maxTextureSize

EDIT: This could be done via the RenderFrontEnd via some method like FlxG.render.getMaxTextureSize()