Jump to content

8DashP

Members
  • Posts

    60
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by 8DashP

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. Something else I just found. The function GetTWithNextKey() has a parameter of NextKeyTime, which is unused. I assume since you can get NextKey.time directly, then this is an unnecessary parameter, or do you want to disassociate the nextkey time from the nextkey key?

    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.

  7. 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.

  8. 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.

  9. Yes, it should. Just try and see if you get an index out of bounds exception or something like that.

    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.

  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.

    Jg6Zrjs.png

    *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);

    0WpnCuB.png

  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. Is k.info.angle the parent angle? The angle of the current object has to be affected by the inherited angle with currentObject->angle += parentObject->angle (same for the scaling with multiplication). I think you are rotating the wrong x and y values. You do not have to rotate pivot points. Those are just added to the final position.

    And I would do the unmapping before calculating the pivot part.

    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. I see. It looks like you are drawing some parts without taking into account that the origin of the sprites are centered by your engine. Then you should try to recalculate the final sprite position by moving it half of the width to the left and half of the height to the bottom (or the other way around).

    Somehting like:


    calculate position x, y with pivot points...
    move x by -sprite_width/2
    move y by -sprite_height/2
    render sprite at x,y

    Maybe the y value is a different, since I do not know how your engine draws pixels on the y-axis.

    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;

    Then a character map with no targets makes no sense to me. Why should Spriter save such a useless character map?

    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. 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.

  19. 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?

  20. 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?

    BYXoa6t.png

    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?

    6CYkW3h.png

×
×
  • Create New...