8DashP

Thanks Mike. It’s been a long road since I first purchased in 2013. You may or may not remember I built a plugin for Shiva3D way back when, but then they screwed over their developers and basically died, and it left such a bad taste, that I quit the game development industry. Life has moved on, and I’m now starting again in Unity and maybe Godot. I can see an opportunity to develop a Godot plugin, but I’d definitely need to get a better handle on what features and functionality are coming, to decide whether to commit, so any updates would be greatly appreciated. Hope you get the support you need and can push forward to plan. Russell.

Nice to see a big list of features. It sounds like a very ambitious project, and probably something needed to differential Spriter from the competition in the current market. I must confess however, it is all quite confusing as to what the end result will be. The ideas behind the control widgets and procedurally generated characters in particular are hard to envisage how this would be implemented in a game development package. It almost seems like you want Spriter to be the game engine. Are the widgets going to be exportable components to be imported into the end user game engine, or are they used within spriter simply to render out generated images to, for example, sprite sheets, or animation states? This is just an example of what is unclear from the Kickstarter page to me, which makes it hard to decide whether to invest or not, and even whether this is all Alchemist functionality, or a mix of Spriter 2 and Alchemist. My assumption is that everything shown is Alchemist specific and won’t be available in Spriter 2 base. It would be good to see some more in-depth examples of specific functionality. Not sure if development is far enough along to do this though. Russell.

Thanks. Yep, figured all that. I'm using it as an optimisation technique to only load required images instead of all of them.

My rambling as you so put it, is from reading an article by the MessagePack author about it's performance in particular situations, and his own statements that JSON may be better in certain situations. I'm glad you managed to try it out and found a good improvement for Spriter files.

Apart from the bugs in the reference code, I think it's still pretty much valid and should just need adding to with new features. My Shiva implementation is in C++, but using Shiva API's for image, object and screen manipulation as Shiva is a 3D environment, not 2D. I've had to modify some of the reference data structures to make sense in my environment, mainly around the timeline, bone and object keys, as turning 2D images into 3D objects but still treating like 2D objects requires some lateral thinking, and coding. I started with the generic C++ code! but have virtually rewritten it all as my deviations for my environment were turning it into spaghetti code, and I wanted to stay closer to the reference implementation. So overall, the basic algorithms and data structure are sound. It's getting it into your runtime environment that takes all the work.

I might have to look into something like this. My current Shiva implementation is taking 150ms to load the Platformer essentials .xml data (which is 12,000 lines of text, so no wonder) on my i7 iMac. I'm afraid to even run it on an Android device to see how long it takes. I realise it's a 1-off load at start time, but if you start to use a bunch of different characters and sprite objects, with multiple animations each, it's all going to add up, and I haven't even got around to using points, collision boxes, or any of the other new features yet. *EDIT* Hmm, after looking into MessagePack more, it seems it might be dependent on the use-case as to whether it's better than JSON or not. I might look at a JSON solution first and see how much better than XML it is. I'm also thinking of maybe trying to minify the XML or JSON by stripping out non-essentials for my use-case, such as string names etc. Running the profiler in Visual Studio, I was surprised at how much work it takes to process std::string. *EDIT #2* Well, just tried converting the player.scml to player.json. It went from 1.4mb down to 1.3mb (or 3.2mb if you convert it to pretty format!!), hardly significant. JSON is throwing quotes around everything, which pretty much balances out the XML tags difference. I might just forget the whole idea for now, and see how my results actually run when I get to mobile deployment, before thinking about refactoring the XML.

Can I get a clarification on this? I'm having an issue with the transition from the last key back to the first, in a looping animation, and am wondering if something is amiss here. *EDIT* OK, after replacing all nextKey.time with NextKeyTime, the wrap around seems to work. So, I'm guessing the correct code is to make my substitution, and also this should mean that nextKey is not required as a parameter? Russell.

Ok, I think some of my confusion with editing the timeline might be a bug? Using b7(pre 2) in WIndows 8 VM, in parallels on OSX Mavericks iMac So I completed a simple logo animation of my plugin name, using just sprites, no bones, and now I want to add some additional elements, like stars sparkling around the name. I added the first star to the start of the animation, but am having difficulty setting up subsequent key fames. I don't want to copy my first keyframe to every other keyframe, as I want the star animations in different places to my logo animations. If I move the timeline to before the next existing keyframe, I can edit my sprite and the world is good, but if I want to edit it at a place after the next existing keyframe, by copying the first key and pasting it in the new timeline spot, my sprite vanishes because it is not keyed at that existing keyframe which is between my new key and the initial key. 1. However, if I copy the initial key and place it the existing keyframe I just jumped over, and then delete it again straight away, so I only have my initial key for the star, and the new keyframe for just the star after the existing keyframe for the logo, it then tweens properly between the two star keyframes. 2. Also, if I then move the timeline on, then "key all", nothing shows up. I can keep moving the timeline and "key all" with nothing showing in the timeline, but if I then change an element, all of a sudden all of those "key all"s I did show up. 3. Am also experiencing weird timeline behaviour if I undo (cntrl-z) with what is selected. For example, I can delete a keyframe, then undo, then press delete again, and the undo selects different keys, so the second delete is deleting keys further down the timeline, instead of what I had previously selected. 4. Similarly with selection, dragging the keys backs and forth across the timeline, when you release it in it's new position, random other keyframes in the timeline become selected, rather than the one you just released. 5. What behaviour should moving an individual sprite key have? Moving it back & forth across existing keyframes causes it to snap to one I moved over randomly, instead of where I released the key. When an individual key is moved to an empty timeline space, should a "header" key be created? I am ending up with sprite keys with no header, and headers with no sprite keys. 6. If I move say two individual keys from their existing timeline spot, to different spots each, then delete one of the individual, I am getting multiple keys created at the spot of the other individual, for new images I've added to the animation. I then can't delete those new keys, so they may be display artefacts, not real keys. Russell.

