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

C-7: That's my initial idea as well, though if I do that, it will defeat the purpose of using Spriter in my project. I planned to have an enemy where you can destroy all the individual limbs and joints, and currently it's done manually per 'section'. It's tedious to setup, but I think I might have to fallback to this.

Thanks alot for the help!

Hi all. Sorry for my extended silence. Some non-Spriter/non-Brashmonkey issues have kept me from being too active recently. There will be options to adjust the main collision box(as well as separate animateable collision boxes) in the Spriter editor. The upcoming version will also eliminate the need to do anything extra(like name each item in Spriter) to make it work in C2.

BluePhaze, turning the animation into a spritesheet will be done through texturepacker integration, but as far as using for c2. c2 does that behind the scenes with sprite objects from what I understand. If you export each full frame as an individual image (I think that's what you're asking), you will lose the benefit of using modular animation though.

lucid: good to hear about the collision option, but may I ask how soon such feature will be available?

Thanks for the reply, I don't want to export each frame as a seperate image, I want to export all the keyframes as a SpriteSheet in order to keep the benefits of having all the animation frames in a single sheet.

BluePhaze: Spriter uses the keyframes as coordinates for the different sprites that compose your animated object.

Check again this example of use.

The "monster" is composed by several sprite objects, positioned and each displaying a specific set of textures.

What Spriter does is emulate the positions of each object in relation to the others in real time, according to the keyframes.

So a spritesheet containing the fixed positions of the character kind of defeats Spriter's purpose.

The textures of the monster WILL be in a spritesheet no matter what as mentioned in this article and if you use the correct image compression.

The character being composed of several sprites, there is one sprite for the head and its different "stances", one for the left arm, one for the right arm, etc...

The keyframes are nothing but datas that will be applied in realtime to transition from a stance of the character to another one (applying to each and every single sprite that composes the character).

I hope it makes things clearer.

edit: oops this towards C-7 problem.

I know what's going on here. I'm just not entirely sure how to fix it.

What's happening is that when the animation sprites change the old versions are being left behind. I suppose what you can do is make sure they are hidden. I haven't used Sprite in C2 yet although I plan too. Sorry I can't help more, but your capx is for 115 and for me I avoid using beta's until there is a required feature for my game.

um. If you can't hide the last sprite change you can try spoofing the problem by pushing the last draw of the last sprite frame to the outside of the layout. Then start back to it's proper position the next frame. That way the sprites of the last direction are still there, but wont' be seen. However, this is an ugly hack job :|

So I guess my main goal here is to use spriter to help get the movement and positions right, then have it give me a sprite sheet based on the entire character, not of the individual sprites. My goal is to have an ouptut similar to a sheet like the one for teh main character in the jungle platformer sprite pack. So I put all the pieces of the monster together, use the bones to get the overall structure and movement done, create my keyframes, then export the keyframes of the entire creatures movement (as opposed to sheets for each component of the creature) frames. As long as Spriter can do that for me, then I am all set when I buy it.

I may just be overthinking this...

Other wise I can just screenshot each keyframe, and put those screen shots together into a spritesheet I guess... I don't need all the super crazy features, just the basics of make a series of poses (walking cycle, etc...) and export each pose of the cycle as a frame in my sprite strip.

BluePhaze

Based on how you want to proceed your taking your project backwards and ultimately going to use a lot more memory space.

Spriter plugin system handles animation for you. You don't need to export to sprite sheet, unless you specifically need spritesheets. That's also very unlikely for the purpose of animation. So let's go over the post.

"My goal is to have an ouptut similar to a sheet like the one for teh main character in the jungle platformer sprite pack."

Do you actually need a sprite sheet? So far I only know that you need animation. What exactly do you need the spritesheet for? Spritesheets use a lot more memory and storage space than a Spriter object.

"So I put all the pieces of the monster together, use the bones to get the overall structure and movement done, "

Not entirely. This will only achieve a non moving object. This is the first step to using Spriter.

" create my keyframes, then export the keyframes of the entire creatures movement (as opposed to sheets for each component of the creature) frames.

"

This is not how spriter works. Keyframes are positions and angles for 1 part of your monsters part. ie it's one position of the leg at one point in time. The next key frame could be the last position in time in the animation. A keyframe is not an animation frame. It's point A and B locations at differnt points in time. The animation will move the objects position and angle from A to B during the animation process.

