Import Sprite Sheets / Core sprite sheet support

[Maji]

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.

[RMDB]

For what matter,
imo this should not replace the old animation/sprite system,
but should be an addition on what we have now.

[Digi-Device_File]

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.

[kikiki]

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?

[ZeroX4]

What Silver suggest is best solution i seen so far when it comes to not generating tons of images

Import Sprite Sheets / Core sprite sheet support

To revisit this, I’ve recently done digging elsewhere, and it seems like a lot of other engines are close to what I’d consider the optimal solutions on this: The equivalent to sprite objects always use sprite atlas/spritesheets in the final exported project. (Many engines actually bundle all 2D textures into atlases upon export regardless of object type) If a user imports individual frames, they’re packed into a sprite atlas in the exported project. For GDevelop, this would likely mean using …

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

[RMDB]

@ZeroX4

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.

[ZeroX4]

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

[RMDB]

@ZeroX4

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

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.

@ZeroX4

same as text object was not replaced by bbtext or bitmap text but we have 3 unique objects for each case

I agree with you on this one.

[ZeroX4]

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

[RMDB]

Wel you know what i think…after what happened to undelcared variables…
better get out soon what you have to say…

[ZeroX4]

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

[Digi-Device_File]

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.

[RMDB]

@Digi-Device_File

there where good reasons for that one

And i have no doubt…but as i said in its thread…it was a feature.

@Digi-Device_File

is making a new spriteSheetObject completely dedicated to be used with sprites sheets,

I guess it is what they gonna do…we’ll see

[xuniversax]

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.