SpriteAnimation: introduce imageRange#80
SpriteAnimation: introduce imageRange#80eulerscheZahl wants to merge 2 commits intoCodinGame:masterfrom
Conversation
| if (compressed == images) set("images", Stream.of(images).collect(Collectors.joining(",")), null); | ||
| else set("imageRange", compressed[0], null); |
There was a problem hiding this comment.
If a spriteAnimation's images changes from a set to a range or vice versa, the other variable won't be cleared, I fear it would create problems client side
There was a problem hiding this comment.
easiest scenario is if the compressed version also goes inside the images param. maybe with a special prefix
There was a problem hiding this comment.
or just detect the presence of the pipe character
There was a problem hiding this comment.
Nice catch, images and imageRange shouldn't co-exist like this. I'll think about a solution after work. I was a bit scared about checking for the pipe in images because the image name might contain that symbol, breaking things in a different way.
There was a problem hiding this comment.
setting the stale param to "" might be enough
There was a problem hiding this comment.
This indeed did the trick.
- I verified that it was broken by replacing one animation by just a subset if the images
- Changed the code to set an empty string as you suggested. It works fine now
Example of serialization including reset of other parameter:1139 0.001 d 333 I w481,w483,w491 IR ;1148 0.001 I w681,w683,w691 rs 6;1059 0.001 d 1000 I IR w2|21|36. You can also see that the new entity 1148 doesn't reset anything as the value remains unchanged.
I pushed the fix: fa3f2ac
2 participants
SpriteAnimation.setImagescan be quite expensive, as it serializes the whole image sequence. When the animation sequences changes to something else and then changes back (because a character plays an attack animation, changes moving direction, ...), the whole sequence gets serialized again.There is the AnimationModule as an alternative, but it's not as easy to use.
Here is an example from Code Keeper - not even quoting a full frame:
12 0 I c5o12,c5o13,c5o14,c5o15,c5o16,c5o17,c5o18,c5o19,c5o20,c5o21,c5o22,c5o23;1210 0 I c4i21,c4i22,c4i23,c4i24,c4i25,c4i26,c4i27,c4i28,c4i29,c4i30,c4i31,c4i32,c4i33,c4i34,c4i35,c4i36,c4i37,c4i38,c4i39,c4i40,c4i41;1213 0 I c4i21,c4i22,c4i23,c4i24,c4i25,c4i26,c4i27,c4i28,c4i29,c4i30,c4i31,c4i32,c4i33,c4i34,c4i35,c4i36,c4i37,c4i38,c4i39,c4i40,c4i41;
While image names don't have to be in sequence, they are in most scenarios. So it's possible to compress them by just storing the prefix, the first and last suffix.
E.g.
I c5o12,c5o13,c5o14,c5o15,c5o16,c5o17,c5o18,c5o19,c5o20,c5o21,c5o22,c5o23would becomeIR c5o|12|23with this commit.It checks, if image names are in sequence. If they are, the new
imageRangeproperty is used to serialize and deserialize. Otherwise the oldimagesis still used as a fallback solution.From a user perspective nothing changes, this all happens behind the scenes.