A(0time)- - - - - - - - B(10seconds later)

X - - - - - - - - - - - X

The above has Keyframe A and B. B is set to 10 seconds later and 200 pixels away from keyframe A. Let's ignore angles.

When the engine animates in game or tool the X sprite. It's going to create 600 "frames" or animation positions. You as the monster designer do not have to actually animation anything between time keyframe's A and B.

That's the point of keyframes and this form of animation.

"As long as Spriter can do that for me, then I am all set when I buy it."

Lucid says it's coming, and if you need it. Then sounds good :) Spriter makes animation easier even if you want to use spritesheets.

"Other wise I can just screenshot each keyframe, and put those screen shots together into a spritesheet I guess"

nope. Keyframs are not the same as a sprite sheet animation frame. They represent a part of the objects in a different place and time in a animation.

You can if you want animate and take as screen shot, but your overcomplicating your game design.

My suggestion is to try using spriter and watch the tutorials. Watch how many keyframes it takes to make an animation and how it all works. It seems by your posting that you might not know how key frames work in animation. All we want is for you to make the most informed decision.

youtube.com/watch

youtube.com/watch

But if you actually need individual frames. It will work and good luck :)

Thanks for the informative reply! I think where I am off here is that I was assuming that the Spriter object would use more memory than a spritesheet due to everything it does and brings with it including the generated sprite sheet, etc... My assumption was that a sprite sheet would be less resource intensive than an entire spriter object.

I will definitely go over the tutorials with Spriter, etc... I guess my question now is, if I want to use spriter to make my main character and all my enemies, will having that many spriter objects give me much savings over using sprite sheets and instances for them? I am assuming I can use C2 to tell the spriter object to change to different animations the same as I would with my existing sprites in C2 that use sprite sheets?

Thanks again for all the info, all of my experience with keyframing is from Flash, so I understand the tweening process, etc... but C2 and Spriter are still very new to me, so are sprite sheets.

edit: oops this towards C-7 problem.

I know what's going on here. I'm just not entirely sure how to fix it.

What's happening is that when the animation sprites change the old versions are being left behind. I suppose what you can do is make sure they are hidden. I haven't used Sprite in C2 yet although I plan too. Sorry I can't help more, but your capx is for 115 and for me I avoid using beta's until there is a required feature for my game.

um. If you can't hide the last sprite change you can try spoofing the problem by pushing the last draw of the last sprite frame to the outside of the layout. Then start back to it's proper position the next frame. That way the sprites of the last direction are still there, but wont' be seen. However, this is an ugly hack job :|

Sorry about the r115! I updated to see if it might, for some reason, be fixed in it. Yeah, it's the leftovers, but there aren't really "frames" that I can get rid of in any way. It has keyframes, but those are just coordinates. It does its positioning through the animation as milliseconds (and then scales them if need be). Other than me using 4 scml's for it all as a workaround, it seems like I may just need to wait for an update. It could just be the issue of objects in one animation not being present in another. Like the objects left behind are probably the ones not carried over to the turn, so it has nowhere to move the objects and leaves them there. I hope its a simple fix whenever it gets addressed!

After testing my technique, I am getting a big file size problem and potentially sprite management hell, so I went back to Spriter to test more. I managed to get it working consistently and I have also found out the problem with collisions.

By default, all sprites have their origin in the center, which is usually height/2 & width/2. Spriters image however, tend to have their origin moved to where it would be pivoted most. When it's imported into Construct, all is fine, as it seems Spriter scml will take care of that in run time.

However, one thing I noticed is that, the collision box however is a different matter. At run-time, it seems that collision box will be offset to a difference between the default origin and Spriter's origin. I managed to somewhat lessen the difference by moving the origin in Construct to match that of Spriter.

It works great so far, but I can see this being a nuisance to production. Any chance that this will be worked upon?

yes. thanks for the bug report. When this next version finally releases I'll be able to resume plugin work. I'm sure there's something that can be done about the collision boxes either c2 side or in the plugin.

Is there possibility to move my entire character, because it's not centered in spriter and it affects in C2? Is there some pro version of Spriter and how do I get that, I pledged on Kickstarter long time ago?

There will be a way to do that soon nemo. The pro version is a bit delayed, but things are still moving along. You should get your pro key and download link later this month.

Ah that's good news lucid. Been waiting for pro to come out.