Mikal's Forum Posts

  • Sorry, a little hard to understand across Google translator. In the case of other spine animations that we tested, it works well and is centered and scaled properly with a scale setting of 1.

    Some ideas to try:

    - Adding a bounding box to your spine animation.

    - Make sure animation is centered around 0,0 in Spine.

  • I think the scale parameter should just be adjusting the spine rendered texture, not the rendered quad size in the C3 canvas (which it seems to be doing.)

    I'll take a look at it.

    Overall, what scale is used for is to reduce the rendered image size so that it fits in the texture. So, in this case, I do expect that you will need to use a smaller scale (like 0.3), but you can then scale the size up of the Spine object to make it larger when displayed.

  • Ah, yes that's more on par (though the max worst case for 115KB binary is around 153KB for a base64 version, no higher than that.)

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Wow, something strange is going on. If the PNG version is 4KB, the base64 version of the PNG binary (string version) should be around 6KB.

  • Thanks for the alternate method Ashley, here's what I had to do to get that to work for my example (add the data and image info, etc. before base64 string to load the sprite by URL.) 

    -> SpriteDisplay: Load image from "data:image/jpeg;base64,"&BinaryData.GetBase64 (Keep current size, cross-origin anonymous)

    Newt, base64 is larger, but not too bad (33% bigger at most.)

  • Did a little experiment...

    Paste some sprites into a Drawing Canvas, save Drawing canvas, get blobURL, then run a little JS to convert the blob URL to base64, put that in a string and load a Sprite, seems to work (the one caveat is that the Drawing Canvas transparent regions get changed to black...

    So if you want to save a DC as a string which can be used in JSON then load that image back into a sprite, this is one way...

  • Are you trying to save an image (binary) in JSON? Usually, you will need to convert it to base64 (string representation of binary) to save to JSON. So I would look around for that.

    If you have an image to convert, you can use this:

    base64-image.de

    However, then you need to figure out how to load the base64 output into something else to display in C3, which you can easily do!

    For example, you can load it into a sprite through a URL:

    -> Sprite: Load image from "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAMAAADXqc3KAAAB+FBMVEUAAAA/mUPidDHiLi5Cn0XkNTPmeUrkdUg/m0Q0pEfcpSbwaVdKskg+lUP4zA/iLi3msSHkOjVAmETdJSjtYFE/lkPnRj3sWUs8kkLeqCVIq0fxvhXqUkbVmSjwa1n1yBLepyX1xxP0xRXqUkboST9KukpHpUbuvRrzrhF/ljbwaljuZFM4jELaoSdLtElJrUj1xxP6zwzfqSU4i0HYnydMtUlIqUfywxb60AxZqEXaoifgMCXptR9MtklHpEY2iUHWnSjvvRr70QujkC+pUC/90glMuEnlOjVMt0j70QriLS1LtEnnRj3qUUXfIidOjsxAhcZFo0bjNDH0xxNLr0dIrUdmntVTkMoyfL8jcLBRuErhJyrgKyb4zA/5zg3tYFBBmUTmQTnhMinruBzvvhnxwxZ/st+Ktt5zp9hqota2vtK6y9FemNBblc9HiMiTtMbFtsM6gcPV2r6dwroseLrMrbQrdLGdyKoobKbo3Zh+ynrgVllZulTsXE3rV0pIqUf42UVUo0JyjEHoS0HmsiHRGR/lmRz/1hjqnxjvpRWfwtOhusaz0LRGf7FEfbDVmqHXlJeW0pbXq5bec3fX0nTnzmuJuWvhoFFhm0FtrziBsjaAaDCYWC+uSi6jQS3FsSfLJiTirCOkuCG1KiG+wSC+GBvgyhTszQ64Z77KAAAARXRSTlMAIQRDLyUgCwsE6ebm5ubg2dLR0byXl4FDQzU1NDEuLSUgC+vr6urq6ubb29vb2tra2tG8vLu7u7uXl5eXgYGBgYGBLiUALabIAAABsElEQVQoz12S9VPjQBxHt8VaOA6HE+AOzv1wd7pJk5I2adpCC7RUcHd3d3fXf5PvLkxheD++z+yb7GSRlwD/+Hj/APQCZWxM5M+goF+RMbHK594v+tPoiN1uHxkt+xzt9+R9wnRTZZQpXQ0T5uP1IQxToyOAZiQu5HEpjeA4SWIoksRxNiGC1tRZJ4LNxgHgnU5nJZBDvuDdl8lzQRBsQ+s9PZt7s7Pz8wsL39/DkIfZ4xlB2Gqsq62ta9oxVlVrNZpihFRpGO9fzQw1ms0NDWZz07iGkJmIFH8xxkc3a/WWlubmFkv9AB2SEpDvKxbjidN2faseaNV3zoHXvv7wMODJdkOHAegweAfFPx4G67KluxzottCU9n8CUqXzcIQdXOytAHqXxomvykhEKN9EFutG22p//0rbNvHVxiJywa8yS2KDfV1dfbu31H8jF1RHiTKtWYeHxUvq3bn0pyjCRaiRU6aDO+gb3aEfEeVNsDgm8zzLy9egPa7Qt8TSJdwhjplk06HH43ZNJ3s91KKCHQ5x4sw1fRGYDZ0n1L4FKb9/BP5JLYxToheoFCVxz57PPS8UhhEpLBVeAAAAAElFTkSuQmCC" (Resize to image size, cross-origin anonymous)

  • We also tried to recreate the issue with the problem with a smaller project, but so far it does not fail in the same way.

  • We saw something similar in our project with r192.

    A temporary workaround was to add the object to the layout offscreen and destroy the offscreen object on the start of the layout.

    My guess is that this is caused by a recent change in 192 dealing with loading objects on start of the layout (discussed in another thread here on the forum.)

  • There is a _simple_ C3 Spine plugin that I helped work on here:

    github.com/gritsenko/c3_spine_plugin

    It does basic animation playback. It does not handle events, etc.

    So, it depends on how sophisticated you are in terms of using more than the basic animation ACEs.

  • Enable experimental features.

  • Good luck with early access! I am really bad at the game, but I still really like it :) Style is so clean and great music.

  • Thanks for thinking of me mOOnpunk I am currently doing game dev with my FQZ plugin at the moment, so not able to work on it. It does look interesting!

  • Thanks! Very helpful, much appreciated. We will also help test after the changes.

    Also, so you know, my quote about the UID conflict resolution in C2 was from the C2 SVN tutorial that you yourself wrote. (Seven years ago! So, I'm not surprised at all it may not have rung a bell):

    From: construct.net/en/tutorials/collaborate-projects-svn-321

  • Thanks for looking at it Ashley.

    Unfortunately, my understanding is that source control cannot detect this case, because the changes that cause an issue for C3 are happening in different files. Git/SVN cannot detect this as an issue.

    For example, in two different branches, one user adds Sprite1 w/ 1 frame, another user adds Sprite2 w/ 1 frame. One user pushes to repo, then the second user pushes and tries to merge. Git will not detect any merge issues.

    The *.c3proj file will have non-conflicting changes (two objects added with different names.)

    Two json object files well be created w/ different names one per user/branch: Sprite1.json and Sprite2.json. So git will not detect a conflict.

    Two animation images will be created with different names: Sprite1-*.png and Sprite2-*.png. So Git will not detect any conflict.

    However, in some cases, the Sprite1.json and the Sprite2.json will use the same imageSpriteId for the animation frame. This will cause an error in C3 when loading, but git cannot detect it.

    Since if it seems there cannot be a change to C3 like what is done for UID, the conflict detection I am thinking about is to add CI to our git repo that goes through the branch of the PR and detects for duplicated imageSpriteIds between different object json files. We could at least detect conflicts, though I don't think there is anything we can do about it, except reverting/refusing the PR. I don't know of a fix (e.g. change a imageSpriteId manually seems like a very bad idea, since it must be included somewhere else also (in png meta data?)). Thoughts on CI detecting this type of issue would be appreciated.

    Of course, we will also add some 'rules' to our team workflow. I wanted to note something that would be helpful for team collab and source control - if that becomes more important to the C3 community.