Introduce an intermediate visual class

[ACrazyTown]

Related to #2915, #3053

Any visual related classes are expected to extend FlxSprite. This is fine in like 99% of cases, where we are working with a quad and we can inherit all its properties. However, this becomes a problem with the special case of FlxStrip.

FlxStrip extends FlxSprite, and yet does not implement most of its inherited properties, because it works in an entirely different way. As part of my rendering changes, I've been working on a replacement for FlxStrip that resolves most of its issues, like the lack of complex transformations (rotations, scale, origin...) and nonworking isOnScreen() checks.

In doing so, I've found myself in a dilemma between what class to base it off of. If I extend FlxSprite like FlxStrip did, the class would inherit a bunch of unused fields, and I wouldn't be able to even implement stuff like origin because centerOrigin() is inlined. Alternatively I thought about just basing it off of FlxObject and re-implementing the common bits but then stuff like sprite groups and anything that expects a FlxSprite would break.

I think the best solution would be to introduce some sort of intermediate class, or interface, that implements the common bits shared by both sprites and strips/meshes. That'd include stuff like angle, color (only multiplicative tinting, additive color transforms might be trickier to pull off for meshes for reasons I won't get into now), alpha, scale, origin etc...

[Geokureli]

I think the best way forward is to have FlxStrip extend FlxSprite, for now. For things like centerOrigin, you would implement that by setting frameWidth and frameHeight when the strip changes size. It's also not a breaking change to make a function non-inlined.

I fear an intermediary class is only reinforcing the problem, which is a overuse of inheritance, and switching to a composition system is the better long term solution.

If you stand by your initial solution, can you share an outline of what it would contain? is it basically FlxSprite minus the frame stuff?

If we did this, what would the dependency chain for FlxSpriteGroup be? for now I'll call it FlxDisplay (this is a bad name):

FlxObject -> FlxDisplay -> FlxSprite -> FlxTypedSpriteContainer<T:FlxSprite>
FlxObject -> FlxDisplay -> FlxTypedDisplayContainer<T:FlxDisplay>

or

FlxObject -> FlxDisplay -> FlxTypedDisplayContainer<T:FlxDisplay>
typedef FlxTypedSpriteContainer<T:FlxSprite> = FlxTypedDisplayContainer<T>

NGL I hate FlxSpriteContainers and the idea of making more of them

[ACrazyTown]

I think the best way forward is to have FlxStrip extend FlxSprite

Just to clarify, I'm talking about a new class that behaves similarly to FlxStrip, to simplify things we can refer to it as a FlxMesh. Since it's a new class, I don't have to worry about keeping backwards compatibility so I thought I'd ask for a second opinion about this

For things like centerOrigin, you would implement that by setting frameWidth and frameHeight when the strip changes size. It's also not a breaking change to make a function non-inlined.

That might work; feels pretty hacky though. It changes the meaning of what frame(Width/Height) mean. In a regular sprite context it refers to the texture's dimensions, but in the context of a mesh it'd now represent the mesh bounds. What happens when we're dealing with a mesh that has a texture?.

I fear an intermediary class is only reinforcing the problem, which is a overuse of inheritance, and switching to a composition system is the better long term solution.

I don't feel too strongly about this. If it'd interfere with the composition system too much I'd be down to look for an alternative solution. I'm just trying to make do with the current setup while keeping jank to a minimum.

If you stand by your initial solution, can you share an outline of what it would contain? is it basically FlxSprite minus the frame stuff?

Pretty much, yes. I skimmed through FlxSprite's properties and I think these are the only ones we can reliably implement for both display types:

• alpha
• antialiasing
• blend
• clipRect (with new renderer stuff I think we can also expand this to more different shapes and do cool masking stuff)
• color (not colorTransform)
• flipX
• flipY
• offset
• origin
• scale
• shader

If we did this, what would the dependency chain for FlxSpriteGroup be? for now I'll call it FlxDisplay (this is a bad name):

FlxObject -> FlxDisplay -> FlxSprite -> FlxTypedSpriteContainer<T:FlxSprite>
FlxObject -> FlxDisplay -> FlxTypedDisplayContainer<T:FlxDisplay>

or

