aseprite-zig
aseprite-zig is an idiomatic
.aseprite parser with a focus on speed (supporting ALL versions of Aseprite)
15 Replies
This project is a product of me and @earth's penguin's intrest to make a Raylib game using aseprite sprites.
Unlike other libraries, we plan on adding tilemap support
Here will be our little check boxes for what we have done so far
✅ fully implementation & tested
☑️ experimental implementation / semi-tested
❌ not implemented
TODO:
Header
* ☑️ file size
* ☑️ magic number
* ☑️ frame count
* ☑️ width
* ☑️ height
* ☑️ color depth
* ☑️ flags
* ☑️ (DEPRECATED) speed
* ☑️ palette transparency index
* ☑️ color_count
* ☑️ pixel_width
* ☑️ pixel_height
* ☑️ grid_pos_x
* ☑️ grid_pos_y
* ☑️ grid_width
* ☑️ grid_height
Frame
* ☑️ size
* ☑️ magic number
* ☑️ (DEPRECATED) number of chunks
* ☑️ duration
* ☑️ number of chunks
Chunks
* ☑️ chunk size
* ☑️ chunk type
THE REST OF THE CHUNK TYPES ARE IN THE PINNED MESSAGES
Created a new logo for the sprites README, for context sprites is a directory which has .aseprite files exported from many different versions of Aseprite. All of which are only used for testing and aren't actually required to use aseprite-zig
Working on a general README now
Added a sweet little README topping
Old palette chunk (0x0004)
* ❌ packet count
for each packet
* ❌ palette entry count to skip
* ❌ color count
for each color
* ❌ red (0-255)
* ❌ green (0-255)
* ❌ blue (0-255)
Old palette chunk (0x0011)
* ❌ packet count
for each packet
* ❌ palette entry count to skip
* ❌ color count
for each color
* ❌ red (0-63)
* ❌ green (0-63)
* ❌ blue (0-63)
Layer Chunk (0x2004)
* flags
* ☑️ visible
* ☑️ editable
* ☑️ lock movement
* ☑️ background
* ☑️ prefer linked cels
* ☑️ the layer group should be displayed collapsed
* ☑️ the layer is a reference layer
* layer type
* ☑️ normal (image) layer
* ☑️ group
* ☑️ tilemap
* ☑️ layer child level
* ☑️ (IGNORED) default layer width in pixels
* ☑️ (IGNORED) default layer height in pixels
* blend mode
* ☑️ Normal
* ☑️ multiply
* ☑️ screen
* ☑️ overlay
* ☑️ darken
* ☑️ lighten
* ☑️ color dodge
* ☑️ color burn
* ☑️ hard light
* ☑️ soft light
* ☑️ difference
* ☑️ exclusion
* ☑️ hue
* ☑️ saturation
* ☑️ color
* ☑️ luminosity
* ☑️ addition
* ☑️ subtract
* ☑️ divide
* ☑️ opacity
* ☑️ layer name
* ☑️ tileset inde
Cel Chunk (0x2005)
* ☑️ layer index
* ☑️ x position
* ☑️ y position
* ☑️ opacity level
* cel type
* ☑️ raw image data (unused, compressed image is preferred)
* ☑️ linked cel
* ☑️ compressed image
* ❌ compressed tilemap
* ☑️ z-index
For cel type: Raw Image Data
* ☑️ width
* ☑️ height
* ☑️ raw pixel data
For cel type: Linked Cel
* ☑️ frame position to link with
For cel type: Compressed Image
* ☑️ width
* ☑️ height
* ☑️ raw pixel data compressed with ZLIB
For cel type: Compressed Tilemap
* ❌ width
* ❌ height
* ❌ bits per tile
* ❌ bitmask for tile ID
* ❌ bitmask for X flip
* ❌ bitmask for Y flip
* ❌ bitmask for diagonal flip
* ❌ row by row, from top to bottom tile by tile compressed with ZLIB
Thanks to Discord's message limit I had to break up the todo
I really should move the todo else where off Discord, but whatever
For now this will work
Switched up the README a tad bit
Created a
tests directory, switching up the logo for sprites. Another thing, I have now justified why I'm testing each version that I test. This will be required when requesting a version of Aseprite to test on.I also went and created a logo for the
examples directory
I have decided to split up the api into 3 parts. Is this too much? Maybe... but I find this 3 layer api allows for some really fine grain control. The other ideas are:
1. omit low level
2. omit high level (I really don't see this as an option)
Raw is pretty much required as I need a direct 1:1 representation of the .aseprite spec. or alternativly I can build that into the high level api. Theres a slight issue with doing that though, as it floods the high level api with tons of garbage. This garbage is stuff like the magic number which has no bearing on the sprite itself. Finding a good way to merge raw and high level is hard. As such if 3 parts is too much, what about 2?
I heard of Aseprite some time ago and knew it had something to do with drawing pixel arts
I didn't know it was that complex and that you could do animations on it tho
Yep animations, and even tilemaps
It's actually very powerful
it is really great. although you can compile it yourself, i paid for it. $20 and i get a steam key as well as pre-compiled updates
To avoid tons of complexity I decided to only have one high level api which wraps the raw api
Implementing some of what was the low level api's methods into the raw api
So now the raw api and the low api have been merged
This creates less ambiguity on how to use Aseprite-Zig
At this very moment the api is a bit all over the place
Once everything is correctly implemented at the
raw level I will go through and manually tweak everything
For example renaming type to kind to avoid naming issues with Zig
These changes should be small enough to the point where someone reading the Aseprite spec. will still instantly be able to understand what that would be in Aseprite-Zig
The minor changes made are just for consistencies sake, as keeping the library uniform is very important to me
Updated the Discord todo list