Jump to content

lucid

Administrators
  • Content Count

    1,053
  • Joined

  • Last visited

  • Days Won

    98

Reputation Activity

  1. Like
    lucid reacted to LukeLanFaust in Linux, Mac, and Windows users, please test Spriter R5   
    I just tested it out on windows and seems to work great. The current mesh deformation feature never worked on my laptop before, but it does now!
  2. Like
    lucid reacted to Breush in SpriterPlusPlus - a C++ Spriter implementation   
    I found out what the problem was, and it was not SpriterPlusPlus fault but mine.

    Reason was: I use a "model" image to place the different limbs of my animation correctly in Spriter.
    However, it becomes useless once in game. So I removed the line "<file id="6" ... />" by hand (back in the day) from the SCML file.
    But the current loader is guessing the file id, and not reading it, so all files id afterwards where wrong for SpriterPlusPlus.
    That's it. (Reloading the broken file in Spriter and saving a new version fixed it easily).)
  3. Like
    lucid reacted to conceptgame in SpriterPlusPlus - a C++ Spriter implementation   
    Cool! Really good job.
    I will now be able to update it to the Clickteam Fusion 2.5 tool. For what I have seen so far it should be straightforward from my existing implementation.
  4. Like
    lucid got a reaction from HeadClot 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!
  5. Like
    lucid reacted to labsin in SpriterPlusPlus - a C++ Spriter implementation   
    I've added a pull request for a gcc change and a fix for header files not found.
    I could build the engine now with:
    cd spriterengine LANG=C g++ -std=c++14 -shared -fPIC -I. */*.cpp -o spriterengine.so (LANG=C only because I like the terminal output in English)
  6. Like
    lucid reacted to Breush in SpriterPlusPlus - a C++ Spriter implementation   
    @lucid OK thanks, nice new wrappers.
    I updated my fork https://github.com/Breush/SpriterPlusPlus with the PugiXml loaders.
    You should check example/override/pugixml* and the pugixml at the root directory.
    Works all right for me.
  7. Like
    lucid got a reaction from AlisaMesy in Spriter R4 Bug Thread   
    Please post bugs with Spriter R4 here.
  8. Like
    lucid got a reaction from aiat_gamer 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!
  9. Like
    lucid got a reaction from loudo in SpriterDotNet - An implementation for all C# frameworks   
    Hi loodakrawa,
    See if this helps:
    // before adding the parent.angle to child.angleif(parentInfo.scaleX*parentInfo.scaleY<0) // if one, but not both are negative{ child.angle*=-1; // or child.angle=360-child.angle // (if you want to keep it within the 0 - 360 range)}
  10. Like
    lucid got a reaction from LukeLanFaust 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!
  11. Like
    lucid got a reaction from PixelPicoSean 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!
  12. Like
    lucid got a reaction from Ventos 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!
  13. Like
    lucid got a reaction from loodakrawa 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!
  14. Like
    lucid got a reaction from hippyman in Reference Implementation Status Update (10/18/2015)   
    Progress is indeed going smoothly. Still on target for October 18th. original post updated to reflect we're still on track for the ETA
  15. Like
    lucid reacted to NarwhalAndNot in Reference Implementation Status Update (10/18/2015)   
    really looking forward to this update, hope progress is going smoothly :D
  16. Like
    lucid got a reaction from TristanFat in Spriter r2 released! Steam Sale 50% until December 2nd   
    Hello everyone!
        Welcome to the first post 1.0 release of Spriter.  Aside from a couple of bug fixes, this release includes a new video help option that lets you watch our YouTube tutorials in a floating window (with links to open the playlists in your default browser).  Video Help will show up immediately upon startup to give guidance for beginners, and the window has an option to disable this behavior.  Spriter will now warn you if you try to save outside the project directory that it won't be able to find it's images, and will also provide an explanation and the expected file structure when you load a file with missing images.
    An important note for Mac users.  There is an optimization in this version that may correct the performance issues some users have been experiencing on the Mac.  Please let me know if this fixes the issue for you, as it seemed to make a significant difference on our machines.
    We will continue to fix bugs and provide minor feature updates, but my primary focus at the moment is completing the developer documentation.
    Lastly, if you're reading this and you don't already own Spriter Pro, or you have a friend who doesn't, Steam is having their Autumn Sale now, and Spriter is 50% off until December 2nd.  Spread the word!
    Thanks everyone, and enjoy the new build!

    download Spriter r2 here
    Change-Log 11/28/2014Additions and Enhancements
    Performance optimizations - possible fix for Mac slowdown issues Added Video Help on startup (with the option to never show again), and in the Help menu Added a link the Grey Guy example file in the Help menu Added a warning when attempting to save outside of the project directory(with the option to never show again) Added a warning/explanation that pops up when a project has missing images, and displays the expected file tree(with the option to never show again) Added a Help menu option to reset all 'show this message again' checkboxes Saving a resized project no longer allows you to save to your current project folder or any of it's subfolders to avoid confusion and overwriting or mixing up both projects' images Saving a resized project now confirms individual image overwrites as it creates resized copies of images Original image size data is now preserved in Missing Image placeholders Original image size data is now preserved when saving a project with missing images Bug Fixes
    Fixed a crash that could occur with certain projects with missing folders and images Fixed a bug that would give autosaves the *.scon extension when working on a project last saved as *.scon, even though all autosave data is saved as scml Fixed a bug that would cause child bones created on very wide parent bones to have 0 width
  17. Like
    lucid got a reaction from TristanFat in Art Packs now on Steam. New Price.   
    Hi Everyone,
    We're pleased to announce that our 4 fully animated Art Packs for use with Spriter are now available on Steam as of 4 pm today. June 4th EST.
    In conjunction with their Steam release we're also introducing a new, lower price point for them and all future art packs, not just on Steam, but on our own Web Store and on affiliate stores as well.
    Here are previews of all of the currently available art packs, along with their new prices:
    Game Effects Pack $12.99 Basic Platformer Pack $24.99 Adventure Platformer Pack $24.99 Run N' Gun Platformer Pack $24.99 In addition to this substantial price reduction, in celebration of their introduction, all art packs are currently on sale on Steam for 50 percent off, making this an excellent opportunity to snatch up these royalty free Spriter animations Packs for your current and future game projects at an unprecedented low price. For those who have already purchased one or more of our full Art Packs from our web store or any of our affiliates (Not Steam) BEFORE they became available on Steam, please keep an eye out in your in-box for an update email (for the Art Packs you purchased) automatically upgrading it to drastically increase your content. Here's what to expect:
    If you already purchased the Effects Pack, then you'll receive the Basic Platformer Pack for free.
    If you already purchased any one of the Platformer Packs you'll receive all other Platformer Packs for free.
    If you already purchased any of the bundles of 2 Art Packs then you'll receive all the other remaining Art Packs and the next Art Pack we release as well for free.
    If you purchased the all Art Packs bundle you'll receive all current and all future art packs we release for free. If you purchased more than one art pack, but one at a time you should qualify for numbers 3 or 4 above, then please email support@brashmonkey.com with the details of each purchase and make the subject title of the email “Art Pack bundle equivalent upgrade” (without quotes) And we'll upgrade your product description in our system and send you the additional art packs. If four days from now you still haven't received your automatic upgrade email, please contact support@brashmonkey.com with your original purchase information for your art packs or bundles and make the subject title of the email “Did not receive art packs upgrade” (without quotes) 
    In related news, we're currently working on 2 new Animated Art Packs which we plan to reveal more about within roughly a month.
    Cheers!
  18. Like
    lucid got a reaction from TristanFat in Spriter R4.1 Release (4.1 update contains critical bug fix)   
    Spriter R4.1 Critical Bug Fix:
    There was a critical bug in yesterday's build of Spriter that made it so you couldn't edit default pivot points.  I apologize for any inconvenience this may have caused, and here is a new version that fixes the issue.  If you use the Steam version of Spriter, it should automatically update the next time you log in.
    This version also contains a fix that may help some Steam users that were experiencing library issues on Linux.  
     
     
    Original R4 Update:
    Hi everyone,
     
    We're pleased to announce the release of Spriter build R4 available for download at www.brashmonkey.com and also as an automatic update on Steam.
     
    R4 is the first build to feature the newly updated manual which now covers all core features. R4 also features the long awaited hot-key list, which you can access by pressing Shift+Escape (or through the Help menu).
     
    One great new feature introduced in this new build is the ability to copy a specific individual attribute of an object (such as it's x scale, y scale, position, angle, or opacity) and automatically paste to all of its other key frames.
     
    This build should also fix a library issue with the 64 bit Linux version. Internal testing shows the Steam version of Spriter Pro now loads properly from Steam with Ubuntu 11.04, but so far we can only get it to run on Ubuntu 14 by launching it directly from it's Steam folder location.  It will not launch directly from Steam itself.  We will continue to look into this and thank you for your patience.
     
    Here is the full changelog for Spriter R4:
     
    Spriter Release 4
    Released 4/22/2015
     
    Additions and Enhancements
    Updated manual now includes all core features Added Shortcut Key Popup (available in the Help menu, and through keyboard shortcut Shift-Esc) Added the right-click menu option on the canvas to copy a single object attribute (x,y,angle,etc) to every frame (when one object is selected) Export To PNG/Gif window now remembers 'Keyframes Only' setting   
    Changes
    Minor cosmetic changes Changed Export to PNG Sequence naming convention to use one underscore (myImage_000.png) instead of two (myImage__000.png), as the double underscore was causing issues on certain OS's and API's Bug Fixes
    Fixed a bug that made the right click image list for sprites not show up under certain circumstances Removed the 'Program Update' settings from the Steam version, as Steam handles updates and these settings had no effect. We'd also like to take this opportunity to mention some great new Spriter implementations in the works for several popular authoring systems. Here are links so you can get the specific details for each of them. (If we missed any new Spriter implementations, please let us know and we'll mention it in our next update.)
     
    Atomic Game Engine (Video) 
     
    Overlap 2d
     
    Clickteam Fusion  (Video) 
     
    We should also mention Spriter2Unity has also been updated to work with Unity 5.
     
     
    Speaking of runtimes, we'd like to humbly thank everyone again for your patience as we continue to work on the Spriter Pro reference implementation. As most of you may know, the goal is to provide a fully featured and easy to follow/port Spriter implementation, and the delay is in general because we are making sure the implementation is as flexible as possible, includes several up-coming features and improvements, and makes room for the easy addition of several planned features which will be a big part of Spriter's future. As this full and future-proof implementation develops we're very excited with what it will offer Spriter users, but it's also becoming obvious that there's a conflict between the need to make sure its done carefully and the desire to get it done quickly.
     
    For this reason we've decided its best for me to switch gears and make a much simpler reference implementation which perfectly supports all current features (but not the future features) so that people who need to port or finish a Spriter implementation sooner rather than later will have a concise and easy to follow example in the near future. The much more robust implementation will be the focus once the basic implementation is made available to everyone. We will deliver a detailed update regarding this 1.0 feature complete reference implementation within the next 14 days.
     
    Cheers,
    Edgar at BrashMonkey
  19. Like
    lucid got a reaction from TristanFat in Please post feature suggestions here.   
    it's a definite possibility for the long term.
    good idea. It was already going to have the spinboxes, but that's a good idea. Also, the angle control will have a wheel you can rotate with your mouse.
    The current beta does have a 'protected selection' feature. You can drag, drop, and rotate a selected object even if it's behind others. only if you click a sprite on an area that doesn't overlap the currently selected object(s) will it change the selection.
    yes, that's in there
    yes, the next release will be native UI on Windows, Mac, and, Linux
    yes, all of that is planned for the long term, and the groundwork is already layed for those features.
    thanks for the kind words, and yes, we do want to work with the community to develop an ecosystem of some sort for both the animators and the developers.
    the todolist is huge, but things are going very well on fronts.
    working hard on the next version, and loving every minute of it.
  20. Like
    lucid got a reaction from TristanFat in scml documentation update   
    Just wanted to link to this on the main forum for anyone who's been waiting on this:
    viewtopic.php?f=3&t=12569
  21. Like
    lucid reacted to loodakrawa in SpriterDotNet - An implementation for all C# frameworks   
    Fixed, thanks.
     
    @All if you find any other issues, please let me know.
  22. Like
    lucid reacted to loodakrawa in SpriterDotNet - An implementation for all C# frameworks   
    Fixed! Thanks to Lucid for great support.
  23. Like
    lucid got a reaction from JohnnyType in Spriter version B6 Teaser!   

    Special Thanks to user TombMonkey for allowing us to use his awesome art.
  24. Like
    lucid reacted to hippyman in Reference Implementation Status Update (10/18/2015)   
    Good stuff. Just glad to see that it's moving forward. No hard feelings for not having a video. :)
  25. Like
    lucid got a reaction from Arrgincey in Please post feature suggestions here.   
    it's a definite possibility for the long term.
    good idea. It was already going to have the spinboxes, but that's a good idea. Also, the angle control will have a wheel you can rotate with your mouse.
    The current beta does have a 'protected selection' feature. You can drag, drop, and rotate a selected object even if it's behind others. only if you click a sprite on an area that doesn't overlap the currently selected object(s) will it change the selection.
    yes, that's in there
    yes, the next release will be native UI on Windows, Mac, and, Linux
    yes, all of that is planned for the long term, and the groundwork is already layed for those features.
    thanks for the kind words, and yes, we do want to work with the community to develop an ecosystem of some sort for both the animators and the developers.
    the todolist is huge, but things are going very well on fronts.
    working hard on the next version, and loving every minute of it.
×
×
  • Create New...