Apologies for the bump.
thanks for the bump
The first thing I'm wondering is if the collision rectangles work the way I think they do. If I understand right, it sets collision points before putting the animation into whatever game program, and then whoever does the programming can simply use those without having to implement collision masks in the program itself? Granted, what happens during those collisions obviously wouldn't be handled in spriter, but still, if that does what I think it does, I'd be amazed.
that's exactly how it works. you simply add SpriterHitBox to your project, and do nothing further. the spriter plugin will create and destroy them according to the frame of animation. so you can do events like
SomeSprite on collision with SpriterHitBox
----SpriterHitBox.Name = "swordtip"
-----------Do Something
they are invisible by default, but you can turn them on for debugging your game, and they appear in the color you specified in the editor. It's just random in this case, and for testing purposes, but if you look at the video, when a certain frame plays a red box appears. that's a hitbox
Another thing I'm wondering is if any additional programming is required for bone movement after putting the animations in the program. Is it really that simple? I know very little of bone movement in construct right now, so maybe this is a question best saved for later, but I'm just too curious I suppose.
it really is that simple. most of the actions/conditions/expressions are taken directly from the normal sprite object, with modified inner workings of course, but you'll see everything you would expect to see, like Play Animation, Pause, Set Speed, Set Angle, and you can apply behaviors, etc.
It's very different than bone behavior. it will be an object like sprite, rather than a behavior, and will not use separate sprites to create the different parts like the bone behavior. it handles all the drawing internally.
on another note, the VRAM savings over normal sprites can be tremendous. For instance, assuming your character uses the same set of sprites for each frame(which won't always be the case), if you made a character with 500 frames of animation over the course of all their animations, it would take approximately 0.2% of the VRAM of the same character had it been a normal sprite. For example if a normal sprite took up 150MB of VRAM, the same thing could be done 0.3MB. This drastic VRAM savings means you can have larger characters and enemies, with smoother animations, and more different types of characters and enemies before vram starts becoming an issue
Finally, will the current price for pro remain the same when the beta is released?
The public beta is aimed to begin at a late November release. the price will remain the same until it's out of beta, which won't be until it's complete and stable. the new price has not been decided yet.