It's not my field, so i can't test the alignment myself, but i noticed a thing that can create confusion: The sidebar is too narrow. Even if an array of accessories is named just... IDK Cape1; Cape2; Cape3, or CapeA; CapeB; CapeC... It might become a little confusing for the end user to evaluate the options by counting the position in the array by pointing their finger at the monitor while scrolling up.
About the RAM or virtual RAM limit, it is pretty simple: Beside the limitation of 16384 frames, even if we talk about bigger frames, it looks like i can't put together on a PC a spritesheet so big that your script can't trim on the very same PC, but if i can put a sheet together on Aseprite, then your script can create a GIF.
There is objectively no position decay at all. It is possible that black background affects the outline differently than any other color, for reasons connected to the fact any factor multiplied by 0 gives 0 and this is why i ran different tests expecting different results.
Actually, if there is an apparent shift in the image, it would happen on not-black background, because, judging by the time the computer chews the procedures, it is when background isn't black that dithering becomes esoteric.
However: A slip of the finger (I.E. an height of 155 instead of 156) is always a possibility, but it would have produced a shift of 43-1 (First row won't get shifted) pixels in the end, in this particular spritesheet.
The Gif below has been obtained by typing 155 on purpose, and as expected, every 30 frames, the image shift down by 1 pixel. (Every self-respecting scientist/researcher deep down loves explosions and breaking stuff on purpose. )
When i code stuff myself, i work with sequences.
Somebody told me they understand spritesheet better than sequences but don't have the tools or know how to make spritesheets from sequences and therefore i started providing raw spritesheets, but i'm not familiar with spritesheets.
I might consider to select some frames from "the huge spritesheet" to suggest a complete foe ready to be coded, but it would be quite energy-consuming to do it "now". Kinda like a crocodile climbing a tree.
The human mind is quite brainy, and doesn't work like a car.
The sad truth is that everyone has weak points, mine is semantic. If i do ALL the semantic naming i would never be able to release anything.
-
Sometimes i try to devise a criteria to separate the cels, but there are really too many
(Idle, Attack, Gethit /Stand, Crouch, Air, Falling/ Runtime, Noctrl, Splash, Menu)
I'm aware of the fact a huge spritesheet might be scary at first, but with the sequence at hand it is relatively easy to find cels within the spritesheet, perhaps i should specify how wide is the spritesheet in cels (in this case 30)
I think that selection is an action required to anchor the sprite, anyway. So i deem it superfluous from my end. After all if someone is going to code a videogame or a more or less interactive movie, he'd have to name and anchor the cels anyway.
I don't have intention to put them in a game in the foreseeable future, but should i decide to code them i'll make sure to publish the selections i used, or even the SFF directory.
This is an hobby, and i don't want to face it as if it was a dayjob.
Since the sprites are public domain, anyone including you is welcome to make their own selections and share them.
Really good nesting. Also, i love that style. I guess it would be quite interesting to animate the grab, but all animals look fresh and seem to have good impact.
Looks like a very quick and versatile tool.
It's not my field, so i can't test the alignment myself, but i noticed a thing that can create confusion: The sidebar is too narrow. Even if an array of accessories is named just... IDK Cape1; Cape2; Cape3, or CapeA; CapeB; CapeC... It might become a little confusing for the end user to evaluate the options by counting the position in the array by pointing their finger at the monitor while scrolling up.
It might be simple, but it is strangely captivating... For sure it reminds me of the good old days.
BTW, i don't see any rope on the bows.
BTW: This class (Komato security) is composed by 51 ranks, in 17 collections. (or submissions) 16 are OpenGL, one will be Iray.
About the RAM or virtual RAM limit, it is pretty simple: Beside the limitation of 16384 frames, even if we talk about bigger frames, it looks like i can't put together on a PC a spritesheet so big that your script can't trim on the very same PC, but if i can put a sheet together on Aseprite, then your script can create a GIF.
There is objectively no position decay at all. It is possible that black background affects the outline differently than any other color, for reasons connected to the fact any factor multiplied by 0 gives 0 and this is why i ran different tests expecting different results.
Actually, if there is an apparent shift in the image, it would happen on not-black background, because, judging by the time the computer chews the procedures, it is when background isn't black that dithering becomes esoteric.
However: A slip of the finger (I.E. an height of 155 instead of 156) is always a possibility, but it would have produced a shift of 43-1 (First row won't get shifted) pixels in the end, in this particular spritesheet.
The Gif below has been obtained by typing 155 on purpose, and as expected, every 30 frames, the image shift down by 1 pixel. (Every self-respecting scientist/researcher deep down loves explosions and breaking stuff on purpose. )
Almost forgot:
When i code stuff myself, i work with sequences.
Somebody told me they understand spritesheet better than sequences but don't have the tools or know how to make spritesheets from sequences and therefore i started providing raw spritesheets, but i'm not familiar with spritesheets.
Thank you!
I was exactly thinking: "Uh, designing planets it's not my thing, let's hope somebody will publish them on OGA."
I might consider to select some frames from "the huge spritesheet" to suggest a complete foe ready to be coded, but it would be quite energy-consuming to do it "now". Kinda like a crocodile climbing a tree.
The human mind is quite brainy, and doesn't work like a car.
The sad truth is that everyone has weak points, mine is semantic. If i do ALL the semantic naming i would never be able to release anything.
-
Sometimes i try to devise a criteria to separate the cels, but there are really too many
(Idle, Attack, Gethit /Stand, Crouch, Air, Falling/ Runtime, Noctrl, Splash, Menu)
I'm aware of the fact a huge spritesheet might be scary at first, but with the sequence at hand it is relatively easy to find cels within the spritesheet, perhaps i should specify how wide is the spritesheet in cels (in this case 30)
I think that selection is an action required to anchor the sprite, anyway. So i deem it superfluous from my end. After all if someone is going to code a videogame or a more or less interactive movie, he'd have to name and anchor the cels anyway.
I don't have intention to put them in a game in the foreseeable future, but should i decide to code them i'll make sure to publish the selections i used, or even the SFF directory.
This is an hobby, and i don't want to face it as if it was a dayjob.
Since the sprites are public domain, anyone including you is welcome to make their own selections and share them.
It was a problem with Brave, in Firefox it works fine.
It looks simple but captivating.
I'm not familiar with Python, but there should be a way to make the snow fall endlessly.
Really good nesting. Also, i love that style. I guess it would be quite interesting to animate the grab, but all animals look fresh and seem to have good impact.
Pages