Coming soon™ since 2018!pwnskar wrote:I've seen some gifs of mind blowing tools by kasumi but I don't know if he/she has shared anything related to animation sequences of existing CHR and metasprite data.
Import an image sequence, get CHR data and metasprites. No preparation needed in most cases, even if the image sequence is more than 4 colors (so long as it is less than 14 colors). (That said, you probably at least want to set up a palette file for it to use. It's capable of guessing, but if you make it guess for multiple characters, the guesses won't align which isn't good if you want them on screen together.)
You're welcome to PM me if you want to try it. It works, and is stable (albeit probably hard coded to something slightly less useful for the latest shareable version), but I've been getting the impression that what people want from it is even more impossible than what it already does. There's also a public version here: https://kasumi.itch.io/ichr But it only does backgrounds (which, yes, can be animated). It should be similarly no fuss. Just import the image and get data. No manual recoloring or anything, unless the image doesn't conform. (In which case it usually shows you where.)
Assuming your sprite were only 3 colors plus transparent, you could use the public version for that, but I wouldn't recommend it. (It has been used in this way, though.)
Edit: It exports NES Screen Tool data (provided the entire character uses less than 256 tiles), but can't import it (through the UI, anyway). I have some code for it, but there are reasons why it's not available. I've been trying to plan how best to make those >256 tile characters still be interoperable with NES Screen Tool. Re-reading your post, this is probably the main thing you want, and I slightly regret writing the rest!
Edit2: I've attached a file of what it currently exports for sprite data. I guess I'm this deep in, anyway... Edit3: (Some things are explained elsewhere in the documentation. u is unsigned, s is signed. The number following is how many bits. All big endian.)
It can also save and load all data to a single custom file, but I feel like I'm going to regret that it exists.
As far as Aseprite being unintuitive, I really disagree. Whatever ways you find its region select features to be unlike other editors can probably be changed. (By default it's MS Paint-like, but it can be set like other things I've used.) (Unless you mean specifically for selecting/moving frames and or layers, rather than the canvas, in which case I agree.) Similarly, if you find the file oriented dialogs terrible, there's an option to use native OS file dialogs (which doesn't work on Linux Mint at least, but well... or maybe that's fixed, I haven't updated in a bit, because I haven't done pixel art in a bit.)
Granted, it has some defaults that are unlike other software (my least favorite being the canvas scaled to 200X by default, in such a way you can't see 1:1 pixels), but I'm not sure it's fair to expect it to behave like something else. I don't think it does anything egregious (like say, Pro Motion which ran counter to everything I've used in nearly every respect as opposed to a reasonable number of things.)
Extensions are for skins/palettes. It supports Lua scripting, which might be a better start for dealing with NES Graphics: https://github.com/aseprite/api Whether documentation is good depends on perspective. People seemed to take to it very quickly. Had it had that when I started my graphics tool, maybe I'd have used it.
I find Aseprite to be the least frustrating piece of software I've ever used (that wasn't... like a text editor), and it's getting better all the time. It getting better all the time, and getting better quickly is perhaps why I cut it slack. Tile support is being worked on: https://twitter.com/aseprite/status/109 ... 21?lang=en All kinds of other things are constantly being worked on, across all areas of it to give it better features, and make it more user friendly. Lua scripting seemed to come out of nowhere, and perhaps it has problems now (haven't done much with it), but I have confidence they'll be fixed. I have confidence most things in Aseprite will be fixed. Forgive me, I'm an Aseprite stan.
My on topic answer, that is neither about Aseprite, nor about my own graphics tools:
For Indivisible, animations were more or less tied to states. Each state had a duplicate of some animation playback code, but not code to check for when to advance individual frames.
Code: Select all
lda AJNAframe,x;AJNAframetimer clc adc #%00000100 sta AJNAframe,x;AJNAframetimer cmp #5*16;*16 to shift to the high bits bcc ajna.standingaxeless2.continue jmp ajna.toidle ajna.standingaxeless2.continue: lsr a lsr a lsr a lsr a tay lda ajna.standingaxeless2frames,y sta AJNAmetasprite,x jmp spriteend
This state actually seems old, I ended up thinking of lots of clever bit hacks beyond the above to get the most out of that one byte. If you set the high bytes to $F0 - framecount*16, you can detect the end of the animation by the carry being set alone (as opposed to a cmp) and you can do similar for the lowest bits to make them advance in X frames without changing the add value.
I can certainly think of ways to make that generic (usually a state will play an animation, and then when the animation is complete go to another state), but some of Indivisible's states were reasonably meaty, and I think making them generic wouldn't have been worth it with regards to the kinds of things that needed to happen on specific frames. (During crouching Axe, a hitbox appears in the middle of the animation. You can cancel the attack by jumping if and only if that hitbox hits something, which will take effect after Ajna exits hitstop. Other attacks that hit can't be jump-canceled. Most attacks can be turned around within 3 frames of starting.)