Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TIPE: Unified parameters with inheritance #103

Open
olofson opened this issue Aug 17, 2016 · 0 comments
Open

TIPE: Unified parameters with inheritance #103

olofson opened this issue Aug 17, 2016 · 0 comments

Comments

@olofson
Copy link
Owner

olofson commented Aug 17, 2016

Currently, the TIPE input data has a fixed structure - top level, sources, layers, and (implicitly) frames - with each level having its own specific parameters. Frames are not really addressable in the structure, except that some layer parameters can be arrays of per-frame or interpolated values.

Most parameters should only really exist on the layer level, with inheritance from any higher levels, where the TIPE defaults would be the implicit top level. It should be possible to specify any parameter on any level, with lower level parameters overriding higher level ones locally.

Rather than just having a top level, and layers, there should be groups or similar, that can be nested to arbitrary depth. A group would be a table which can contain parameters, a "layers" table, and/or further groups. A group should probably defined as any "unknown" item (as in, a name not recognized as a parameter), holding a table. One should probably recommend a safe naming convention, such as BumpyCaps or similar, to avoid collisions with parameter names.

Note that in the current implementation, there are a few parameters that are handled globally, for the entire output sprite sheet. Some of these could actually be implemented on a per-frame basis, but there may still be conflicts in certain cases, in which case warnings should be logged.

The "output" parameter needs some special handling: When entering a level where "output" is specified, a new rendering target surface needs to be created, and when leaving that level, that surface is to be converted and written to file, as specified by the current parameter set. This way, multiple sprite sheets can be rendered from a single parameter structure.

The engine.target field should probably be an array or something, to handle this. Maybe put them in a table, keyed with the group names that generated the respective images? This table could also serve a sources for recursive rendering.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant