Mikal's Recent Forum Activity

  • Thanks for the help investigating this, that's too bad about the binary object. I have been working on the full project and trying some different ideas. However, then I just fall back to the test case that already has issues with just the one action, so I should probably just focus on that. I'm going to file a bug report and see if I can get some attention from Scirra also.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Agreed on the memory allocation, this is where I started on the problem also, Major GC, blob creation seem to be the issue. However, I'm also exploring some more with coordination (or lack thereof between the rendering process and loading the Sprite image.) If the 'consumption' gets out of sync and delayed, perhaps blobs could be created without revoking. I'm adding in some check and variables, but have not yet seen improvement.

    I'll take a look at the BinaryData object too, but it sounds like you already did and it's not going to help.

    I really just want to have a reusable ping-pong buffer that is the size of the image data for the sprite that I can load into the Sprite (as long as that load does not create new blobs which must also be dealt with.) I may need to start exploring readpixels from the webgl context of the canvas that was rendered: WebGLRenderingContext.readPixels()

  • Yes, I think Spine and Spriter animation in C3 will take more performance than frame by frame (though with the benefit of potentially lower memory footprint and more flexibility of controlling the animations during runtime.) It's a tradeoff. Exporting png Spritesheets from Spine and Spriter is also a reasonable solution with different tradeoffs.

  • q3olegka Sorry, I'm not sure I understand your question. This is a Spine skeleton, animations, and atlas imported into C3 from Spine (_not_ done with exporting spritesheets from Spine.) The Spine-TS JS runtime is also imported into C3 (via JS script files) to render the animation to a canvas each frame. The canvas image is then loaded into a C3 sprite animation frame on each tick. The original Spine animation and skeleton are using mesh (you can see the animation mesh deform as it moves.) The Spine animation could be controlled dynamically by C3 JS scripting events which use the Spine-TS JS API.

    At this stage, it's a C3 tech demo to see if it's possible to use the Spine-TS JS runtime as an alternative to waiting for someone to do a full C3 plugin / port to C3 SDK. If it works reliably (there is a stuttering issue every few seconds which I am tracking down), I'll make a template and share it.

    Did I answer your question?

  • Magistross Agreed - though it seems pretty close to working. It works well for 100s of frames before it stutters, so I'm hoping Ashley can give some guidance on how to improve this, perhaps using a function of the C3 Plugin SDK or Scripting SDK instead of the Sprite action, or if there can be some improvement done to my use of the Sprite Load Image action (or if it's possible to change the C3 implementation of the action so the Major GC does not occur.) The Load image w/ blob takes up < 1ms of frame time, so pretty usable.

    Here's a short loop that shows it works well for a second or two (this is from the full project, Spine webgl runtime integrated with C3 via Sprite image loaded from separate Spine runtime webgl rendered canvas and outline effect applied on Sprite.)

  • Here's another more clean example (the gif loop is short, so the stutter every few seconds does not appear.) Since the image is on a Sprite, you can also do some fun post effects, like adding Lems' 'outline' effect:

  • Magistross Thanks for the comments, if I wanted to preload the animations, I could also use the Spine tool itself to playback animations and create many png spritesheets to import into the C3 editor. However, for high frame rate and many animations, this would be a lot of PNGs to store. I would also have to add all the variations for mixing different animations (you can 'tween' between, so they transition well.) It would also have to be done for every skin (you can see how this explodes quickly.) It's similar to why some people use the Spriter plugin, instead of using captured Spriter png spritesheets. I do want the dynamic Spine animation control during game runtime (to control animation mixing, skinning, etc.)

    That being said, your suggestion may be an improved workflow to doing Spine png export and I will definitely keep it in mind (you can even do some optimizations like change render resolution for preloads during runtime depending on the device you are on.)

  • That JSON is just in the example to focus on the Sprite Load image action. In the actual project, the blob or data URI is generated from the capture of the Spine rendered canvas, each rendered frame and JSON is not needed or used. The JSON in the example was a capture of three of the data URIs generated in the full project.

    The blob or the data URI contains only the image. They will change each frame depending on the game's control of the Spine animation.

    I am hoping for more suggestions around loading a Sprite image each frame without the engine stuttering.

  • newt In your suggestion, what would the JSON data to be used for and what object would it be loaded into? I'm not sure how this helps to load a sprite image.

  • It's not a Spine plugin, but I'm playing with JS integration of the Spine-TS (webgl) runtime. It will require more direct C3 JS scripting to control the Spine-TS api. I am using Spine-TS to render to a separate canvas and then capture the canvas and update a sprite with the rendered image each frame.

    It's currently working, but with one caveat, every few seconds it stutters (it looks like due to JS Garbage collection, there's another thread about that in the forum asking for help on a solution.)

    You will need to use JS to control it, so it will require some C3 JS knowledge. The current template is more of a tech demo and would need a lot of clean up to be used in a game, but's promising to see something work.

    Here's an example of it in action in C3 (I'm also enabling the display mesh and display bones options on and off.)

  • newt you are right, it does. It looks like a lot of work to port the full Spine runtime from JS / webgl to the C3 SDK (including managing textures, animations, etc. in the C3 SDK, dealing with deforming meshes and degenerate C3 quads rendered to texture with proper texture projection.) So, I'm trying to take the shortcut of using the Spine JS/webgl runtime pretty much as is and push the final rendered output to a sprite (except loading atlas and skeleton from C3 project files.)

    WackyToaster Yes, that's what happens, with the blobs, I'm trying some tricks like URL.revokeObjectURL() on the blob URI to give hints to the GC to do Minor GC over time, instead of Major GC. I also tried using the data URI, so at least I'm not creating blobs as I capture the canvas, however, I imagine that the Sprite Load image action may be creating blobs for the new image it's loading from the data URI (perhaps adding a URL.revokeObjectURL() to old blobs in the implementation of the Sprite Load image action would help, but this is all speculation.)

    With the full project, it's similar, very smooth, but then every few seconds there is a stutter. I'll post the full project in another thread later, it's WIP, but promising!

  • newt WackyToaster Thanks for the comments. The example project was done just to isolate the stuttering issue to a C3 action. The full project includes the Spine JS webgl runtime (skeletal animation, similar to Spriter 2, Dragonbones, etc.) which does full animation, including dynamically mixing between animations, skinning, many animations, etc.) The Spins JS runtime allows for dynamic control, so the animation rendered will not be just one small animation loop that captured and replayed. It needs to run constantly. I just did the JSON data URI / string replay in the example to show the stuttering issue in an isolated way without all the baggage of the Spine JS webgl runtime.

    In the full project, I have tested with using a blob (binary/png) URI and a data URI (text.) with similar results.

    I am hoping that Ashley or others can take a look at it since it seems related to the C3 runtime/plugin implementation of the Load image from URL action (or have a suggestion on an alternative workaround that allows a Sprite image to be updated every frame.)

Mikal's avatar

Mikal

Early Adopter

Member since 22 Apr, 2016

Twitter
Mikal has 103 followers

Trophy Case

  • 8-Year Club
  • Entrepreneur Sold something in the asset store
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Popular Game One of your games has over 1,000 players
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x10
    Great Comment One of your comments gets 3 upvotes
  • Delicious Comment One of your comments gets 10 upvotes
  • Email Verified

Progress

19/44
How to earn trophies