It is currently Sat Apr 20, 2019 7:13 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 18 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Fri Mar 29, 2019 9:05 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1282
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.

Coming soon™ since 2018!
Image
Image
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! :lol:

Edit2: I've attached a file of what it currently exports for sprite data. I guess I'm this deep in, anyway...
Attachment:
Exported Character Files.txt [3.23 KiB]
Downloaded 50 times

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:
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

Usually (because, again, each state technically had its own version of this) a byte was split in half. The low bits were the frame timer, and the high bits were the frame. By adding to the low bits, the high bits would eventually change, changing the frame. Then the low bits were divided out to get the actual graphic to display, loaded from a table.

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.)

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Sat Mar 30, 2019 3:16 pm 
Offline

Joined: Tue Oct 16, 2018 5:46 am
Posts: 78
Location: Gothenburg, Sweden
koitsu wrote:
You might consider using NES Screen Tool by Shiru here on the forum instead. I haven't used it myself, but have seen infiniteneslives use it on his live streams.

FrankenGraphics wrote:
I use NESST for pretty much everything except 1) sprite overlays on still pictures such as title screens and 2) animation previews. For the latter i just screen grab and paste my NESST-made metasprites in photoshop and make gif animations; 2 frames equals 1 NES frame (on PAL, NTSC would be slightly quicker). I can still step through metapsrites to kind of review animations in NESST.

You need to be a bit careful when saving, which has its quirks, and when editing metasprites, but otherwise it's really great.

I really enjoy NESST too, it's what I do all my metasprite work in, apart from sketching in Photoshop. My workflow so far is to make all my tiles and metasprites in NESST, then running a python script in my compile script (*.bat file). The python script I've done is passed some parameters for what *.msb file to read and what the output should be. It then spits out the data as labeled assembly in a tailored format that I include in my game engine.

Kasumi wrote:
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:
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

Usually (because, again, each state technically had its own version of this) a byte was split in half. The low bits were the frame timer, and the high bits were the frame. By adding to the low bits, the high bits would eventually change, changing the frame. Then the low bits were divided out to get the actual graphic to display, loaded from a table.

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.)

Thank you for taking part in the discussion, and in such detail too! :beer:

I would definitely like to try your tools and I'll PM you a request about that. From what I understand your tool set is an all-in-one conversion from a sequence of images to CHRs, palettes, metasprites and animations? It would be really interesting to try that workflow. I would imagine it can speed up iterations quite a lot.

I read through the exported data example you linked and you seem to also store a delay value for each frame. But when reading your code example, I can't see where that value is actually read? It can't be "AJNAframe, x", right? Because then you would have to be using indirect addressing with the y register. Unless you've already read the value before and stored it somewhere in RAM, which would be AJNAframe?

Back to the issue of tools; as cool as it is to create all graphical content from bitmap sequences, I still feel it could be good to have a sequencer tool that dealt with CHR data and msb's natively. The more I think about, I wish there was a tab for sequencing animations in NESST, just like there's a tab for nametables and metasprites. It's been many years since I touched C++ and I never fully got the hang of it, but maybe I should have a look at the source code for NESST to see if I can add something like that. Or perhaps I'd do better to just make something in C# or python first. But from what I understand you are already working on code for your tool to import data from NESST?
Kasumi wrote:
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! :lol:


Top
 Profile  
 
PostPosted: Sat Mar 30, 2019 11:55 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1282
pwnskar wrote:
From what I understand your tool set is an all-in-one conversion from a sequence of images to CHRs, palettes, metasprites and animations?

Yes. You open an image sequence. You wait (sometimes an hour, if you're doing something insane like 255 frames of Street Fighter 3 Third Strike animation). You optionally open another image sequence for another animation. You press shift+E. You're done.
pwnskar wrote:
I would imagine it can speed up iterations quite a lot.

Making changes free to try is probably the largest benefit. Even if you eventually want to do it manually, this can help get things in game quickly to see how they'll look before committing to doing it manually.

I avoided changing certain attack animations in Indivisible for a long time, because I dreaded the work. I-CHR can do all the frames (over 200) significantly faster than I can do a single frame manually. The result is slightly worse (as far as tile use), but at this scale that doesn't matter.
Quote:
I read through the exported data example you linked and you seem to also store a delay value for each frame. But when reading your code example, I can't see where that value is actually read? It can't be "AJNAframe, x", right? Because then you would have to be using indirect addressing with the y register. Unless you've already read the value before and stored it somewhere in RAM, which would be AJNAframe?

This tool was made after Indivisible, in response to the problems I had with the process. Indivisible doesn't have different frame delays per frame, only per animation. If a frame in an animation needs to be displayed for twice as long as the other frames:
Code:
frames:
.db 0, 1, 2, 2, 3

I'm not that sure I'd support different frame delays per frame even in a new engine I might write, I don't think it'd do anything but use more CPU. The tool supports it because it was easy to do.
Quote:
Back to the issue of tools; as cool as it is to create all graphical content from bitmap sequences, I still feel it could be good to have a sequencer tool that dealt with CHR data and msb's natively.
...
But from what I understand you are already working on code for your tool to import data from NESST?

I had NESST import working so I could compare my manual Indivisible work to it, but it got broken somewhere along the way. I don't personally benefit much from fixing it. My biggest goal is to just release the update. I have lots of ideas for it, but right now I'm mostly just killed by how much better what I'm sitting on is than the public version. (The public version is still real good at what it does, though.)

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group