I'm saving textures for creating VRChat worlds. It would be impossible to mark every texture i'll use or not 1 by 1 but i'll give credit to each author i downloaded from.
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. )
Here we go.
The results are excellent. Thank you again, MedicineStorm, you had a great idea.
Now, down to business:
First image is a direct confrontation of first frame (Any frame could have been used.)
The other 3 files are
A gif created with ASEprite by manual procedure. (and, sorry if i sound presumptuous, but i think i have great familiarity with the task.)
A gif created with Medicinestorm's script with an arbitrary background.
A gif created with Medicinestorm's script with black background.
Short answer: Perfect for the task.
Long answer:
I applied a coloured background, and it applied a form of optimization that resulted in dithering and consequent "green dots", wich was to be expected, the tool isn't designed to print production ready stuff. The overall effect is apparent on real objects, probably ignored by most human minds on abstract object such as sparks or smoke.
The complexity of the optimization on the GIF compression is seen in the filesize.
Since the effect is interesting and can be used in production, i launched the script another time with a black background, and i got surprised by noticing that the dithering was much less noticeable. I removed the darkest colors in the palette untill they were in the sprite, and i can say that as long as the sprite itself doesn't contain colors darker than 64/255 it can be used to convert PNGs into 8bits sprites, if required.
In general i'd advise to use a black background for solid objects, coloured background for etheric objects or abstract effects, for best result, but the optimization isn't really spoiling the preview, the result is rather good.
Perhaps it could be expanded, but the selling point is the simplicity and the fact it is nearly impossible to do mistakes.
I'll do some more experiments.
I'm ashamed to admit currently i can't put more than 5400 cels in a spritesheet and therefore i'm not allowed to laugh like a pirate and shout: "16384? HA! that's not even warm up!" ;)
Also: For now i must go to work, but this evening i'll try it myself, it looks very useful, the file below is a manual conversion, when i'll come back i'll download GIMP, install the script and recreate the animation with your script. I don't see reasons for the experiment to go wrong, and if it doesn't i'll use it myself, since manual conversion is indeed time consuming.
Looks like a great tool.
I can't name a tool better than this, for the purpose of creating previews quickly, since it doesn't require specific experience, decisions based on it or manual procedures. It can be used by anyone even if they isn't familiar with GIF's architecture, and i'll recommend it to whoever wishes to create animated samples of 32 bits PNG but has trouble with manual conversion.
I apologize if my observations sound like complaints, but i don't speak good english and altough i try to make some time to help with what i mean to be constructive critics...
The bad news: i don't have much time and energy to spend in semantics and ducal courtesy.
The good news: I guess other people is in the same situation, if something someone said can be read according to 2 meanings and one of them is offensive i assumed they meant the other meaning.
Also, if the overall style requires the eyes to be clearly visible, the shadow between the eyebrows gives an overall neanderthal-ish vibe, that quite clearly isn't there on purpose, perhaps that shadow isn't necessary, i made an example here.
I had the time and the energy to log in into opengameart just today, i'm sorry for the delay after i promised a shower of ugly, bad and muscular komato warriors, sailors, scientists, the raw renders are in my hard disk, but in those troubled months i didn't find the time or the energy to edit them, A.S.A.P. i'll get back to work on this project.
I'm saving textures for creating VRChat worlds. It would be impossible to mark every texture i'll use or not 1 by 1 but i'll give credit to each author i downloaded from.
On Aseprite the "rot-sprite" algorithm is very similar to "eagle eye engine", plus it is possible to cut some edges with the filter "despeckle"
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. )
Here we go.
The results are excellent. Thank you again, MedicineStorm, you had a great idea.
Now, down to business:
First image is a direct confrontation of first frame (Any frame could have been used.)
The other 3 files are
A gif created with ASEprite by manual procedure. (and, sorry if i sound presumptuous, but i think i have great familiarity with the task.)
A gif created with Medicinestorm's script with an arbitrary background.
A gif created with Medicinestorm's script with black background.
Short answer: Perfect for the task.
Long answer:
I applied a coloured background, and it applied a form of optimization that resulted in dithering and consequent "green dots", wich was to be expected, the tool isn't designed to print production ready stuff. The overall effect is apparent on real objects, probably ignored by most human minds on abstract object such as sparks or smoke.
The complexity of the optimization on the GIF compression is seen in the filesize.
Since the effect is interesting and can be used in production, i launched the script another time with a black background, and i got surprised by noticing that the dithering was much less noticeable. I removed the darkest colors in the palette untill they were in the sprite, and i can say that as long as the sprite itself doesn't contain colors darker than 64/255 it can be used to convert PNGs into 8bits sprites, if required.
In general i'd advise to use a black background for solid objects, coloured background for etheric objects or abstract effects, for best result, but the optimization isn't really spoiling the preview, the result is rather good.
Perhaps it could be expanded, but the selling point is the simplicity and the fact it is nearly impossible to do mistakes.
I'll do some more experiments.
I'm ashamed to admit currently i can't put more than 5400 cels in a spritesheet and therefore i'm not allowed to laugh like a pirate and shout: "16384? HA! that's not even warm up!" ;)
Also: For now i must go to work, but this evening i'll try it myself, it looks very useful, the file below is a manual conversion, when i'll come back i'll download GIMP, install the script and recreate the animation with your script. I don't see reasons for the experiment to go wrong, and if it doesn't i'll use it myself, since manual conversion is indeed time consuming.
Looks like a great tool.
I can't name a tool better than this, for the purpose of creating previews quickly, since it doesn't require specific experience, decisions based on it or manual procedures. It can be used by anyone even if they isn't familiar with GIF's architecture, and i'll recommend it to whoever wishes to create animated samples of 32 bits PNG but has trouble with manual conversion.
You are very welcome.
I apologize if my observations sound like complaints, but i don't speak good english and altough i try to make some time to help with what i mean to be constructive critics...
The bad news: i don't have much time and energy to spend in semantics and ducal courtesy.
The good news: I guess other people is in the same situation, if something someone said can be read according to 2 meanings and one of them is offensive i assumed they meant the other meaning.
Also, if the overall style requires the eyes to be clearly visible, the shadow between the eyebrows gives an overall neanderthal-ish vibe, that quite clearly isn't there on purpose, perhaps that shadow isn't necessary, i made an example here.
I had the time and the energy to log in into opengameart just today, i'm sorry for the delay after i promised a shower of ugly, bad and muscular komato warriors, sailors, scientists, the raw renders are in my hard disk, but in those troubled months i didn't find the time or the energy to edit them, A.S.A.P. i'll get back to work on this project.
Pages