PrimaryFeather
commented
8 years ago My first version of the API actually did just that; there was a style that contained only the absolute minimum (just like the "Effect" base class). However, it turned out that this made some other parts of the API very hard to use.
E.g., the Quad and Image classes now provides methods and properties like setColor, setVertexColor, texture, setTextureCoordinates, etc. If I can't guarantee that a mesh even contains color or texture information, I can't provide those methods on those classes — even though 99% of the users will need them.
So you could say: fine, let the users change those values via quad.style. But even then, developers would constantly have to cast to MeshStyle before setting a texture or a color. Extremely annoying.
Thus, I decided to go the more pragmatic route and make the base MeshStyle already contain color and texture information. That doesn't mean that subclasses are forced to support that; they can still provide their own vertex format that doesn't contain any of that information. They just need to document that calls to the color- and texture-related data actually don't do anything.
I hope that makes some sense! :smile:
Starling obviously provides a default MeshStyle. It has some default features, such as color tinting vertexes. But, not all of those features will be applicable to all styles. As such, the default style should be a subclass of an abstract base class that only contains features shared by all styles.