2013-09-22 23:02:43 +04:00
|
|
|
(function () {
|
|
|
|
var ns = $.namespace('pskl.utils');
|
fix : reduce piskel model size
- Initial implementation : working but ...
- MODEL_VERSION has been bumped to 2
- The loading process is now theoretically asynchronous (loading images to
read the content of the layers), but for now, the asynchronous behaviour
is hidden behind a nasty hack, which is somehow similar to lazy loading.
When loading the piskel, a Piskel is created synchronously, with fake
empty frames, and as the images will get loaded, the fake frames will be
replaced by the actual frames.
I really don't like this, and the asynchronous nature of the loading
should be clearly expressed
- There is no backward compatible deserializer for the previous version of
the model (1)
- The Serializer utils is just badly designed. Serialization and
deserialization should be splitted into two different classes
- Saving & loading are still done in app.js and should be moved to
services
BUT : the size of the piskels is now pretty small. A piskel which was
using 890kB previously is now using only 10kB. Although it should be
noted, that after gzip there is no significant difference between this
version and the existing one. The only gains we can really expect with
this are : less disk space used on appengine, ability to reuse the
layers' pngs directly on piskel-website (but to be honest I can't see any
valid use case for this)
2013-11-08 03:44:24 +04:00
|
|
|
|
|
|
|
var layersToLoad = 0;
|
|
|
|
|
2013-09-22 23:02:43 +04:00
|
|
|
ns.Serializer = {
|
|
|
|
serializePiskel : function (piskel) {
|
|
|
|
var serializedLayers = piskel.getLayers().map(function (l) {
|
|
|
|
return pskl.utils.Serializer.serializeLayer(l);
|
|
|
|
});
|
|
|
|
return JSON.stringify({
|
|
|
|
modelVersion : Constants.MODEL_VERSION,
|
|
|
|
piskel : {
|
|
|
|
height : piskel.getHeight(),
|
|
|
|
width : piskel.getWidth(),
|
|
|
|
layers : serializedLayers
|
|
|
|
}
|
|
|
|
});
|
|
|
|
},
|
|
|
|
|
|
|
|
serializeLayer : function (layer) {
|
fix : reduce piskel model size
- Initial implementation : working but ...
- MODEL_VERSION has been bumped to 2
- The loading process is now theoretically asynchronous (loading images to
read the content of the layers), but for now, the asynchronous behaviour
is hidden behind a nasty hack, which is somehow similar to lazy loading.
When loading the piskel, a Piskel is created synchronously, with fake
empty frames, and as the images will get loaded, the fake frames will be
replaced by the actual frames.
I really don't like this, and the asynchronous nature of the loading
should be clearly expressed
- There is no backward compatible deserializer for the previous version of
the model (1)
- The Serializer utils is just badly designed. Serialization and
deserialization should be splitted into two different classes
- Saving & loading are still done in app.js and should be moved to
services
BUT : the size of the piskels is now pretty small. A piskel which was
using 890kB previously is now using only 10kB. Although it should be
noted, that after gzip there is no significant difference between this
version and the existing one. The only gains we can really expect with
this are : less disk space used on appengine, ability to reuse the
layers' pngs directly on piskel-website (but to be honest I can't see any
valid use case for this)
2013-11-08 03:44:24 +04:00
|
|
|
var frames = layer.getFrames();
|
|
|
|
var renderer = new pskl.rendering.FramesheetRenderer(frames);
|
|
|
|
var base64PNG = renderer.renderAsCanvas().toDataURL();
|
|
|
|
|
2013-09-22 23:02:43 +04:00
|
|
|
return JSON.stringify({
|
|
|
|
name : layer.getName(),
|
fix : reduce piskel model size
- Initial implementation : working but ...
- MODEL_VERSION has been bumped to 2
- The loading process is now theoretically asynchronous (loading images to
read the content of the layers), but for now, the asynchronous behaviour
is hidden behind a nasty hack, which is somehow similar to lazy loading.
When loading the piskel, a Piskel is created synchronously, with fake
empty frames, and as the images will get loaded, the fake frames will be
replaced by the actual frames.
I really don't like this, and the asynchronous nature of the loading
should be clearly expressed
- There is no backward compatible deserializer for the previous version of
the model (1)
- The Serializer utils is just badly designed. Serialization and
deserialization should be splitted into two different classes
- Saving & loading are still done in app.js and should be moved to
services
BUT : the size of the piskels is now pretty small. A piskel which was
using 890kB previously is now using only 10kB. Although it should be
noted, that after gzip there is no significant difference between this
version and the existing one. The only gains we can really expect with
this are : less disk space used on appengine, ability to reuse the
layers' pngs directly on piskel-website (but to be honest I can't see any
valid use case for this)
2013-11-08 03:44:24 +04:00
|
|
|
base64PNG : base64PNG,
|
|
|
|
frameCount : frames.length
|
2013-09-22 23:02:43 +04:00
|
|
|
});
|
|
|
|
},
|
|
|
|
|
2013-10-10 02:06:11 +04:00
|
|
|
/**
|
fix : reduce piskel model size
- Initial implementation : working but ...
- MODEL_VERSION has been bumped to 2
- The loading process is now theoretically asynchronous (loading images to
read the content of the layers), but for now, the asynchronous behaviour
is hidden behind a nasty hack, which is somehow similar to lazy loading.
When loading the piskel, a Piskel is created synchronously, with fake
empty frames, and as the images will get loaded, the fake frames will be
replaced by the actual frames.
I really don't like this, and the asynchronous nature of the loading
should be clearly expressed
- There is no backward compatible deserializer for the previous version of
the model (1)
- The Serializer utils is just badly designed. Serialization and
deserialization should be splitted into two different classes
- Saving & loading are still done in app.js and should be moved to
services
BUT : the size of the piskels is now pretty small. A piskel which was
using 890kB previously is now using only 10kB. Although it should be
noted, that after gzip there is no significant difference between this
version and the existing one. The only gains we can really expect with
this are : less disk space used on appengine, ability to reuse the
layers' pngs directly on piskel-website (but to be honest I can't see any
valid use case for this)
2013-11-08 03:44:24 +04:00
|
|
|
* @param {Object} data JSON.parse of a serialized piskel
|
2013-10-10 15:35:18 +04:00
|
|
|
* @return {pskl.model.Piskel} a piskel
|
2013-10-10 02:06:11 +04:00
|
|
|
*/
|
fix : reduce piskel model size
- Initial implementation : working but ...
- MODEL_VERSION has been bumped to 2
- The loading process is now theoretically asynchronous (loading images to
read the content of the layers), but for now, the asynchronous behaviour
is hidden behind a nasty hack, which is somehow similar to lazy loading.
When loading the piskel, a Piskel is created synchronously, with fake
empty frames, and as the images will get loaded, the fake frames will be
replaced by the actual frames.
I really don't like this, and the asynchronous nature of the loading
should be clearly expressed
- There is no backward compatible deserializer for the previous version of
the model (1)
- The Serializer utils is just badly designed. Serialization and
deserialization should be splitted into two different classes
- Saving & loading are still done in app.js and should be moved to
services
BUT : the size of the piskels is now pretty small. A piskel which was
using 890kB previously is now using only 10kB. Although it should be
noted, that after gzip there is no significant difference between this
version and the existing one. The only gains we can really expect with
this are : less disk space used on appengine, ability to reuse the
layers' pngs directly on piskel-website (but to be honest I can't see any
valid use case for this)
2013-11-08 03:44:24 +04:00
|
|
|
createPiskel : function (data) {
|
2013-10-05 00:59:42 +04:00
|
|
|
var piskel = null;
|
fix : reduce piskel model size
- Initial implementation : working but ...
- MODEL_VERSION has been bumped to 2
- The loading process is now theoretically asynchronous (loading images to
read the content of the layers), but for now, the asynchronous behaviour
is hidden behind a nasty hack, which is somehow similar to lazy loading.
When loading the piskel, a Piskel is created synchronously, with fake
empty frames, and as the images will get loaded, the fake frames will be
replaced by the actual frames.
I really don't like this, and the asynchronous nature of the loading
should be clearly expressed
- There is no backward compatible deserializer for the previous version of
the model (1)
- The Serializer utils is just badly designed. Serialization and
deserialization should be splitted into two different classes
- Saving & loading are still done in app.js and should be moved to
services
BUT : the size of the piskels is now pretty small. A piskel which was
using 890kB previously is now using only 10kB. Although it should be
noted, that after gzip there is no significant difference between this
version and the existing one. The only gains we can really expect with
this are : less disk space used on appengine, ability to reuse the
layers' pngs directly on piskel-website (but to be honest I can't see any
valid use case for this)
2013-11-08 03:44:24 +04:00
|
|
|
if (data.modelVersion == Constants.MODEL_VERSION) {
|
|
|
|
var piskelData = data.piskel;
|
|
|
|
piskel = new pskl.model.Piskel(piskelData.width, piskelData.height);
|
2013-11-14 01:57:07 +04:00
|
|
|
|
fix : reduce piskel model size
- Initial implementation : working but ...
- MODEL_VERSION has been bumped to 2
- The loading process is now theoretically asynchronous (loading images to
read the content of the layers), but for now, the asynchronous behaviour
is hidden behind a nasty hack, which is somehow similar to lazy loading.
When loading the piskel, a Piskel is created synchronously, with fake
empty frames, and as the images will get loaded, the fake frames will be
replaced by the actual frames.
I really don't like this, and the asynchronous nature of the loading
should be clearly expressed
- There is no backward compatible deserializer for the previous version of
the model (1)
- The Serializer utils is just badly designed. Serialization and
deserialization should be splitted into two different classes
- Saving & loading are still done in app.js and should be moved to
services
BUT : the size of the piskels is now pretty small. A piskel which was
using 890kB previously is now using only 10kB. Although it should be
noted, that after gzip there is no significant difference between this
version and the existing one. The only gains we can really expect with
this are : less disk space used on appengine, ability to reuse the
layers' pngs directly on piskel-website (but to be honest I can't see any
valid use case for this)
2013-11-08 03:44:24 +04:00
|
|
|
piskelData.layers.forEach(function (serializedLayer) {
|
2013-10-05 00:59:42 +04:00
|
|
|
var layer = pskl.utils.Serializer.deserializeLayer(serializedLayer);
|
2013-09-22 23:02:43 +04:00
|
|
|
piskel.addLayer(layer);
|
|
|
|
});
|
fix : reduce piskel model size
- Initial implementation : working but ...
- MODEL_VERSION has been bumped to 2
- The loading process is now theoretically asynchronous (loading images to
read the content of the layers), but for now, the asynchronous behaviour
is hidden behind a nasty hack, which is somehow similar to lazy loading.
When loading the piskel, a Piskel is created synchronously, with fake
empty frames, and as the images will get loaded, the fake frames will be
replaced by the actual frames.
I really don't like this, and the asynchronous nature of the loading
should be clearly expressed
- There is no backward compatible deserializer for the previous version of
the model (1)
- The Serializer utils is just badly designed. Serialization and
deserialization should be splitted into two different classes
- Saving & loading are still done in app.js and should be moved to
services
BUT : the size of the piskels is now pretty small. A piskel which was
using 890kB previously is now using only 10kB. Although it should be
noted, that after gzip there is no significant difference between this
version and the existing one. The only gains we can really expect with
this are : less disk space used on appengine, ability to reuse the
layers' pngs directly on piskel-website (but to be honest I can't see any
valid use case for this)
2013-11-08 03:44:24 +04:00
|
|
|
} else if (data.modelVersion == 1) {
|
2013-11-14 01:57:07 +04:00
|
|
|
piskel = pskl.utils.Serializer.backwardDeserializer_v1(data);
|
2013-09-22 23:02:43 +04:00
|
|
|
} else {
|
fix : reduce piskel model size
- Initial implementation : working but ...
- MODEL_VERSION has been bumped to 2
- The loading process is now theoretically asynchronous (loading images to
read the content of the layers), but for now, the asynchronous behaviour
is hidden behind a nasty hack, which is somehow similar to lazy loading.
When loading the piskel, a Piskel is created synchronously, with fake
empty frames, and as the images will get loaded, the fake frames will be
replaced by the actual frames.
I really don't like this, and the asynchronous nature of the loading
should be clearly expressed
- There is no backward compatible deserializer for the previous version of
the model (1)
- The Serializer utils is just badly designed. Serialization and
deserialization should be splitted into two different classes
- Saving & loading are still done in app.js and should be moved to
services
BUT : the size of the piskels is now pretty small. A piskel which was
using 890kB previously is now using only 10kB. Although it should be
noted, that after gzip there is no significant difference between this
version and the existing one. The only gains we can really expect with
this are : less disk space used on appengine, ability to reuse the
layers' pngs directly on piskel-website (but to be honest I can't see any
valid use case for this)
2013-11-08 03:44:24 +04:00
|
|
|
piskel = pskl.utils.Serializer.backwardDeserializer_(data);
|
2013-09-22 23:02:43 +04:00
|
|
|
}
|
2013-10-05 00:59:42 +04:00
|
|
|
|
|
|
|
return piskel;
|
2013-09-22 23:02:43 +04:00
|
|
|
},
|
|
|
|
|
2013-10-10 02:06:11 +04:00
|
|
|
deserializeLayer : function (layerString) {
|
fix : reduce piskel model size
- Initial implementation : working but ...
- MODEL_VERSION has been bumped to 2
- The loading process is now theoretically asynchronous (loading images to
read the content of the layers), but for now, the asynchronous behaviour
is hidden behind a nasty hack, which is somehow similar to lazy loading.
When loading the piskel, a Piskel is created synchronously, with fake
empty frames, and as the images will get loaded, the fake frames will be
replaced by the actual frames.
I really don't like this, and the asynchronous nature of the loading
should be clearly expressed
- There is no backward compatible deserializer for the previous version of
the model (1)
- The Serializer utils is just badly designed. Serialization and
deserialization should be splitted into two different classes
- Saving & loading are still done in app.js and should be moved to
services
BUT : the size of the piskels is now pretty small. A piskel which was
using 890kB previously is now using only 10kB. Although it should be
noted, that after gzip there is no significant difference between this
version and the existing one. The only gains we can really expect with
this are : less disk space used on appengine, ability to reuse the
layers' pngs directly on piskel-website (but to be honest I can't see any
valid use case for this)
2013-11-08 03:44:24 +04:00
|
|
|
var layerData = JSON.parse(layerString);
|
|
|
|
var layer = new pskl.model.Layer(layerData.name);
|
|
|
|
// TODO : nasty trick to keep the whole loading process lazily synchronous
|
|
|
|
// 1 - adding a fake frame so that the rendering can start
|
|
|
|
layer.addFrame(new pskl.model.Frame(32,32));
|
|
|
|
|
|
|
|
// 2 - create an image to load the base64PNG representing the layer
|
|
|
|
var base64PNG = layerData.base64PNG;
|
|
|
|
var image = new Image();
|
|
|
|
|
|
|
|
// 3 - attach the onload callback that will be triggered asynchronously
|
|
|
|
image.onload = function () {
|
|
|
|
// 6 - remove the fake frame
|
|
|
|
layer.removeFrameAt(0);
|
|
|
|
|
|
|
|
// 7 - extract the frames from the loaded image
|
|
|
|
var frames = pskl.utils.LayerUtils.createFromImage(image, layerData.frameCount);
|
|
|
|
|
|
|
|
// 8 - add each image to the layer
|
|
|
|
frames.forEach(function (frame) {
|
|
|
|
layer.addFrame(pskl.model.Frame.fromPixelGrid(frame));
|
|
|
|
});
|
|
|
|
};
|
|
|
|
|
|
|
|
// 4 - set the source of the image
|
|
|
|
image.src = base64PNG;
|
|
|
|
|
|
|
|
// 5 - return a pointer to the new layer instance, which at this point contains a fake frame
|
|
|
|
return layer;
|
|
|
|
},
|
2013-10-05 00:59:42 +04:00
|
|
|
|
2013-11-14 01:57:07 +04:00
|
|
|
deserializeFrame : function (frameString) {
|
|
|
|
var framePixelGrid = JSON.parse(frameString);
|
|
|
|
return pskl.model.Frame.fromPixelGrid(framePixelGrid);
|
|
|
|
},
|
|
|
|
|
|
|
|
backwardDeserializer_v1 : function (data) {
|
|
|
|
var piskelData = data.piskel;
|
|
|
|
var piskel = new pskl.model.Piskel(piskelData.width, piskelData.height);
|
|
|
|
|
|
|
|
piskelData.layers.forEach(function (serializedLayer) {
|
|
|
|
var layer = pskl.utils.Serializer.deserializeLayer_v1(serializedLayer);
|
|
|
|
piskel.addLayer(layer);
|
|
|
|
});
|
|
|
|
|
|
|
|
return piskel;
|
|
|
|
},
|
|
|
|
|
fix : reduce piskel model size
- Initial implementation : working but ...
- MODEL_VERSION has been bumped to 2
- The loading process is now theoretically asynchronous (loading images to
read the content of the layers), but for now, the asynchronous behaviour
is hidden behind a nasty hack, which is somehow similar to lazy loading.
When loading the piskel, a Piskel is created synchronously, with fake
empty frames, and as the images will get loaded, the fake frames will be
replaced by the actual frames.
I really don't like this, and the asynchronous nature of the loading
should be clearly expressed
- There is no backward compatible deserializer for the previous version of
the model (1)
- The Serializer utils is just badly designed. Serialization and
deserialization should be splitted into two different classes
- Saving & loading are still done in app.js and should be moved to
services
BUT : the size of the piskels is now pretty small. A piskel which was
using 890kB previously is now using only 10kB. Although it should be
noted, that after gzip there is no significant difference between this
version and the existing one. The only gains we can really expect with
this are : less disk space used on appengine, ability to reuse the
layers' pngs directly on piskel-website (but to be honest I can't see any
valid use case for this)
2013-11-08 03:44:24 +04:00
|
|
|
deserializeLayer_v1 : function (layerString) {
|
|
|
|
var layerData = JSON.parse(layerString);
|
|
|
|
var layer = new pskl.model.Layer(layerData.name);
|
|
|
|
layerData.frames.forEach(function (serializedFrame) {
|
2013-10-05 00:59:42 +04:00
|
|
|
var frame = pskl.utils.Serializer.deserializeFrame(serializedFrame);
|
2013-09-22 23:02:43 +04:00
|
|
|
layer.addFrame(frame);
|
|
|
|
});
|
2013-10-05 00:59:42 +04:00
|
|
|
|
2013-09-22 23:02:43 +04:00
|
|
|
return layer;
|
|
|
|
},
|
|
|
|
|
2013-10-05 00:59:42 +04:00
|
|
|
/**
|
|
|
|
* Deserialize old piskel framesheets. Initially piskels were stored as arrays of frames : "[[pixelGrid],[pixelGrid],[pixelGrid]]".
|
|
|
|
*/
|
2013-10-05 01:55:45 +04:00
|
|
|
backwardDeserializer_ : function (frames) {
|
2013-10-05 00:59:42 +04:00
|
|
|
var layer = new pskl.model.Layer('Layer 1');
|
|
|
|
frames.forEach(function (frame) {
|
|
|
|
layer.addFrame(pskl.model.Frame.fromPixelGrid(frame));
|
|
|
|
});
|
|
|
|
var width = layer.getFrameAt(0).getWidth(), height = layer.getFrameAt(0).getHeight();
|
|
|
|
var piskel = new pskl.model.Piskel(width, height);
|
|
|
|
piskel.addLayer(layer);
|
|
|
|
|
|
|
|
return piskel;
|
2013-09-22 23:02:43 +04:00
|
|
|
}
|
|
|
|
};
|
2013-10-10 15:35:18 +04:00
|
|
|
})();
|