I'm running Windows 8 in parallels on a Mac. I'm having problems loading my project, that I started on the mac. Copied the directory to my shared folder, and it crashed trying to access them. Then I copied the folder to my Windows desktop. it then opened OK, but just came up with a file browser instead of images in the palette window. only had drive letters, none of the virtual folders like Desktop. So I browsed to c:\user\desktop and it got that far, but would not recognise anything below it. Finally, moved my folder to a standard C:\ subdir, and it's all come up as normal. I'm also finding it very unintuitive how I need to set and adjust keys in the timeline. I'll go rewatch all thw intro videos, but something doesn't seem right. Russell.

Well it was working fine on the lightning sample, but when I tried doing my own sprite today, with image swaps, I found a flaw in the theory. For just image swaps, the obj number and the name match the obj_info name and index, but that in't sufficient, as image swaps index into the data. So it looks like I'll have to rework the methodology. Problem is, it's a many to many relationship. Each obj_info can point to many image files, and each image file can have multiple obj_info references. Urgh, never a good sign when that happens.

As a follow up. I'm thinking the "obj' attribute in the Timeline element in an index value into the array of loaded "obj_info" attributes. Is that correct? So the Timeline name matches the "obj_info" name, but the "obj" number also matches the obj_info attributes?

I've come across another dilemma. Everything works wonderfully when only a single copy of a sprite part is used, and I can use the folder/file I'd combo to identify my part. However, when multiple copies of the same part are used, the folder/file is no longer sufficient to identify which part I am using, as multiple different objectInfo names point to the one folder/file Id, but each copy can have different runtime values. I therefore need to store each instance separately, including the image data. This is where I have a problem. The SpriteTimelineKeys only use the file/folder combo to identify the object being operated on. I see though, that the timeline name seems to match the objectInfo name. Can we assume that the timeline name can be used to match the object instance name it is operating on? As a backup plan, the mainline reference also refers to the objectInfo name, which could be passed down to the timeline functions, if the mainline were a match, but the timeline wasn't for some reason. Do either of these sound like viable options for applying timeline values to the correct object instance, rather than the base file/folder objects? Thanks. Russell.

I jus realised there's an issue with the defaults for the parent of a Ref. While your pseudocode shows -1 as the default, the example on the right shows -1 only for bones, but 0 for objects. I assume it should always be -1, otherwise if an object default of 0 is used with no bone_refs, the updateCharacter function will fail with an invalid index to non-existent pone_refs. The examples on the right should show default values for consistency. Russell.

*EDIT* OK, finally got it all figured out. I was trying to do the pivot adjustment on the spriter data all this time, when i should have just been doing it on my Shiva images, using the spriter data. So yeah, in the end, I threw out all my pivot code changes, and just had to change the paint method to accept the pivot value, and then subtract that from the final image location. The one trick with all that, was that the final pivot adjustment is in local coordinate space, not global. Hope my wild rambling will be of use to some future implementers. Thanks. Russell.

Been trying all sorts of combo's. This is the closest I've got with using the absolute of the scale values when calculating sprite_x and sprite_y, but I can't figure out where the final alignment issues are. Nothing I try to adjust the pivot offsets gets any closer to a final image. Given my non-pivot code seems to be the same as what is recommended elsewhere, I can only think the issue is in my pivot adjustments. *EDIT* Actually I can get a slightly closer image in some components, by changing the new x value sin/cos line to a + instead of a -, which has some consistency with flipping. Here's the bits of code changed from what i posted above, and the final image I have. float sprite_x = offsetX * std::abs(k.info.scaleX) * -1; float sprite_y = offsetY * std::abs (k.info.scaleY) * -1; float s = (float)sin (angle * SCM::DEG_TO_RAD); float c = (float)cos (angle * SCM::DEG_TO_RAD); float xnew = (sprite_x * c) + (sprite_y * s); float ynew = (sprite_x * s) + (sprite_y * c);