FlxObject -> FlxDisplay -> FlxTypedDisplayContainer<T:FlxDisplay>
typedef FlxTypedSpriteContainer<T:FlxSprite> = FlxTypedDisplayContainer<T>

NGL I hate FlxSpriteContainers and the idea of making more of them

The latter. I also want to avoid making a bunch of new classes and I think this is something that could be implemented without too much fuss and without breaking already established things

[Geokureli]

The latter

On second thought that might not be possible, as it would mean FlxSpriteContainer isn't a FlxSprite, so you couldn't add FlxSpriteContainers to FlxSpriteContainers

It would need to be

FlxObject -> FlxDisplay -> FlxSprite -> FlxTypedDisplayContainer<T:FlxDisplay> -> FlxTypedSpriteContainer<T:FlxSprite>

[ACrazyTown]

On second thought that might not be possible, as it would mean FlxSpriteContainer isn't a FlxSprite, so you couldn't add FlxSpriteContainers to FlxSpriteContainers

It would need to be

FlxObject -> FlxDisplay -> FlxSprite -> FlxTypedDisplayContainer<T:FlxDisplay> -> FlxTypedSpriteContainer<T:FlxSprite>

Ah good catch.

So do you think that making a new class is not worth the hassle, even if we'd have to bend the rules a bit to get things working as a FlxSprite extension?

[Geokureli]

So do you think that making a new class is not worth the hassle, even if we'd have to bend the rules a bit to get things working as a FlxSprite extension?

The more I think about it the more I see potential, I think:

1. Making a FlxDisplayContainer would allow me to take out some issues I have with FlxSpriteContainer/Group without breaking existing games. I plan to deprecate FlxSpriteGroup soon, so there would be no FlxDisplayGroup
2. Having a graphical class with no frame/animation control could actually be a useful step towards a composition system, simply by making FlxSprite a simpler, more focused class

I do think the more we extend this base display class, the more issues we will have, as most of our features won't support them. but I don't see people caring about that for meshes and I don't see many more extensions on the horizon.

I would like it if the bulk of FlxMesh was a FlxDisplay with a mesh field that covers as much of the logic as possible, with the new mesh specifc fields in FlxMesh simply being helpers that reference the mesh's fields/methods.

Also consider what this heirarchy will be once we do make things more compositional: Will FlxDisplay have a display field that controls the fields you listed above (say FlxDisplayController), and the mesh will be a FlxMeshController that extends it, or an entirely separate component. We might as well briefly consider FlxSprite's components on top of display as well. As for the scope of this project, we don't need all of that set in stone, just FlxDisplay, FlxMesh and FlxMeshController. FlxDisplay can be it's own PR

Man it would be great if the name FlxGraphic wasn't already taken

[ACrazyTown]

I do think the more we extend this base display class, the more issues we will have, as most of our features won't support them. but I don't see people caring about that for meshes and I don't see many more extensions on the horizon.

I don't think we'll even need anymore extensions apart from the two. Sprites cover 90% of the use case and meshes cover the other 10%. Hell, you could even make sprites extend meshes as a quad is merely a 2 triangle mesh, but I think that's overkill.

I would like it if the bulk of FlxMesh was a FlxDisplay with a mesh field that covers as much of the logic as possible, with the new mesh specifc fields in FlxMesh simply being helpers that reference the mesh's fields/methods.

In my current draft FlxMesh only introduces two new fields: topology and geometry. Geometry does most of the heavy lifting, and it's where the vertices, uvs, indices and colors are stored. I've also been thinking of moving topology into the geometry class. All in all FlxMesh is a pretty tiny class.

Also consider what this heirarchy will be once we do make things more compositional: Will FlxDisplay have a display field that controls the fields you listed above (say FlxDisplayController), and the mesh will be a FlxMeshController that extends it, or an entirely separate component. We might as well briefly consider FlxSprite's components on top of display as well. As for the scope of this project, we don't need all of that set in stone, just FlxDisplay, FlxMesh and FlxMeshController. FlxDisplay can be it's own PR

I suppose something along those lines, I'm not actually sure... I need to familiarize myself with composition a bit more!! Are most fields going to be moved into seperate components, with the extending classes just being some sort of preset with them already added?