Geo separate renderer

[Geokureli]

testing CI. may PR here, instead: https://github.com/ACrazyTown/flixel/compare/seperate-renderer...Geokureli:flixel:geo-separate-renderer?expand=1

[ACrazyTown]

One thing that stuck out to me, I think this name is a bit misleading. This seems more of some kind of canvas than it is a vertex buffer. Maybe a name like FlxCanvas would be better?

[Geokureli]

Lol, I spent so long trying to think of another name and eventually was like "just go with this and hope ACrazyTown suggests something better". I like it

I think there's other badly named things, so poke around and lmk

[Geokureli]

@ACrazyTown gonna type up a summary and some of my immediate plans. There's also this:Geokureli#5 which gave me nightmares

There's a lot of things that just suck in the old way, and if we're going to add new ways to do them we should make them not suck, otherwise we're gonna be back here, deprecating all of these new methods when we make the better system. That's why I added the wrappers for graphics and vector (in the other pr). I think we should also consider adding FlxTexture, now for this reason.

After my summary, I'm gonna test all the demos now (for real, this time). If it fails on #5 I'll test it on this branch if it fails on both I'll test it on yours, then dev until I know which set of changes caused it

[Geokureli]

• Nearly everything in rendering moved to view. This was the easiest thing I could do right now, I may move quad/tri batches to FlxCanvas. Some helpers may be better off as methods in their respective blit/quad renderer, so I added a rendererer field to blitview and quadview
• A lot of FlxCamera's deprecated helpers no longer point to the new version, a lot of them were unpooled points, rects and matrices that you couldn't nor shouldn't use as a way to influence rendering as they were cleared after each use
• FlxG.renderer.blit/tile: Seemed cute, might delete later, might change tile to quad. Also note a third CUSTOM method where blit/tile are null, I also changed a lot of != BLIT checks to == TILE so that quad things don't activte on CUSTOM
• Gonna type up more after errands

Some ideas:

• A way to force blit/quad at compile time, where forcing blit would make FlxG.renderer a FlxBlitRenderer at compile time, and FlxCameraView a FlxBlitView, allowing the dev to access blit fields without casting.
• FlxTexture, new methods that take bitmaps should take textures, instead
• There should be an easy way to assert the renderer to the expected type, i.e.: FlxG.renderer.assertBlit().useBufferLocking = true; where an error is thrown if a different method is being used. But also, most people should never have to do this, and there should be a nicer public facing way to do most things, same with views

[ACrazyTown]

• Nearly everything in rendering moved to view. This was the easiest thing I could do right now, I may move quad/tri batches to FlxCanvas. Some helpers may be better off as methods in their respective blit/quad renderer, so I added a rendererer field to blitview and quadview

I think it might be better to leave the batching as-is for now as it's specific to the drawQuads renderer. I'll start working on implementing the GL renderer to the abstraction, having two hardware accelerated renderers might make it easier to reason about things

I'm a bit worried about tying the render methods to the camera view but I suppose this boils back to my previous sentence

FlxTexture, new methods that take bitmaps should take textures, instead

I have a draft (as discussed in #3540) for this typed up in a branch somewhere. It's implemented as a new class rather than an abstract so there is a bit of friction with implementing it with existing systems. Will need to revisit it and clean it up

[ACrazyTown]

Also, maybe it'd be a good idea to merge this into a feature branch in the Flixel repo here. That way both of us can make PRs to that instead of going back and forth between our forks

[ACrazyTown]

Suggested change

	if (FlxG.renderer.blit)
	if (FlxG.renderer.tile)

This broke the "DrawQuads" stats in the debugger