Mikal's Forum Posts

  • 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.)

  • Is there an SDK method to update a Sprite animation frame with a new image (from a blob, data URI, JS array, etc.)

    I am looking for alternatives/workarounds to a current stuttering issue seen when using the Sprite Action Load Image from URL.

  • Checking in on this, it would be useful to add this. Ashley?

  • I'm working with an animation runtime which is rendering via webgl to a separate canvas.

    I want to use the result of the render as the image for a Sprite in C3. I would like to change the image for the Sprite on every frame (to show the animation.)

    I am using the Sprite Load Image from URL action (using a blob URI or a data URI that has been captured from the separate canvas) to set the image of the Sprite.

    It's working pretty well, except for a stutter I get every few seconds. Tracking it down, it _looks_ like it's due to v8 running 'Major GC' and pausing the rest of execution for a while. Is there something in the Sprite Load Image from URL action that would cause 'Major GC' to kick off every few seconds?

    I have created a simplified test case which shows the issue (in this case I created a JSON object of data URIs instead of capturing another canvas and using the animation runtime, to help isolate the issue to just the Sprite Load Image from URL action.)

    Looking at the perf graphs, a big system task is kicking in, then 'Major GC' starts.

    I thought I would start here for discussion, but if needed, I can also file a bug report.

    Example Project:

    LoadSpriteURLTest.c3p

    I am also very open to other ways to do a load of the sprite texture each frame if that would work better (within the JS C3 SDK or other C3 actions, etc.)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Really nice work, I have been playing with using a pathfinding library (Easystar) and have found that at about pathfinding actors it starts to slow down a bit. This looks really nice going up to a higher actor count and with more interesting behavior. Looking forward to see more of your work on this.

  • Ah, that would be difficult then. Also for this module to work, you need to get the raw audio in a buffer, which I am not sure how to do from the C3 Game Recorder (except something like loading and decoding the recorded webm file which seems like a pain also.)

  • I think this is for a download application vs web app (right?). So - you may be able to use npm modules if you export (and there are other ways if it is for web.)

    If that's the case you may look at this:

    npmjs.com/package/audiobuffer-to-wav

    You would then add an appropriate JS or plugin to call it (after loading your locally recorded file, getting it from a buffer, etc.)

  • Try assigning it to another local variable within the function declared static. However, this could have issues with multiple calls to the same function within the 1s, where the variable could get reassigned while the wait is active and could be tough to debug. Perhaps look at using a timer (with tags) assigned to an object instead, and use the function to start the timer and the timer end trigger to do the next action(s).

    construct.net/en/make-games/manuals/construct-3/behavior-reference/timer

  • Updated project file.

    • Fixed a bug in Player UI (would impact tilemaps that do not have square tiles.)
    • Updated Easystar plugin bundled in project to handle 'disable diagonals', I also asked Eren on their github to fix the posted C3 version.