0 Favourites

Drawing plugins now supported in r68

  • As for Construct 3 r68, the plugin SDK supports drawing plugins.

    The plugin SDK download has been updated, and now includes two example plugins: a single-global plugin (the same one that it had before), and a drawing plugin (the new one). The drawing plugin simply displays a single image and provides the options to edit the image, size it to original size (like Sprite), and also a C2 runtime implementation that draws it from a spritesheet.

    Note that in C2, not all images were spritesheeted. In C3, all images are spritesheeted, so plugin drawing methods must take this in to account. The example C2 runtime implementation has code that demonstrates this for both the canvas2d and WebGL renderers.

    All available editor APIs are now documented in the editor API reference section of the Addon SDK documentation. To fully support drawing plugins, many new interfaces have been added, and they are comprehensively documented there.

    This is an initial release and the capabilities are fairly basic. If you are developing a plugin that needs some extra APIs, please let me know in this thread and I'll see what we can do about it. I'd expect it to take a few more releases of C3 to fully mature the APIs and cover everything that third-party developers need.

  • Great news.

    lucid, Brashmonkey, please keep the community updated on when work will start on porting Spriter to C3.

  • None of the basic actions are offered: Angle, Appearance, Size/Position, Z-order. These were based on the C2-flags, if I recall.

    Also need access to set the HotSpot, for offering HotSpot properties.

  • blackhornet - ah, good point about basic ACEs, they were actually implemented but not documented. I've updated the documentation to include them.

    The hotspot features are there, they were just renamed to "origin" in C3. See the origin functions here.

  • stricky - working on it, possibly gradually depending on the resolution to the below

    blackhornet - any plans/eta on updating your indispensable Plugin Converter?

    Ashley - It appears I may have made a mistake converting the Spriter plugin. After I installed the addon I get this error as soon as I launch the C3 editor, so I can't remove the addon to try again:

  • lucid

    I'm working on it. Started yesterday, as a matter of fact.

  • lucid - use developer mode so you can just fix the problem and carry on.

  • Ashley -

    To enable Developer Mode, open Construct 3's settings dialog and click or tap the dialog caption 10 times

    I'm not sure how to open the settings dialog, as that error appears as soon as I click 'Launch Construct 3'. Is there a way to access settings before you open C3?

    blackhornet - Awesome. Thanks for the awesome tool, btw. Saves hours of work for plugins with a lot of ACEs.

  • You can use safe-mode:

  • Over on the Spine forums, badlogic made this comment on the new API that they will not be able to implement a Spine runtime/plugin, Ashlhey any comments?

    Spine Forum Post

    Thanks for the update, I saw the new C3 release as well. Currently, it's not possible to draw textured triangles, a feature required so mesh attachments can be drawn: 

    construct.net/make-games/manuals/addon-sdk/reference/graphics-interfaces/iwebglrenderer[/p] [/p] Scirra also requires plugin developers to use their sprite sheets implementation, which makes sense. However, that would require us to be able to create sprite sheets on the fly programmatically from the atlas format Spine exports. I can not find an API to create sprite sheets on the fly. The alternative, and I think that's also what Spriter does, is to have users setup sprite sheets manually. That's a pretty terrible workflow we don't really want to push on our users.[/p] [/p] I'm afraid we'll have to wait for future updates.[/p] [/code:z4hz30cj]

  • I really, really would so much prefer Spriter and Spine to not implement themselves as drawing plugins. This forces the plugin to reimplement a bunch of Construct features and actually limits other creative features too. For example:

    • you can't add a WebGL shader to just one part of a skeletal animation if the plugin draws the whole thing, but you can if it just controls sprite objects (e.g. make just the head flash red if hit, etc)
    • you can't test for collisions with just a segment of a skeletal animation if the plugin draws the whole thing, but you can if it just controls sprite objects
    • a plugin which draws the whole animation probably has to reinvent a whole asset management pipeline, but if it just controls sprites it leverages our project-wide in-editor spritesheeting engine
    • Construct's support for containers allows you to treat composite objects as if they were one instance in the events

    Personally I am convinced that these plugins should not use the drawing APIs and should simply act as controllers for sprites. This makes it much more flexible for the user, and avoids clunky reinventions of existing parts of Construct. I discussed this at length with a Spine developer a while ago and I thought they agreed; one of the outcomes of that discussion was the decision provide a custom import process so they can conveniently generate all the necessary sprites on import, so I filed this issue as a TODO for that work. Perhaps not all the Spine developers are aware of this approach.

    We could add the drawing APIs they want, but one of the reasons we're holding off is because those features don't work in the canvas2d renderer. From the user's point of view, this will manifest as the plugin randomly not working on a small percentage of devices. I intend to make the C3 runtime the point where we unilaterally drop the canvas2d renderer, at which point we can go to town with these kinds of features. However even then it has the drawbacks listed above, and the C3 runtime is still some way off.

    Rather than adding new drawing APIs, I would much rather add any extra APIs to allow them to act as controllers, and have a good workflow for importing and updating. That's why I filed the custom importers TODO issue. I am totally willing to co-operate with any developers who want to take this approach and refine the SDK to make it work well. I can't force them to, and they might make drawing plugins anyway, but I hope at least one of them take me up on this offer!

  • What about the issues of using sprites for everything?

    For example you can't define hotspots, or image points at any other time than on import.

    Another might be that you can't decide what frames are loaded on creation.

    These should be features accessible to the object, and not only available to a behavior.

  • You can use safe-mode:

    Thank you.

  • I really, really would so much prefer Spriter and Spine to not implement themselves as drawing plugins. This forces the plugin to reimplement a bunch of Construct features and actually limits other creative features too. For example:

    - you can't add a WebGL shader to just one part of a skeletal animation if the plugin draws the whole thing, but you can if it just controls sprite objects (e.g. make just the head flash red if hit, etc)

    - you can't test for collisions with just a segment of a skeletal animation if the plugin draws the whole thing, but you can if it just controls sprite objects

    - a plugin which draws the whole animation probably has to reinvent a whole asset management pipeline, but if it just controls sprites it leverages our project-wide in-editor spritesheeting engine

    - Construct's support for containers allows you to treat composite objects as if they were one instance in the events

    Personally I am convinced that these plugins should not use the drawing APIs and should simply act as controllers for sprites. This makes it much more flexible for the user, and avoids clunky reinventions of existing parts of Construct. I discussed this at length with a Spine developer a while ago and I thought they agreed; one of the outcomes of that discussion was the decision provide a custom import process so they can conveniently generate all the necessary sprites on import, so I filed this issue as a TODO for that work. Perhaps not all the Spine developers are aware of this approach.

    We could add the drawing APIs they want, but one of the reasons we're holding off is because those features don't work in the canvas2d renderer. From the user's point of view, this will manifest as the plugin randomly not working on a small percentage of devices. I intend to make the C3 runtime the point where we unilaterally drop the canvas2d renderer, at which point we can go to town with these kinds of features. However even then it has the drawbacks listed above, and the C3 runtime is still some way off.

    Rather than adding new drawing APIs, I would much rather add any extra APIs to allow them to act as controllers, and have a good workflow for importing and updating. That's why I filed the custom importers TODO issue. I am totally willing to co-operate with any developers who want to take this approach and refine the SDK to make it work well. I can't force them to, and they might make drawing plugins anyway, but I hope at least one of them take me up on this offer!

    Spine, Creature, and Spriter 2 would all use polygon meshes to render their parts, as opposed to rigid sprites. As far as rigid sprite animations like Spriter 1 (or if C3 gets a deformable polygon mesh object, and we went with that), the only issue was that since all objects would be in a single container, they would all need to be present at all times (unless containers don't work like that anymore). This means that if you have sprites that only briefly appear in one of the several animations, or small objects composed of several sprites, of which there would be hundreds of instances, there comes an ever increasing overhead of sprite objects created that don't do much but sit around, invisibly, and wait to be used. Even when I added functionality to disable all animations on objects that were off screen, having hundreds of idle Spriter objects in a level (composed of more hundreds of individual sprites), the overhead of having all of those idle sprites made it run much more slowly than when I enabled the self-drawing mode, even though animations weren't being calculated or applied at all.

    [quote:3p2kc0q6]a plugin which draws the whole animation probably has to reinvent a whole asset management pipeline, but if it just controls sprites it leverages our project-wide in-editor spritesheeting engine

    'm not sure why this would be. The C2 plugin for Spriter was eventually expanded to allow users the choice of the import process we worked together on, and control individual sprites, or to allow them to load a single spritesheet image and draw itself. The plugin handled the splitting up of the spritesheet itself, though, so perhaps this is what you mean?

    [quote:3p2kc0q6]you can't test for collisions with just a segment of a skeletal animation if the plugin draws the whole thing, but you can if it just controls sprite objects

    this does pose a problem. For the Spriter plugin, in self-drawing mode, you had the option of having the plugin still create just the collision sprites, and so the API you mention would still be quite useful. Another alternative would be if there was the ability to have multiple collision types/shapes on the same object, and plugins could test if any or a particular one registered an overlap or collision.

    What about the issues of using sprites for everything?

    For example you can't define hotspots, or image points at any other time than on import.

    Another might be that you can't decide what frames are loaded on creation.

    These should be features accessible to the object, and not only available to a behavior.

    or the hotspots with the scml plugin on C2, since Spriter has animatable pivot points, we just had all of the sprites generate as 0,0 hotspots, and then the plugin did the hotspot math to compensate.

  • Construct 3

    Buy Construct 3

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

    Buy Now Construct 3 users don't see these ads
  • lucid - you've raised some good points, actually. Let me have a think about what we could do to solve some of these integration problems.

    For rendering deformed meshes, are you currently drawing degenerate quads? (i.e. make two points of the quad the same, so you get a triangle)

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)