Completely similar experience. If we can also see sprite sheet usage in 3d settings, (such as the 3D Sprite extension), it would be so much easier to get past that 1000 file limit on itch.
For what matter,
imo this should not replace the old animation/sprite system,
but should be an addition on what we have now.
Definitely, small projects (or at least projects with small animation frame count) and people with some workflows that have been presented here need that option.
I would go as far as suggesting a new spriteSheetObject , with its own specialized edit menu to name your animations like the spriteObject, but instead of looking for frames in a folder you look for them in a grid on your spriteSheet.
Wow I didnāt know there was a file limit associated with itch.io! Yeah there really should be a way to use spritesheets along with respecting the way we import assets now. Generating atlases on export could be a good idea?
What Silver suggest is best solution i seen so far when it comes to not generating tons of images
And if anything i would want to see at least that implemented
Where i would want just to use spritesheet by default
Since we often have frames of animation for example for our player object
It is A LOT easier to edit it in sprite sheet than going via each frame
For example imagine changing color of player shirt
I can simply select that color and change it for all instances of it on spritesheet image
Where now i need to edit spritesheet and then slice it
Where A LOT of users do not think about keeping spritesheet
So after they slice it they are left with editing image by image one by one
Which just feel sad
in some games you canāt without it.
i am in favor of using spritesheet.
but i donāt think itās correct to add a feature to the expense of another. (tested and working)
itās true, in indexed images you can replace the palettes at your wish.
however for example itās a feature that i donāt use in my game (just for example).
i fall into the second category. if i want to change a character, i redo it from scratch. because in my case i canāt do anything elseā¦i donāt think iām the only one.
as I said above iām in favor to have both systemā¦cos spritesheets are useless ifāuāre with HD characters.
egā¦iāve a character with 256x256 px with an ani of 15 frames it means to havve a spritesheet of at least 2000 in widthā¦thaz badā¦(i worked in anims for years ā¦i know what iām saying)
Just sayingā¦some game that can be developed with the actual systemā¦will not be possible to develops laterā¦ thatās not an improvement.
I am not sure i get you so correct me if im wrong
But if i get it right
Then no one is here voting for replacing sprite object with spritesheet object
This whole topic is about adding additional feature either to sprite object or creating 2nd object same as sprite object which would use spritesheet
kinda same as text object was not replaced by bbtext or bitmap text but we have 3 unique objects for each case
And personally i would opt out from this approach if we lose one in favor of another
Then iāve nothing to blame as long as the old anim system stay untouchedā¦(or improved)
Iām saying this bcs the only other engine that use the same method is Game maker.
In other 2d engines iāve tested that use the spritesheets as the only available method to make an animation youāre idd forced to create a spritesheet so the animatin follow the ids of eachframe in the sheetā¦this imply the use of low res imagesā¦since anything above will results in an oversized thing to read by the engine.
ā¦imho the actual anim system of GD is something to be proud ofā¦
Just saying iām ok with sprithesheet but i donāt want to be forced to use them to make an animationā¦and honestly when i started, this was the thing which let me chose GD.
I agree with you on this one.
Putting some logic here
Ever seen any1 complain about current sprite animations system with per image requirement?
I sure donāt
I only seen ppl asking for ADDITIONAL option for using spritesheet
So i would hardly believe that removing current one would be even ever been taken under consideration
Letās hope for the best
Wel you know what i thinkā¦after what happened to undelcared variablesā¦
better get out soon what you have to sayā¦
I am still not fan of declaring vars
BUT it was circling around it
Where sprite animations and sprite sheet animations i really doubt share same fate
Cause animation can have proper names like per image
For example walk1.png walk2.png walk3.png
And idle1.png idle2.png
And if you add these 5 files AT ONCE
You wonāt end up with one animation with 5 frames
But 2 animations one with 3 frames of walk and other with 2 frames of idle
So i would not believe someone care to destroy that
But yeah i canāt agree more
Better to be sorry for complaining
Then be sorry for not pointing it out when there was chance to prevent bad change
there where good reasons for that one, I stick to my sugestion that the best course of action is making a new spriteSheetObject completely dedicated to be used with sprites sheets, that way it wonāt even be noticed by the people who donāt need it.
And i have no doubtā¦but as i said in its threadā¦it was a feature.
I guess it is what they gonna doā¦weāll see
The idea for sprite-sheet internalization is that boundaries of a sprite-sheet elements are based on intelligent padding determination and intelligent sprite size; dimensions.
One goes through with a algorithm of optimum universal satisfactory result; to detect the padding determination for each sprite in the sheet; in such a way that all sliced and or non-sliced sprites are uniform as one whole image; which then in practical usage; can be crop cycled with the usual accumulator frame step and or modulo frame step algorithm techniques or otherwise.
In the main; render loop you would do:
(delta is very confusing; but it requires getting the current time before the main loop and then checking it again before or after not sure with present time then subtracting them together to get a summation; which I think is known as delta-time;
I think)
var current_time = now.currenttime();
while loop:
var present_time = now.currenttime();
delta = current_time - present_time;
accumulator++
if accumulator >= delta * 1000 (1 second)
framestep += 1;
when framestep >= 4
framestep -= 4;
canvas.draw_image(x_pos, y_pos,
sprite_size_width, sprite_size_height,
scale_x, scale_y, x_des, y_des, etc);
accumulater -= accumulator;
x_des would be something like:
sprite_size * framestep
Probably missing something;
but thatās generally the frame-step with an accumulator method.
As for anything else; like determining padding boundaries of a sprite element; good gosh; think it has to do with how central all the sprites are in an geometric/block sequence strip; If there not central enough then the padding is not accurate; so however; youād do that in codeā¦ Id love to know in a very simple and easy to understand way.
Think; it requires using geometric primitives and image pixel edge checking
and avoiding overlap.
Hope that helps; somewhere and somehow.
sprite sheets would be really good to have as a separate object that people can use only with sprite sheets
Instead of editing one image at the time you can edit all of them at once saving time
like people who want to make big projects on gdevelop would greatly benefit from that option especially when they want to release it on itch.io
and we should keep the old system as it is since for example if a object only needs one image then we shouldnāt force it to be a sprite sheet object
also old system is easier to understand and friendly to newcomers