-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Sprite definition format #965
Comments
Have you considered an existing textual format such as toml? |
We had a discussion in IRC, a |
propsed specification: Sprite File Formats
Both file types contains key-value pairs. Why not nyan?https://github.com/SFTtech/nyan has quite some overhead and is not as compact as this format. Requirements
|
As I mentioned here, there are some things I noticed while working on the sprite formatter:
|
That was an error in the definition. It is supposed to be on the same line. Fixed it in jj's post :)
It is very pythonic (like calling a method). Mandatory values have fixed positions and require no keyword, all other values have a keyword because they are only valid for specific modes or optional. Plain data will also be marginally faster to parse.
There is no default value in that case. Sometimes the value is simply not be necessary.
Hmm.. what would be the benefit of that? Internally, the frame must be attached to an angle anyway and we would have to remember the previously defined angle. We can do it of course, but I do not see a real benefit. |
Gotcha.
It just felt unnecessary to have the redundancy, it's more stuff to parse. So this makes me think: does angle information (stuff like |
Let's keep the redundancy for now as it might make debugging a tiny bit easier. We can always change it later on when everything works well.
Yes, some attributes of a sprite come from the |
It's true, we could implicitly assign an angle by assigning it to the last-defined angle. I made that explicit to allow rearranging the lines: you could with the explicit angle reference first define all angles, and then assign all sprites to their angles. |
We have to get rid of the crappy csv files that describe where subtextures are. Instead, we need to create far more sophisticated™ key-value files that describe animations, frames and angles.
Why not nyan? The frame and animation definitions are directly linked to the image files. They don't change at runtime. And the renderer can directly organize the sprites internally without nyan queries.
The text was updated successfully, but these errors were encountered: