Jump to content

8DashP

Members
  • Content Count

    58
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by 8DashP

  1. Thanks. Yep, figured all that. I'm using it as an optimisation technique to only load required images instead of all of them.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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?
  10. 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.
  11. 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.
  12. *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.
  13. 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);
  14. OK I seem to be having trouble flipping the Grey Guy, and I'm not sure I'm following what's happening above. I've tried every variation I can think of with no luck. My guy looks perfectly fine with characterInfo values of x,y, = 0,0 and scaleX, scaleY = 1,1. If I change scaleY to be -1, to try and flip him the other direction, things become very messed up. scaleX at -1, is just as messy. Both at -1 produces a clean image, just flipped on both axes. Where does the code Lucid suggested go? I tried it in the unmapFromParent() code, separately before that in the bone and object key loading, after the keyFromRef() call. Also, I had to add a transform before painting of the pivot points, to get my code to draw correctly. So I'm guessing an adjustment may need to be made there, but I'm not sure how. Here's my addition pivot transform code, where k is the current object key being processed. float offsetX = (pivotX - 0.5f) * img_dims.first; // image width float offsetY = (pivotY - 0.5f) * img_dims.second; // image height float sprite_x = -offsetX*k.info.scaleX; float sprite_y = -offsetY*k.info.scaleY; bool flipped = ((k.info.scaleX < 0) != (k.info.scaleY < 0)); float angle = k.info.angle; if (flipped) angle = -angle; 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); xnew += k.info.x; ynew += k.info.y; sprite_x = xnew; sprite_y = ynew; // Let the renderer draw it sprites[parentSprite].paint (k.spriteKey.folder , k.spriteKey.file , sprite_x , sprite_y , flipped ? -k.info.angle : k.info.angle , k.info.scaleX , k.info.scaleY , k.z_order); Any ideas where I've gone wrong? Thanks. Russell.
  15. Right well, I'm embarrassed to say that I've found the solution to my problem. I was on the right track about the issue, just looking in the wrong place. Seems when I imported the pivot_y from the scml data, I'd cut & pasted the pivot_x import line, and forgot to change the check from "pivot_x" to "pivot_y" :oops: I did have to go back to my original code of also rotating the offset separately, after transforming the sprite position. I've tried several pays to incorporate it at the same time as the sprite transform, without success. I'll review the math a bit more, as while I have the correct result currently, it's a double calculation, which I'd like to remove. I'm happy to say though, at least I have a working version now, and once again, thanks Trixt0r for at least holding my hand while I worked through the issues, as it encouraged me to keep trying, instead of just giving up. Russell.
  16. First off, I appreciate you taking the time to look. Thanks very much. k.info.angle is the unmapped angle already. Here's my code that processes the keys prior to trying to adjust the pivot, which si really just a c++ version of the reference pseudocode std::vector objectKeys; for (const auto &o : mainKey.objectRefs) { SCM::SpatialInfo parentInfo; if (o.parent >= 0) { parentInfo = boneKeys[o.parent].info; } else { parentInfo = sprites[parentSprite].characterInfo; } SCM::TimelineKey currentKey = keyFromRef (o , newTime); currentKey.info = currentKey.info.unmapFromParent (parentInfo); objectKeys.push_back (currentKey); } After that is when my other code gets run. Unfortunately, just substituting your code in place of my previous code makes a big mess of the placement. But my X, Y values at that time are already unmapped, so maybe that wasn't what you intended. Maybe I need to move the pivot adjustment into the unmap function? I had an original implementation working with the generic C++ code provided here on the forum. But I found it rather difficult to read, and overly complicated for my use. That's why I'm trying to refactor based on the reference documentation. So the reason I was doing my pivot rotation like I currently have was because that's close to how the code in the C++ implementation worked, but obviously I've messed something up in translation :( I also read another article only talking about 2D rotation with an offset pivot, and it mentioned about subtracting the picot first, then transforming, then adding back on, but I'm not sure if that's right, and my attempts so far have not resolved anything. Odd part is, when doing that, all of my locations are displaced EXCEPT the ones that are currently in the wrong position (shoulders & hips joints), they seem to stay fixed in the one place, like they're being scaled to almost 0 or something? It almost seems like a data error int eh SCMl file, but given no one else has this issue, it must be something I'm doing. I'll try moving my pivot code into the unmap, instead of being post-unmap, and see if that matters. *EDIT* Eh, well after trying several variations, they either all make it worse, or best I can get is my original first image posted above. And once again, even in all the bad results, the should & hip joints seem to stay exactly where they are, while everything else moves all over the place. Must be number issues somewhere, not formula. Maybe something is going to 0? Precision problem? The end co-ordinates for those sprite locations aren't 0 thought, just small numbers. Back to the drawing board. Thanks. Russell.;
  17. Yes, I already had that in, even in my original image. What got me to the second image was that I then had to apply a transform to the pivot, the same as the pseudo-code transformation, to get it into the same space as the image coordinates, but still something is amiss with those few joint connections. Here's my pivot transformation C++ code, where k is the current objectkey you are processing to paint, and the values used are those after the pseudocode transforms to the scml data. float pivotX = k.spriteKey.pivot_x; float pivotY = k.spriteKey.pivot_y; if (k.spriteKey.useDefaultPivot) { // get default pivot data from folder/file data pivotX = data_objects[0].folders[k.spriteKey.folder].files[k.spriteKey.file].pivotX; pivotY = data_objects[0].folders[k.spriteKey.folder].files[k.spriteKey.file].pivotY; } float offsetX = (pivotX - 0.5f) * img_dims.first; // image x dimension float offsetY = (pivotY - 0.5f) * img_dims.second; // image y dimension float sprite_x = -offsetX*k.info.scaleX; float sprite_y = -offsetY*k.info.scaleY; bool flipped = ((k.info.scaleX < 0) != (k.info.scaleY < 0)); float angle = k.info.angle; if (flipped) angle = -angle; 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); xnew += k.info.x; ynew += k.info.y; sprite_x = xnew; sprite_y = ynew; Well I could be wrong on the original intent, so don't take my word as the true intent. My guess would be because it means you can use common code, and just process the current character map regardless of whether it is the original image, or a new map, instead of having one code path when no map is applied vs another path when a map is applied. Russell.
  18. My preliminary Shiva improter also seems rather "notchy" when animating, compared to Spriter. Maybe I have a similar issue, can you elaborate on what your problem was? Thanks. Russell.
  19. I'll see if there's anything unusual I do in the code, and try and put that up in the morning. I've given up for the night, and am just heading to bed here now. But I've pretty much just used the straight pseudo-code from the documentation here http://www.brashmonkey.com/ScmlDocs/ScmlReference.html with just some local tweaks for my custom environment requirements. The unmapFromParent function does the grunt work maths of transforming the object location info from the parent bone info, at least from what I can see, so you'd think my problem comes from there, but as I said, it's the same code as the pseudo code. My main difference is manipulating the pivot points before the draw, as Shiva only has a centred pivot point. You'll also see in that doc, that a character map also has two other fields - target folder and target file. So using the map is just a matter of replacing the original references with the target references to the new images. I haven't usually implemented myself yet, got to get the basics done, but in theory it should be easy. There is another thread here viewtopic.php?f=3&t=15496 where Mike explains the process. I think the fact it's missing the targets simply means they should be defaulted, i.e. The map is just the standard images. Russell.
  20. Hmm, this is driving me crazy now. Most of the placements work. It just seems where there is a sub-branch bone coming off the main hierarchy, the top node in that branch is not being placed correctly, but the objects below it are, relatively. The math is the same on all nodes, so what's unique about where the arms & legs join the pelvis/chest? The parent info on these nodes is common I think, in that their parents info is being derived from the base, instead of other nodes. Ive just set my base character info as x,y,z = 0 and scale x,y = 1, and the pelvis/torso/head hierarchy is rendering correctly. It seems after al the transforms, the X coordinate is not far off the Y axis. Not sure where else to look?
  21. *EDIT* My bad, extra save option I missed Russell.
  22. OK thanks. Z_order is the least of my issues at the moment, until I can get the x,y placement of each part correct, but I think that makes sense. Russell.
  23. Hey All, My old plugin code was drawing properly, my new code isn't. The code has been refactored, but the calculations look the same to me, so I'm not sure what's happening. Did the file format change between the old monster sample, and the new GreyGuy sample, that might have changed the render algorithms? I don;t think pivot points were anything but centered in the original example, which may be an issue, but I can't see where. Only things I can think of are that my texturepacker atlas has changed layout somehow, or I've just got either a flipping or offset issue. In particular, the Torso and Head seem way out of place, the other parts not so much, but that may be just a scaling thing as the other parts are smaller. Anyway, here's what my current output looks like. I'm hoping maybe someone can look at it and suggest what the issue might be? Thanks. Russell. *EDIT* Almost got it. I had to add a second transformation to the offset before painting. Now it's almost correct, there just seems to be some slight offset issues. Looks like everything on the X-axis might be compressed, or offset wrong?
  24. Just noticed that the z-index is in the object_refs. Is this the z-index for drawing the individual sprite components? Since the painting happens in the timelineKeys, by which time the object_refs are passed, I've had to add the z-index into the Timelinekeys, and do a copy in the keyFromRef() function. Am I missing something here? Russell.
  25. Good question. I've been wondering myself about the transition when swapping between animations. It would seem there needs to be some sort of tweeting process between the exit positions and one animation, and the entrance positions of another. Almost need an inter-animation, animation and timeline. Russell.
×
×
  • Create New...