Piskel layers

[Atomiz2002]

I found out that when you use a layers in piskel in GDevelop when i save the image it merges the layers and i cant edit the image using them again, i have to make new layers and split the image on them. I cant say this is a bug but it would be better without it.
Also the layers cant be renamed...i checked the browser version and it uses dialog box to ask for the new name of the layer you want to set, but this doesnt happen in GDevelop. Probably cause GDevelop isnt a browser, anyways you might want to find other way of asking about the name.

[blurymind]

This is the next thing I will work on, after jsfx is completed
#695

[blurymind]

sorry, this will wait a bit. I am working on replacing jsfx by jfxr

[4ian]

No worries, jfxr will be great addition :)

[blurymind]

On the subject of layers - I wonder if the layer metadata should be stored on the first frame image resource or all of them?

If it's on the first - it is possible that the user moves its index or removes it in GD and that deletes the data. If it's on all of them then we have a json project file full of repetition of a very long string.

One alternative is to save the piskel file in the project's folder and store the relative path to it as metadata - then having the path in each frame image resource won't be as bad.
It would be great if an image sequence could be treated as singular resource. One thing that comes to mind is having a tileset of all the frames in a single image- but GD5 still doesnt have the capability for that

[4ian]

If it's on all of them then we have a json project file full of repetition of a very long string.

How long it is? What is the kind of information stored?

I wonder if in this case it's metadata that should be stored on the animation (well, the direction to be precise).

[4ian]

To be a bit more precise, I think it can be a new, optional parameter, passed to onChangesSaved that would contain information about all the resources (as opposed as the first parameter, which are information per resource). This could then be stored in the direction. If you think that can work, I can add a getter/setter for metadata for gd.Direction.

[blurymind]

@4ian that is a great idea! In this case it makes a lot of sense to store it in the direction!
Can you add the getter/setter please :)

[blurymind]

@4ian Just for reference, this is the example megaman sprite that has three frames. I added another layer to it, called 'Hat'

{  
   "modelVersion":2,
   "piskel":{  
      "name":"Megaman moving",
      "description":"",
      "fps":2,
      "height":28,
      "width":31,
      "layers":[  
         "{\"name\":\"Layer 1\",\"opacity\":1,\"frameCount\":3,\"chunks\":[{\"layout\":[[0],[1],[2]],\"base64PNG\":\"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAF0AAAAcCAYAAAADdbMKAAACi0lEQVRoQ+2Yu3HDMAyG6SoaI2XmSJE5MoY7253HyBwpMkdKj8FUzvEBCgTfEgn5EqnyWRR+8gMIAjyI/WEncGBX3AXFGuh3xG+NnSVu2Eq7i+4SWE748mV+nl61mSW2WoFvpd1VtxXUXRzlDOo6CUbwW2l3122B7osD+utEo7XFZm2kb6U9RLcFUHICLto/f4QwTmixWwN+K+0hurVw7grsSUGNPRDtKvX0h76V9jDdEnTvAAHo8v0sxPPZ4Z/sT3kWYpq6RXpaGzl++jDiak7Ty7XHLhu+5hR0LYwPSYh0DNwCFvL7qBcspewBPa+dSUYrobOtOQZdbyv66LLwKHVEQZRXQqfGcrurqG3BuumBwxM9Q612UbfnmikAfXBc3p7y0NVblF7EzTri5rb4/D0pMTMNVb12ItqpQ2h5m3QM85qj0GFyCr6KcK8Wt9Geizg6HjsR7EUaKq9SYNRm181C15WIrUgwSLWl6aOcQNMSpCRvLLJJSsugCWHSZteN5nS3LQGQohZ2nx7L3DngBvqN1CNpz+AZ1pyuXnAuJtBjKdWmC/pK2a89zODbsCFBDh+ozaabrSRwxMciGQAMuPDyIo9Rm0W3rjmyUZ+savq3/cqfZofwaw/XLUE3i6epBu/x/m0/tr6V9lDdEvTs/QOUdQMuuLSzc/c9A7WH61Z3h/Syi9bencF7HSKjNotutnqhORwqFHywOSD90ky0M2XQZtMNmyN0eKmfAJ5UKNHyamW0ewfYX9YG6MGCgy7Sr1DCLm7+oHRO0FL732mb5qWtOmkdn7ie0n+32mod/5DasY4xNlEcveG9b/hFbbS32modn4eee2veDVl3LZzy9PYR1QR26NWo+g38BXXvWDvG9IC5AAAAAElFTkSuQmCC\"}]}",
         "{\"name\":\"hat\",\"opacity\":1,\"frameCount\":3,\"chunks\":[{\"layout\":[[0],[1],[2]],\"base64PNG\":\"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAF0AAAAcCAYAAAADdbMKAAABHklEQVRoQ+2WwQ7DIAxD6Y3//1punahAYtCSBJg8Ku+yaoPYfvGkHW7sdVbXjrEx29yq89bGTflNh5NSz8DIPAv5peGVwpJmHqPOrj5YAw8hXB957118ju/OOes8Ze7r2PLwSvEv3TJ3vF9kV+eXID0GraGnBUjzlDmbY1rg6uBKI42uAF2lL0GyQi+zSLOVuduG5+DlLy0/p6Ez2pYFSxlufUjmZgxIs3uGZ3RnFr9Kt9t4CxirIcvsegFWracFzniQWjz8/V+a6qS5W8ZuGX76b2O4CW+/uF1L3rAQQgdskdAJHUAAIMmmEzqAAECSTSd0AAGAJJtO6AACAEk2ndABBACSbDqhAwgAJNl0QgcQAEiy6YQOIACQZNMB0D/Vmjgd0WJcPAAAAABJRU5ErkJggg==\"}]}"
      ]
   }
}

If is what you will see if you open a *.piskel file with a text editor

[4ian]

Ok so the images are stored in metadata, so clearly we cannot duplicate this.
In all case, it makes sense to store this in the direction. Direction is what is representing a set of frames.

Will try to add metadata to direction in the next days. We would need these metadata passed back during onSaveChanges, also passed passed in to openPiskel. Can you prototype/test like if set/get metadata was available on direction? So that you can spot any issue now rather than after I add metadata ;)

[blurymind]

I can get the pull started, but without being able to set/get the metadata, I wont be able to test properly.
I can use the first image resource to do it instead for now - and once you have it implemented for direction - use direction instead.
Even with that there will be some odd corner cases - such as changing the order in gdevelop and opening in piskel to find the order from the metadata. Or adding a resource in gdevelop to a direction that uses the piskel metadata

A simple way to address those corner cases is to disable adding resources with gdevelop to resources with piskel metadata and instead open piskel when that happens- so the user adds them in piskel

The way it works is that piskel stores the frames as a horizontal tileset strip of images, which gets converted to a string. So splicing new ones/changing order in the metadata with gdevelop is probably not very trivial

[4ian]

I will add the get/set metadata to Direction this afternoon

[4ian]

@blurymind Delete public/libGD.js, relaunch yarn start/npm start and you should get the version of libGD.js with set/getMetadata on Direction :)

[blurymind]

I started refactoring the code :) Thank you @4ian

[blurymind]

@4ian we might need to also set metadata on tiledSprite object :)
I could set it on the image resource in that case if you want to

[4ian]

If there is only a single image, it's better to store it directly on the ImageResource (so that layers and any saved data can be retrieved from another object using it too)

[4ian]

I'll close the issue as it's tracked in a card on the roadmap made by @blurymind and in the Pull Request opened :)