You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: