Spriter/C2 - (9-16-2019 - bug fix)

C-7 - I already tried adding a preloader layout but the problem is that only a few objects get preloaded since according to the manual:

Construct 2 only loads the images for the current layout. This avoids loading the entire project in memory which would be slow and consume a great deal of memory. When starting a layout, all images for the objects placed in the Layout View are pre-loaded. This includes all frames in all animations of any Sprite objects. (In other words, Sprites are either fully loaded in to memory, or not at all - they are never part-loaded.) When the layout ends, all images that are loaded but not used on the next layout are released from memory.

. The result is that other scml objects doesn't even show up since not present in the main layout. And they don't ever show up.

But if I add objects to both the preloader layout and main layout, things get glitchy on start of layout (must be because of high fps drop caused of javascript garbage removal of duplicate memory images). Creating Objects becomes glitchy and platformer objects are scattered.

With the fade-in delay, spriter objects already created are fine because it was hidden by the delay but during gameplay spawns, newly created objects are still invisible until a few seconds they show up.

*BTW I use the DestroyOutsideLayout behavior instead of Start->Destroy(Object) to destroy not yet used spriter objects on main layout.

Thanks in advance.

— Did you include the scml event sheets both into the preloader and the main sheets where you want to use the spriter sprites? The code are necessary to be included in every event sheets they are used, it's not optional.

Sethmaster - I believe I didn't add the initialization event in my preloader event sheet. Too bad I already deleted the version of my project that has the preloader. I am still remaking it and retry this. So if I add an include of my spriter event sheet, will the preloader work correctly that it will show the spriter objects on my main layout?

— It should since I have been using it as such for quite a while and have no issue whatsoever.

If you don't want redundancy, simply create a layout with the scml sprites with its own event sheet for the initialization events and include the event sheet in every event sheet that you plan to use the sprites in, including the preloading layout/event sheet.

Sethmaster - You are right. It finally works Thanks. A preloader is way better than adding it besides your game layout.

I just wanted to give a huge thanks to lucid for providing the "Set C2 object to Spriter" action. I spent way too long and revamped entire events trying to eliminate lag of an object from my character moving. Once I read about this and used Spriter's internal action point, and now it's working beautifully. Thank you so much!

Sethmaster - Btw. I further tested it, the result of my test is that it really does preload spriter objects more efficiently but it only is efficient with Desktops, Laptops but not in mobile phones. Even when I use the preloader and tested in mobile, there is still a short moment of invisibility when spawning/creating spriter objects for the first time on the main layout(preloaded on the preloader layout but not initially created on start of layout on the main layout.). My guess here is that due to the anticipation of mobile phones to conserve memory, garbage collection is more strict that images not present in the next layout will be automatically be flushed from the memory (that explains the lag when images present in the preloader layout is also present in the main layout that causes high fps drop due to memory flushing that causes layout startup glitches). So I believe depending on the phone's specs, there will be images in the preloader layout that will be flushed on end of layout. So any workaround suggestion?

No experience for using Spriter in mobile implementations since I never aimed for that but you can try creating one dummy for each spriter object you plan to use on the start of the layout outside of the layout (use negatives position) and deleting them shortly afterward (use 0.1 second of 8 ticks delay).

Then create the sprites you actually want to use afterward with none of the lag or problem.

No difference from preloading it using another layout.

Sethmaster - No I don't get the lag problem. That only happens when I have both objects in the preloader and the main layout. Besides, I don't use events to destroy preloader objects, I use DestroyOutsideLayout Behavior which is fast enough to destroy objects than events. Also, what I am experiencing is a short amount of invisibility of spriter objects when they are spawned on gameplay and not initially present in the main layout on startup (but they are present in the preloader). The reason here as I said above must be because of mobile limitations + javascript garbage collection that objects not present in the next layout will be flushed (so the preloader losses it's purpose). So the result is that there is a short moment of invisibility of the spriter objects. In my case, these are the bullets spriter objects. And Bullets that are invisible on first launch is kind of weird. So I am open for suggestions, thanks in advance.

Sethmaster - No I don't get the lag problem. That only happens when I have both objects in the preloader and the main layout. Besides, I don't use events to destroy preloader objects, I use DestroyOutsideLayout Behavior which is fast enough to destroy objects than events. Also, what I am experiencing is a short amount of invisibility of spriter objects when they are spawned on gameplay and not initially present in the main layout on startup (but they are present in the preloader). The reason here as I said above must be because of mobile limitations + javascript garbage collection that objects not present in the next layout will be flushed (so the preloader losses it's purpose). So the result is that there is a short moment of invisibility of the spriter objects. In my case, these are the bullets spriter objects. And Bullets that are invisible on first launch is kind of weird. So I am open for suggestions, thanks in advance.

As I said in my previous post, just create those spriter sprites first at the startup of any layout that will use them outside of the viewport (use negative coordinates). On creation, disable the DestroyOutsideLayout behavior for those instances only.

Then delete it soon afterward.

Sethmaster - Still the same result still showing the visibility delay, btw. I wrong the whole time that I was thinking that the cause of the short invisibility of the scml objects is the image not being preloaded inside the memory. I retested both versions of my game, w/ preloader and w/out preloader.

With Preloader: Memory Usage: 28.18 mb

Without Preloader (Images on the same layout used) : Memory Usage: 38.44

It seems that the spriter objects were already inside the memory the whole time and the preloader only worsen it since every layout change the memory is flushed out.

My point is that maybe the memory management is not the issue but the initialization of the spriter objects causes a delay.

I hope you can still be patient with me. Do you have any more suggestion?

Edit: I will try it again using preloader for spriter objects for the sake of initializing the scml objects.

Edit: Great it is working properly now without visibility delay, made a preloader again and separately initialized the scml objects without the destroyoutside behavior.

Hello everyone. I'll reply in to everyone in greater depth when I get a chance, but there's some great news coming soon regarding the performance and efficiency of the plugin.

If it's a new update then cheers!

indeed —,

It will most likely still be at least a week until the release, but it is an update to the current plugin (and Spriter itself). In the meantime I can give a little information for anyone who's interested. First, this update will enable a new mode for the plugin that operates in a completely different way, and hasn't had extensive testing yet - so upon release, the new mode will be considered alpha, bugs and quirks should be expected, and it should be used with caution. Also at this time, the new mode does not work with sub-entities, and potentially other features.

The new mode for the plugin draws itself instead of using separate sprites. For games that don't make use of individual sprites, this new mode eliminates quite a bit of overhead, resulting in greatly reduced cpu and ram usage. In addition, as far as I can tell, Construct 2's spritesheets don't utilize trimming (removing transparent border pixels of each image) or rotation(rotating images to make them fit in a smaller space). Because of this, Spriter's generated spritesheets, which are used by the new plugin mode, may also use significantly less vram depending on the images used in the project. Finally, since this is a new mode and not a separate plugin, it will be possible to convert your C2 projects using the current plugin, without having to replace objects or events (though it will require a fairly painless manual import process).

Here's an example of the types of speed differences I'm seeing on my machine: (bottom image is using the new mode)

lucid - I'm exited to try this out - and thanks for your continued support of the c2 plugin! In addition to the performance gain (or, rather, the removal of the performance overhead) I imagine that this will also make sprite sheet animation import into c2 far easier for updating during development than is currently the case with the native sprites. Will it be possible to simply over-write the Spriter files in the c2 project folder each time, or will they have to be dropped into the c2 editor for this to work? Either way it'll be interesting to compare the performance with that of native sprite animation.

As an aside, are you able to give an update on Spriter mesh deformation development?