Is the format of the image labels in the copy-paste documented?

[dunbaratu]

When you copy a program from the game and paste it into an external text file, the image lablels seem to be stored using something that looks vaguely like a Base64 encoding string, or at least something along those grounds.

Is there any documentation on what that format actually is? I assume it's storing the brush stroke path information, rather than a bitmap, given how the labels work in the game.

It might be nice to be able to read those dumps and render them in, say HTML, but to do so first requires being able to transform those label dumps into something rendered.

[Grim Leaper]

I agree that the comments must be in the form of vector graphics, partly because the amount of data is pretty small.

It does seem to be MIME/Base64 encoded (once you remove the newlines and semicolon), but I haven't been able to interpret the decoded bytes.

[szendont]

I've managed to reverse engineer it.
Here's a bit of ugly code that generates 15 vertical lines as a label/comment:
https://gist.github.com/szendo/045f01668f976691ff6b (requires Java 8)

EDIT: Here's a program to display them:
https://gist.github.com/szendo/4df27a857000deb18cf9 (also Java 8)
Use Ctrl+Enter to draw the label/comment in the textarea.

[Grim Leaper]

Автор сообщения: sendow

I've managed to reverse engineer it.
Here's a bit of ugly code that generates 15 vertical lines as a label/comment:
https://gist.github.com/sendow/045f01668f976691ff6b (requires Java 8)

EDIT: Here's a program to display them:
https://gist.github.com/sendow/4df27a857000deb18cf9 (also Java 8)
Use Ctrl+Enter to draw the label/comment in the textarea.

Nice work sendow!

[Gimlao]

So... is there a way to show the original code behind this one, for example ?

DEFINE LABEL 0
eJwzZmBgEFV9vn2F/mTfTyYMYJBgycAQYa2hrOfK2yftdtLtuLu34UVPT5Va74VyWT4Nstt9nyg8jmpI
UkqPW5aWvezQglzXm3vzbF+9zQv7A9K/vIbp+vUaZ6fUWnuNprp16r97XP23TM3Ospkn3qWz5NzSo8vC
tjcvl99nviz5AEh9a3PX4jVtxfPm9MztM5juWLVswZICkHjHRuGtq/YwtF458ifr5rnvAbvv5xrJPDXR
AcnN3ZprdOa4Rob9Pc91i19EXaz4JPuNYRSMglFAMgAAt7NWvA;

[szendont]

Автор сообщения: Gimlao

So... is there a way to show the original code behind this one, for example ?

DEFINE LABEL 0
eJwzZmBgEFV9vn2F/mTfTyYMYJBgycAQYa2hrOfK2yftdtLtuLu34UVPT5Va74VyWT4Nstt9nyg8jmpI
UkqPW5aWvezQglzXm3vzbF+9zQv7A9K/vIbp+vUaZ6fUWnuNprp16r97XP23TM3Ospkn3qWz5NzSo8vC
tjcvl99nviz5AEh9a3PX4jVtxfPm9MztM5juWLVswZICkHjHRuGtq/YwtF458ifr5rnvAbvv5xrJPDXR
AcnN3ZprdOa4Rob9Pc91i19EXaz4JPuNYRSMglFAMgAAt7NWvA;

What do you mean by original code?
The code on the 2nd link can display it: http://i.imgur.com/vzdOLYP.png

[Gimlao]

I was excepting some code like this, once decoded :

<line x1="5" y1="5" x2="250" y2="95" stroke="black" />

And so on. ^^;

[szendont]

Okay, well the format is binary so it's not going to be that easy to understand, but I made an infographic to explain it: http://i.imgur.com/ACRhCtF.png

(EDIT: updated the infographic based on new info from dev)

[allanblomquist]

very cool infographic!

[szendont]

Автор сообщения: allanblomquist

very cool infographic!

Thanks. Can you shed some light on the purpose of the bytes at offset 1-3? :)
Whenever I set any them to non-zero values my picture got replaced with a dot in the middle.
Is it reserved for future use? Or just struct padding?

