haxegon

haxegon copied to clipboard

Haxegon depends on a custom modified version of Starling.

Those changes could be pulled back into private functions in Haxegon, allowing Haxegon to work with an unmodified version of Starling!

Which is the sorta thing that nobody will really care about - but it is worth considering for 1.0, just to have a kind of final engine setup for launch...

Specifically, you'd need to:

• [ ] Add private lock and unlock functions to Gfx to replace the ones added to RenderTexture. These would apply to the current Gfx.drawto object.
• [ ] Move the "Starling Shapes" plugin into to Haxegon. (Requires a bunch of package name rearranging I think)
• [ ] Look into State Machine adjustments and reapply em
• [ ] Any future Starling Extensions you get around to using by the time you do this, they'll have to be moved into Haxegon to.

@TerryCavanagh I'm thinking of trying my hand at this because we might get into dependency hell if we keep modifying Haxegon's starling rather than just adding the official up-to-date library as a dependency. You're going to begin optimization of the framework so best to split the library first before further modifying the Haxegon starling.

1. The only modified file in Starling is RenderTexture.hx? Maybe consider contributing to the official Starling library? Or fork a Haxegon specific Starling library if it is too Haxegon-specific?
2. For Starling Shapes, do you think we should do a separate library instead of mixing with Haxegon?
3. What are these State Machine adjustments are you referring to?

Hey!

It would be cool to do this, but I think there are a lot of things to consider!

1. The RenderTexture changes sort of simulate a lock and unlock buffer action for Starling. What I'd probably do here is make an extended HaxegonRenderTexture class and use that internally. I don't think a contribution to Starling makes sense here, since they're fairly set on keeping the library minimal, and also because they're trying to keep as much 1:1 compatibility with the original flash library as they can.

2. I think for the starling shapes extension, we can basically just move all that into haxegon :)

3. I think there's basically only remaining thing - a check for meshs in rendering/BatchProcesser.hx. Which I could probably scrap, tbh

• Half implemented for now - Starling Shapes and HexagonRenderTexture have been refactored and moved into Hexagon.