At different sizes of images for animation (when opened in Piskel or when using an object in the scene), the images are stretched. What for?
Or if so required, then in the object settings, you also need to show how the picture will look as a result.
When editing an object:
Piskel is a separate application from Gdevelop that is bundled to make image editing easier, and does not support different size frames in the same image file. You do not have to use piskel to make your art, you can always use a general art tool like GIMP, or one specializing in pixel art like Pixelorama, then just add your frame files.
Please note that in general you do not want different size frames for the same animation. This can and will break your hitboxes and potentially also your object point positions.
If you’re needing different visual appearance, you are better off figuring out the maximum height and width of all of your frames, and make the image canvas that size, centering your individual frames, and leaving the rest empty space.
Piskel is a different program with its own peculiarities.
Hitbox and Points are set for the entire animation, as I set it up so it will affect the object, the image has nothing to do with it.
What prevents the engine from automatically placing the image in the center for me? If this is a technical feature that is difficult to fix, then why is it shown “incorrectly” in the object editor?
Correct, that is what I was saying.
This is incorrect, unfortunately. As far as I understand, due to how the underlying rendering engine works (PixiJS), the boundary box has a lot to do with both points and hitboxes. The boundary box for sprite and other graphic objects are based off the sprite size, and it doesn’t support different sizes per frame of a single animation from what I can find looking at PixiJS’s github and docs.
See the above for part of the answer. As far as why it looks correct in the object editor, it’s showing the source images from the files for the frames of the animation, rather than the actual object properties.
Thanks for the clarifications, but I still think that the editor should display what will be in the final.
Regarding PixiJS, does anyone bother to write processing before exporting to render, while solving the problem?
I don’t understand what you’re asking here, so you’re going to need to clarify more before anyone can give you an answer.
Sorry to use a translator because English is not my native language.
Question: why is it impossible to write an algorithm for “processing” images (bringing them to a single size) in the development environment (automatically) and showing them to the user? The result of this algorithm will be aligned and images, which will already be transferred to PixiJS for rendering.
This will help the user to see at a glance what they will get in the game.
Is it possible? Maybe, one of the contributors who have worked on the IDE would have to chime in.
Is it likely to happen? I don’t know. The use case is already very limited, because if you’re making your animations in Piskel it won’t allow you to do it in the first place, same as with image editors when exporting an animated gif like from GIMP or Aesprite.
I also checked on my Unity install and that won’t even let you load images with different canvas sizes into the same animation. It forces them to be the same canvas size. Defold seems to be the same way.
What might be a viable alternative would be to change the object editor to not allow a user to load animation frames with different canvas sizes. If a user attempts to do so, have it display an error explaining why the image was not loaded (e.g. different canvas size than other frames in the animation).
Construct 2 allows it.
This is a solution if there are no other technical possibilities. I suppose that the user should receive a notification if something does not meet the requirements (now it turns out, he sees it already during testing).
I discovered this when I unloaded the character animation from Inkscape, every frame (with the unload setting of the selected object).