[Aap op Sokken]

Silly side-effect: From a solution copy, most likely you can reconstruct the resolution the game was running in when the labels were created.

[allanblomquist]

Автор сообщения: sendow

Автор сообщения: allanblomquist

very cool infographic!

Thanks. Can you shed some light on the purpose of the bytes at offset 1-3? :)
Whenever I set any them to non-zero values my picture got replaced with a dot in the middle.
Is it reserved for future use? Or just struct padding?

those first 4 bytes are a little endian 32bit word for the count of the number of points. the count can never be more than 256 so 2 of those bytes are not ever going to actually be used. a single dot is the dummy data that gets substituted in if a drawing fails to decode as expected.

[szendont]

Автор сообщения: allanblomquist

Автор сообщения: sendow

Thanks. Can you shed some light on the purpose of the bytes at offset 1-3? :)
Whenever I set any them to non-zero values my picture got replaced with a dot in the middle.
Is it reserved for future use? Or just struct padding?

those first 4 bytes are a little endian 32bit word for the count of the number of points. the count can never be more than 256 so 2 of those bytes are not ever going to actually be used. a single dot is the dummy data that gets substituted in if a drawing fails to decode as expected.

I'm not sure it can be 256 either, even when I set it to 00 01 00 00 it gets substituted.

[allanblomquist]

Автор сообщения: sendow

Автор сообщения: allanblomquist

those first 4 bytes are a little endian 32bit word for the count of the number of points. the count can never be more than 256 so 2 of those bytes are not ever going to actually be used. a single dot is the dummy data that gets substituted in if a drawing fails to decode as expected.

I'm not sure it can be 256 either, even when I set it to 00 01 00 00 it gets substituted.

you're absolutely right and just helped me find a bug in the game. :) when i originally wrote that, i double checked that you were able to generate a drawing with 256 points in the game. however, looking at the importing code now, i see that the game only accepts drawings with fewer than 256 points. that means that it's possible to make a drawing, copy it out, and when you try to paste it back in the game rejects the drawing you just made. ( http://pastebin.com/7J9gsx3J )

[szendont]

Автор сообщения: allanblomquist

Автор сообщения: sendow

I'm not sure it can be 256 either, even when I set it to 00 01 00 00 it gets substituted.

you're absolutely right and just helped me find a bug in the game. :) when i originally wrote that, i double checked that you were able to generate a drawing with 256 points in the game. however, looking at the importing code now, i see that the game only accepts drawings with fewer than 256 points. that means that it's possible to make a drawing, copy it out, and when you try to paste it back in the game rejects the drawing you just made. ( http://pastebin.com/7J9gsx3J )

Glad I could help. It's weird though because when I've tested how many point the game would let me draw I only got 255 points, that's why I assumed its only one byte storing the count. If you check the revisions of my gists you can see I've even changed them according to this :D

[allanblomquist]

Автор сообщения: sendow

Автор сообщения: allanblomquist

you're absolutely right and just helped me find a bug in the game. :) when i originally wrote that, i double checked that you were able to generate a drawing with 256 points in the game. however, looking at the importing code now, i see that the game only accepts drawings with fewer than 256 points. that means that it's possible to make a drawing, copy it out, and when you try to paste it back in the game rejects the drawing you just made. ( http://pastebin.com/7J9gsx3J )

Glad I could help. It's weird though because when I've tested how many point the game would let me draw I only got 255 points, that's why I assumed its only one byte storing the count. If you check the revisions of my gists you can see I've even changed them according to this :D

yeah it's actually kind of hard to get one with exactly 256, which is probably why i never caught this before. with the benefit of being able to put a breakpoint into the code to let me know once i had one, i was able to keep mashing around and undoing a little until it worked. i assume it just has to do with the way the game is trying to reserve enough space for a null terminator as you draw and the interaction of that with the polyline simplification that happens when you release each stroke, but i haven't looked into it in detail yet.