Jump to content

loodakrawa

Members
  • Posts

    161
  • Joined

  • Last visited

  • Days Won

    19

Reputation Activity

  1. Thanks
    loodakrawa got a reaction from overcrafted in SpriterDotNet - An implementation for all C# frameworks   
    SpriterDotNet A simple, fast and efficient Spriter implementation in pure C#. Feature complete.   About The goal of SpriterDotNet is to be as fast as possible while keeping the code clean and readable. Being a pure C# implementation, SpriterDotNet doesn't depend on any external libraries / frameworks. It focuses on simple and efficient calculations of all transforms at a given point in time. This allows using it with any framework just by mapping calculated transforms to concrete objects.   Supported Features Basic animations Bone animations All curve types (Instant, Linear, Quadratic, Cubic, Quartic, Quintic, Bezier) Points Collision Rectangles SubEntities Events Sounds Variables Tags Character maps Animation blending   Plugins / Examples Unity MonoGame   Source Code GitHub Repository  
  2. Thanks
    loodakrawa got a reaction from tnaseem in SpriterDotNet.Unity   
    I've investigated and this issue is happening due to the fact the animations don't have an identical layout (which is a requirement for animation blending to look right). For example, this is causing the head from animation 1 to be blended with something else (like an arm) from animation 2 which obviously results in weird things happening.
  3. Like
    loodakrawa got a reaction from tnaseem in SpriterDotNet.Unity   
    Hi,
    If there are glitches or issues with transforms I'll definitely investigate since the core problem might be a bug in the core library. There's a big difference between "It doesn't work" and "there are glitches"
    Can you please post as much info as possible about the issue so I can look into it?
  4. Like
    loodakrawa got a reaction from Noxalus in SpriterDotNet - An implementation for all C# frameworks   
    Hi,
    This is definitely the correct place to ask questions
    First of all - If you want to know a specific location from the animation, you should probably use action points.
    At the moment, the point transforms are not being converted into MonoGame coordinates (since I didn't know of a use case for this) but your question made me realise there should at least be a generic method that converts transforms from Spriter to MonoGame. I'll implement that asap.
    If you need such a functionality in the meantime, you can take a look at the MonogameDebugAnimator. It is piggybacking on the functionality of transforming sprite coordinates to draw action points. If you run the example project and go to the 4th spriter animation ("GreyGuyPlus/player_006") you'll be able to see that in action.
    Cheers
  5. Like
    loodakrawa got a reaction from Andrey in SpriterDotNet.Unity   
    Yes - that is the way to do it (if you're not using character maps). What would be the most elegant way? I'm always open for improvement ideas.
  6. Like
    loodakrawa got a reaction from portiexc in SpriterDotNet.Unity   
    SpriterDotNet.Unity The Unity plugin for SpriterDotNet. Supports all Spriter features.

    https://github.com/loodakrawa/SpriterDotNet/tree/develop/SpriterDotNet.Unity
    Documentation The most up to date documentation can be found on the GitHub Repository.
  7. Like
    loodakrawa got a reaction from some1else in SpriterDotNet.Unity   
    SpriterDotNet.Unity The Unity plugin for SpriterDotNet. Supports all Spriter features.

    https://github.com/loodakrawa/SpriterDotNet/tree/develop/SpriterDotNet.Unity
    Documentation The most up to date documentation can be found on the GitHub Repository.
  8. Like
    loodakrawa got a reaction from Dengar in SpriterDotNet.Unity   
    SpriterDotNet.Unity The Unity plugin for SpriterDotNet. Supports all Spriter features.

    https://github.com/loodakrawa/SpriterDotNet/tree/develop/SpriterDotNet.Unity
    Documentation The most up to date documentation can be found on the GitHub Repository.
  9. Like
    loodakrawa got a reaction from Dengar in SpriterDotNet.Unity   
    This is awesome - nice work!
  10. Like
    loodakrawa reacted to Dengar in SpriterDotNet.Unity   
    I appreciate the compliment.

    It doesn't actually create any Mecanim animations (since that is unnecessary) so it's more of a "pseudo pretend Mecanim". The animation states are just empty shells that tell the SpriterAnimator what to do.

    Here's the github link for anyone interested in tinkering with it.
    https://github.com/Dharengo/SpriterDotNetMecanim

    The main feature is basically for just basic statemachine-based animation, you use the AnimatorController just as you would with full Mecanim animations. With transitions, parameters and whatever you will. User-side scripts would communicate with the Animator component just like most Unity-users are used to.

    There are a few caveats though. Unity's AnimatorController is quite... limited in its runtime accessibility. I already have to hop through a number of hoops just to make it possible to edit individual transition lengths. As such, some features might work a little differently than one would expect.

    Animation blending and blend trees are a thing that don't work at this point in time, but substatemachines should work (in theory, it is untested).

    Regarding the blending, I'm not sure if I CAN make it work. Like I said, the runtime accessibility, and even the edit time accessibility leave much to be desired.

    That said, it appears that a future version of Unity will come with additional statemachine-based shenanigans, maybe the answer will lie therein.
  11. Like
    loodakrawa got a reaction from Kiori in SpriterDotNet.Unity   
    Runtime overhead compared to what?
    I've written the library to be as fast as possible (while still having readable code) and reduced memory allocations per frame to virtually zero.
    However, if you have really a lot of animations you might have an impact on the CPU. The usual technique to solve this is caching computation results - like in the SnapshotAnimationDataProvider class. This drastically reduces CPU usage but uses more memory.
    From my testing, the lib performs really well. The only  slow down I noticed is on Android (with > 30 complex animations) and the Profiler pinpointed the ApplySpriterTransform method, or more precisely, various calls to Unity's API inside the method. Unfortunately, I don't know if there's another, more efficient way of achieving the same thing in Unity.
    Regarding coroutines, I don't think it makes much sense to use them here since the overhead of calling Update is probably negligible compared to other processing. But if you get positive improvements, let me know and I'll be more than happy to update the lib.
    Cheers
  12. Like
    loodakrawa got a reaction from Wledig in SpriterDotNet - An implementation for all C# frameworks   
    Hi,
    As far as I know, no one is working on that ATM so feel free to do it if you feel like it. I suggest you take a look at the examples and github documentation and you should get a good understanding of how it works. Also, please read CONTRIBUTING.md before starting any work. If you have any questions, feel free to ask me here (or in the Unity plugin thread).
    Cheers
  13. Like
    loodakrawa got a reaction from Burning-Wood in SpriterDotNet.Unity   
    The colliders get added automatically under the "Metadata" -> "Boxes" object. However, I'm reusing collisions between animations and that could potentially cause problems. I'll look into it ASAP.
  14. Like
    loodakrawa got a reaction from Burning-Wood in SpriterDotNet.Unity   
    SpriterDotNet is a library that does all the work in pure C# code in order to support all Spriter features and be able to work with any .net frameworks/platforms. Unfortunately that means that it doesn't use platform specific things like Unity's animation system (which includes the Animator view).
    The idea is to control the animations with SpriterAnimator  - you can take a look at the example provided.
    That being said, Unity allows custom editors so I'll add the development of such a tool (something like the Animator view) to the project's long term goals.
    Cheers
  15. Like
    loodakrawa got a reaction from Burning-Wood in SpriterDotNet.Unity   
    SpriterDotNet.Unity The Unity plugin for SpriterDotNet. Supports all Spriter features.

    https://github.com/loodakrawa/SpriterDotNet/tree/develop/SpriterDotNet.Unity
    Documentation The most up to date documentation can be found on the GitHub Repository.
  16. Like
    loodakrawa got a reaction from WormLice in SpriterDotNet.Unity   
    SpriterDotNet.Unity The Unity plugin for SpriterDotNet. Supports all Spriter features.

    https://github.com/loodakrawa/SpriterDotNet/tree/develop/SpriterDotNet.Unity
    Documentation The most up to date documentation can be found on the GitHub Repository.
  17. Like
    loodakrawa got a reaction from SkeletalRavenArts in SpriterDotNet.Unity   
    SpriterDotNet is a library that does all the work in pure C# code in order to support all Spriter features and be able to work with any .net frameworks/platforms. Unfortunately that means that it doesn't use platform specific things like Unity's animation system (which includes the Animator view).
    The idea is to control the animations with SpriterAnimator  - you can take a look at the example provided.
    That being said, Unity allows custom editors so I'll add the development of such a tool (something like the Animator view) to the project's long term goals.
    Cheers
  18. Like
    loodakrawa reacted to Owlet in Action points tutorial   
    Update: The solution is to go to Hierarchy view and drag the point under the desired bone. After that, copy and paste the selected point(s) to all keys works- the action points move smoothly with the character.
    Thanks @loodakrawa for help.

  19. Like
    loodakrawa got a reaction from hippyman in SpriterDotNet - An implementation for all C# frameworks   
    There's a Unity project in the SpriterDotNet repo. It is not up to date due to a recent push to implement all the features in the core library. However, it's being worked on and should be complete soon (as a nice Unity package).
     
     
     
    Thanks for the feedback!
     
    While writing the library I took really a lot of effort into breaking down everything into smallest possible methods and naming everything in a consistent and meaningful way (hoping to have self-documenting code). Also, I used only the most common data structures which are available in virtually any language. But I understand why it might be a bit hard to understand, especially if you're not familiar with the scml data structure. In light of this, I will add a document that explains the general flow. In the meantime, you can start by looking at the "main" method and trying to follow the flow while keeping any scml open for reference.
     
    I've added a note about animation blending in the official documentation. The crash you discovered should not be happening and I'll fix it asap.
  20. Like
    loodakrawa reacted to lucid in Spriter Official Reference Implementations and Other Big News   
    Hi everyone,
    We're pleased to announce that at long last the wait for a fully featured and officially supported reference implementation for Spriter is at and end.
    The first two languages to receive officially supported, feature complete implementations are C# and C++.
    The C++ implementation is being created by myself, and should be ready for public testing in the very near future.
    For the C# implementation, we'd like to give a huge thanks to community member Loodakrawa for having created it, and for working with us to make it totally feature complete, officially supported C# reference implementation.  Loodakrawa was also nice enough to agree (and take the necessary steps) to change it's license to the zlib license, which is among the most permissive licenses available. This is the license all officially supported Spriter implementations will be released under. We encourage anyone who wants to port either implementation (or future released implementations) under the same license.
    In summary:

    It should be very easy to port to any language of your choice with a simple copy/paste, and edit.  Also, these will be easy to adapt to any game engine or authoring tool (There is an example in the C# implementation working in Monogame).
    Shortly after the release of the C++ implementation, we'll be working to port one of the two implementation to JavaScript.
    We're also pleased to announce we'll be working with the folks at ClickTeam to make sure Spriter is fully supported in their latest authoring system - Fusion 3 (not yet released).
    Similarly, we'll be working with Enterbrain, the creators of RPG Maker, to add Spriter support to their upcoming RPG Maker MV, which is already available for pre-order.
    Once these initial reference implementations are fully tested we'll also be contacting and working with the developers of as many popular authoring systems as possible to get full Spriter support ported to their respective packages as soon as possible, so please dive in and give these implementations a test spin. Please report any bugs with the C# version to Loodakrawa's thread. The sooner we make sure they're rock solid, the sooner full Spriter support becomes commonplace for all game developers. This is currently our top priority.
    In addition to this, we will be starting a thread in the near future of all ports, either complete or in the works. We will of course post any that we are directly involved with, but we encourage you to post in that thread to let us know if you're creating a port, or if it's already complete.
    While the community is helping us to test and perfect these current reference implementations, we'll be working on a Spriter update build, which will hopefully increase compatibility (most notably we'll be attempting to resolved issues with Retina Displays and Wacom input devices) as well as resolve some known bugs.
    As always, we greatly appreciate and are humbled by your patience and support during the long delay in meeting this critical milestone. Once this testing is complete, getting full Spriter support for any particular language or authoring system should be much easier and faster, even trivial.
    In the mean time, we definitely owe you an explanation for why the full implementation took so long:
    Our initial intent was to not only create a reference implementation which would support all of Spriter's current features, but which would also have the flexibility to support the substantial amount of future features we already have planned. Of course, the attempt to meet these goals necessitated fleshing out the requirements and nuances of the planned features, and taking time to make sure the structure of the reference implementation would leave the room and flexibility to easily incorporate them when the time came.
    This lead to a sort of tug of war, between the potential power and flexibility of the new features, the development time to finish the first release of the reference implementation, and the limits imposed by what the current Spriter data structure could accommodate.
    While grueling and time consuming, there was steady progress in many aspects of feature design, data handling routines, etc. The concepts and possibilities we discovered during this process were encouraging enough to postpone our eventual realization that unless we tweaked our approach and our actual goal, we'd be making too great a compromise, both imposing too long a wait on our users for support of the current features, and too great a compromise on the future flexibility of Spriter - with truncated versions of our new and powerful concepts shoehorned into compatibility with the current data structure.
    We realized the only reasonable thing to do was to break this initial goal into three separate goals, so that milestones useful to Spriter users could be reached much more quickly:
    Get support for all current Spriter features publicly released and available for all Spriter users ASAP. While this support is getting ported to as many languages and authoring systems as quickly as possible, work on an update build of Spriter, increasing compatibility and resolving as many known issues as possible. We'll also take this opportunity to add a couple of simple features specifically geared to improving work-flow. Once the update build(s) improve the current iteration of Spriter, we'll shift our focus back towards continuing where development of the future proof, uncompromising Spriter engine and data format left off. We've already made significant progress on this new core. It's a completely new design, and will be the foundation upon which we will build a new and improved Spriter, with a much more powerful and flexible feature-set. And with that, we'd like to announce our plans to develop Spriter 2. We can't disclose too much information about it or it's new features yet, but we can tell you that Spriter 2 Pro will be a free upgrade to all current Spriter Pro users. We will reveal more as things develop. Cheers!
  21. Like
    loodakrawa got a reaction from lucid in SpriterDotNet - An implementation for all C# frameworks   
    Fixed, thanks.
     
    @All if you find any other issues, please let me know.
  22. Like
    loodakrawa got a reaction from lucid in SpriterDotNet - An implementation for all C# frameworks   
    Fixed! Thanks to Lucid for great support.
  23. Like
    loodakrawa got a reaction from JohnnyType in SpriterDotNet - An implementation for all C# frameworks   
    SpriterDotNet A simple, fast and efficient Spriter implementation in pure C#. Feature complete.   About The goal of SpriterDotNet is to be as fast as possible while keeping the code clean and readable. Being a pure C# implementation, SpriterDotNet doesn't depend on any external libraries / frameworks. It focuses on simple and efficient calculations of all transforms at a given point in time. This allows using it with any framework just by mapping calculated transforms to concrete objects.   Supported Features Basic animations Bone animations All curve types (Instant, Linear, Quadratic, Cubic, Quartic, Quintic, Bezier) Points Collision Rectangles SubEntities Events Sounds Variables Tags Character maps Animation blending   Plugins / Examples Unity MonoGame   Source Code GitHub Repository  
  24. Like
    loodakrawa got a reaction from JohnnyType in Multiple timeline keys with same time   
    Hi, I found a scenario where some of the timeline keys get doubled. For example:
     
      <entity id="0" name="entity_000">        <obj_info name="bone_001" type="bone" w="718.421" h="10"/>        <animation id="0" name="Idle" length="1000" interval="100">            <mainline>                <key id="0">                    <bone_ref id="0" timeline="0" key="0"/>                    <object_ref id="0" parent="0" timeline="1" key="1" z_index="0"/>                </key>                <key id="1" time="500">                    <bone_ref id="0" timeline="0" key="0"/>                    <object_ref id="0" parent="0" timeline="1" key="3" z_index="0"/>                </key>            </mainline>            <timeline id="0" obj="0" name="bone_001" object_type="bone">                <key id="0" spin="0">                    <bone x="363.157895" y="5.263158" angle="180"/>                </key>            </timeline>            <timeline id="1" name="torso-armor">                <key id="0" spin="0">                    <object folder="0" file="2" x="388.164529" y="7.931817" angle="180"/>                </key>                <key id="1" spin="0">                    <object folder="0" file="2" x="-57.894737" y="-67.105263" angle="180"/>                </key>                <key id="2" time="500" spin="0">                    <object folder="0" file="2" x="-57.895" y="-67.105144" pivot_x="0.947577" pivot_y="0.701754" angle="180"/>                </key>                <key id="3" time="500" spin="0">                    <object folder="0" file="2" x="388.164266" y="7.931936" pivot_x="0.506371" pivot_y="0.537199" angle="180"/>                </key>            </timeline>        </animation>    </entity> The object_ref references the keys 1 and 3 only but the timeline actually has 4 keys, two at 0 time and two at 500 time. Is this a bug or did I miss something in the documentation? If this is not a bug, how to handle it in the implementation?

    Steps to reproduce:
    1. Create a bone
    2. Add a sprite and attach it to the bone
    3. Create a new keyframe
    4. Move the pivot point of the sprite in the new keyframe
×
×
  • Create New...