Jump to content

lucid

Administrators
  • Posts

    1,092
  • Joined

  • Last visited

  • Days Won

    108

Reputation Activity

  1. Like
    lucid got a reaction from Fangoram in Spriter crash during batch export   
    This has now been fixed.  Thanks for reporting it.
  2. Like
    lucid reacted to germanmolto in Spriter R6 Bug Thread   
    Awesome! Thank you!
  3. Like
    lucid got a reaction from turosteel in Appended events making crazy stuff happen   
    @turosteel there was a bug fixed in the latest version of Spriter released after you made this post.
    Please see if you still have the issue in the new version.  This will not fix any projects that were already corrupted. 

    If you have important work that was corrupted and you don't have an earlier back up for, feel free to send me the project files to lucid@brashmonkey.com, and I will see if I can repair them
     
  4. Like
    lucid got a reaction from Wledig in Spriter R6.1 Released   
    Update 2/7/2016 Spriter r6.1 - Fixes a critical bug where attempting to batch export images would cause a crash.

    Hi everyone,
    We're happy to announce the beta release of Spriter build R6.
    This build marks another important milestone, as not only does it fix the vast majority of remaining known bugs, but it also introduces 2 great new features which will be described shortly.
    These two new features mark the final two new features for Spriter Pro.
    We're excited to soon begin full time development of Spriter 2, which as we mentioned previously will make room for a large amount of great new features and flexibility.
    As we stated in our previous update, Spriter 2 will be a free upgrade for all Spriter owners.
    Please keep in mind Spriter 2 development is still in it's earliest stages so it will be quite some time before the can provide any in depth updates on it's progress.
    While we'll be dedicating the bulk of our time on Spriter 2 development, we'll always take time as needed to address any critical bugs in Spriter Pro if any are found. There are still many great things yet to come to continue to improve the value of the current Spriter as well, in the way of more run-times for additional authoring systems and languages, more art packs, more tutorials and some other cool stuff we're not ready to announce yet.
    Please keep in mind, this is a beta build and many changes and additions have been made, so new bugs could exist. Always back up your work frequently.
    The first new feature allows you to batch export finished animations as PNG's GIF's Or sprite sheets, but adds the ability to perform multiple batch exports each with a separate set of character maps applied.
    The second new feature allows you to quickly and easily convert your Spriter Projects or art packs from using individual image files to using texture atlases..all generated within Spriter, with plenty of settings for you to control their maximum size, whether they are divided into sub-folders, etc.

    Videos should be released in the coming several days to showcase and explain the use of these new features.
    Also once we're ready to release the non-beta version of this build, the manual will have been updated to contain sections for all new features.
    Aside from those two great new features and a few other small but useful additions, this version also contains 32 bug fixes!
     
    Thanks as always everyone for your support, your patience, and all of your great feedback, not only in finding and reporting bugs, but also for your suggestions which will continue to make Spriter and Spriter 2 the best products possible.
    Cheers,
    Edgar at BrashMonkey
    Spriter Release 6
    Released 2/5/2016
    Additions and Enhancements (Manual entries and tutorial videos explaining new features coming soon)
    Added spritesheet generation directly in Spriter (in the file menu) Added ability to save palette swaps to new projects (in the File menu under Other File Actions) Added ability to choose scms files to perform batch exports on a series of character maps and palette swaps Added Remove all Palette Changes button to palette widget Added 'Clear Active' button to character map widget Added progress bar while applying palette changes Added My Art Packs shortcut to the help menu (Steam version only) Added startup log to help troubleshoot future issues starting the program Added openGL related crash detection with an automatic option to disable openGL upon restart after a crash Cleaned the program startup command line output of extraneous warning messages (Mac and Linux only) Bug Fixes
    Fixed an issue with palette color selection where the palette would unapply when you reentered the palette dialog Fixed an issue where interval values wouldn't update in batch export dialog Fixed an issue where drawing a box from the bottom right would create a box with a default negative size, causing issues in some runtime implementations Fixed a bug where the list of available tags would persist and accumulate when a new project was created or loaded Fixed a bug where changing the keyframe count settings in export to png dialog wouldn't always update the spritesheet size settings, creating spritesheets that had missing images or extra blank images Fixed a crash on start that occurred when Spriter attempted to use legacy window geometry restoration functionality Fixed bug where dragging sub-entities didn't preview the zorder in realtime Fixed a bug where selecting a sub-entity would cause the zOrder window to refresh to that sub-entity's z-Order Fixed a bug where adding a new non-event object after adding an event object would result in strange behavior or an unloadable file requiring a manual fix via text editor Fixed a bug where the transforms would behave erratically when there were multiple objects selected and at least one was a subentity Fixed a bug where the warning dialog for saving to a directory away from your original project directory (and associated project images) wouldn't allow you to accept or cancel, and required a force close to exit the program Fixed a bug where points and boxes were invisible upon creation until the mouse button was released Fixed a bug where the undo stack would already have undos upon loading certain projects Fixed a bug where sometimes pastes wouldn't immediately take effect until you changed animations or attempted to paste again Fixed a bug where sometimes deleting the last instance of an object in an animation wouldn't delete it's timeline Fixed a bug where pasting across entities wouldn't work correctly when the target entity contained an object with the same name if the object wasn't already a copy of the object being pasted. Would also corrupt undo buffer so undoing would cause objects to disappear Fixed a bug where Next and Previous shortcuts didn't work when using the numpad keys Fixed a bug where undoing the deletion of the last key in a timeline wouldn't properly restore the state Fixed a bug where sprites would disappear from the hierarchy window when you dragged them until the widget was next refreshed Fixed a bug where metadata keys for sound effects would show the waveform for the sound Fixed a bug where under certain circumstances newly added or loaded sound effects would display as normal keys instead of showing their waveform Fixed a bug where export to png would fail would if animation preset was selected when no preset was set for an animation. Now falls back on trimming to animation Fixed a crash that could occur under certain circumstances when deleting a key while the floating key curve view was visible Fixed a crash with gif export (64 bit Linux only) Fixed a bug where after a bone's opacity was set to 0, changing the opacity in subsequent keys would leave all child objects at 0 opacity Fixed several additional bugs with and improved the general behavior of children of bones with less than 100% opacity Fixed a bug with saving resized projects where subfolders of subfolders in the project wouldn't be saved to the new project Fixed a bug with saving resized projects where some of the original files might not be overwritten if you saved over a previously resized project and selected 'yes to all' when prompted whether to overwrite existing images Fixed a bug where attempting to set the default pivot point to a box had no effect. Fixed a crash when attempting to set a box to it's default pivot point. Fixed a bug that didn't allow character maps to use spritesheeted images Fixed a bug in the character map dock widget that would merge all character maps to new instead of just the active ones
  5. Like
    lucid reacted to Solgryn in Mantis Queen   
    Just wanted to share some of my work and possibly get some feedback, I think I'm getting the hang of spriter ' v'
    If you want to check out some other spriter works I've tweeted some over at https://twitter.com/Soulgryn
    Idle
    Casting
    Casting ended
  6. Like
    lucid got a reaction from adamcreator in Fix my corrupted file?   
    Hi @adamcreator,
    I sent you a link to your fixed file through the support system, but I'll detail the issues I found here, in case someone ever has similar issues.
    First, there were some png images that weren't importing to C2 correctly.  This is usually caused by software that saves or converts pngs in a nonstandard way.  I did a batch action in photoshop that just resaved the pngs.
    The jpgs were coming up as missing images in Spriter, this could cause issues with the save, which would make it not import correctly into c2.  Your jpgs weren't loading correctly in Photoshop, so I saved blank pngs of the same size with the same names (just paste your jpgs into these pngs and save the png).

    Then you had certain objects with an exclamation point in the name, which was preventing c2 from generating the same name for the sprites.  This may not have caused issues, since the associate action specifies the filename, but to be safe I renamed every object in the project by replacing the  !'s with _'s.  There were also files with '!' in the filename, which would eventually cause issues with on piece of software or another, so I changed those as well.

    Lastly,  I'm not sure how it happened but there was an object listed in your file that no longer existed in the project.  Because of the way it was being stored in the scml file, the scml plugin couldn't finish loading the file, so I removed that as well.

    On a side note, when I was attempting import, C2 was having issues with your wav files, and couldn't import them.

    In general, I'd advise not using special characters in filenames and object names, and if you're using any obscure software to save or convert images or sounds, that seems to be the root of a lot of issues, as Photoshop, C2, and Spriter all had trouble with some of your files.

    -cheers

     
  7. Like
    lucid reacted to adamcreator in Fix my corrupted file?   
    That is awesome, thank you SO much! I'm going to get to everything at the start of my next work day. It may take me time to find out why my PNGs and JPGs are saved in an unusual way, as all my image work and saving is simply done through "Adobe Photoshop CC (64 Bit)", but I'm just so glad to finally know what the cause(s) are. Thanks so much!
  8. Like
    lucid reacted to Banbury in SpriterPlusPlus - a C++ Spriter implementation   
    For complicated reasons UE4 requires that plugins have to be recompiled every time they are packaged into a game. So game-makers need the libraries and their header files in the project or they couldn't use my plugin. Trust me, I know what I'm doing.
  9. Like
    lucid reacted to Banbury in UE4Spriter - Spriter for Unreal Engine 4 (WIP)   
    UE4Spriter
    UE4Spriter is a plugin for Unreal Engine 4, that allows importing and rendering of Spriter animations in Unreal Engine games (Windows only as of now).
    Spriter project files and sprite images can be imported quickly. A Spriter component is responsible for rendering the animation. I tried to make the process of setting up a scene as hassle-free as possible.
    The whole project is open source (MIT license) and free to use. It can be downloaded from Github.
    Download
    Video
    Currently the plugin supports animations only. If there is enough interest I might add more features in the future.
    Recent changes
    Update README.md                                                         Disabled crash reporter and 'anonymous' statistics.                      Added Blueprint function to query triggers.                              Add reimport asset action for Spriter Project.                           Added Blueprint function to blend animation.                             Added Blueprint functions for stopping and starting animations.          Added Blueprint functions for character maps.                            Added Spriter placeholder image.                                         

  10. Like
    lucid got a reaction from monge93 in Spriter crashes when opening project   
    hi @monge93 I'm not sure how the file got corrupted, but my guess is it has something to do with eventlines, and possibly deleting an object after creating an eventline.  I will look into this more.  In the meantime, though, I was able to fix the file: https://dl.dropboxusercontent.com/u/257875422/SpriterForums/v4_character_000.scml

    I apologize for the inconvenience.
  11. Like
    lucid got a reaction from flaith in Spriter R5 Released!   
    Hello everyone,
    We're happy to announce the release of a new Spriter update build.
    This new build involved making the switch to the latest version of the application framework (Qt).
    Community and internal testing shows improved performance and compatibility overall, but this is a big change from previous builds, so please back up your Spriter projects before using this new build and please let us know if any new issues occur.
    Beyond the improved performance and compatibility, this build offers several new features and improvements. Here's a brief overview: (full change-log at the end of this post)
     
    This build seems to resolve the major visual issues for users with retina displays. Mac users report a substantial improvement in performance (FPS), and there seems to no longer be a need to disable OpenGL, however, some Mac users will get better performance with it disabled so you should try both ways and see what works best for your system. There's a new character map related color palette change feature for use with indexed color images (This new feature will be used heavily with our soon to be released RPG Animated art Pack and a SHMUP pack which will be released some time later.) You can now move animations from one entity to another. You can now specify custom trimming rectangles for export per animation. These settings are saved into your project. You can now save and load character map stacks and palette swapping information separate from your project. (ideal for complex Spriter projects where characters can be created by activating many character maps at once.)  
    Stay tuned for new quick-tip videos and documentation showcasing and detailing the usage of these new features in the coming days.
     
    We look forward to your feedback and hope you enjoy these new features and improvements.
     
    Cheers!
     
    Spriter Release 5
    Released 12/11/2015
    Additions and Enhancements (Manual entries and tutorial videos explaining new features coming soon)
    Upgrade application framework (Qt), which will enhance performance and improve compatibility Added ability to reorder character maps Added the ability to move animations from one entity to another Added the ability to swap palettes for indexes color images Added the ability to save and load scms (Spriter Character Map Stack) files which save the current character map stack and all currently applied palette swaps Added the ability to set custom trimming rectangle settings for exporting per animation that get saved into the project Bug Fixes
    Fixed memory leak when creating new character maps Fixed bug where the right mouse button image strip to choose images for sprites wouldn't show up for images in subfolders more than 2 levels deep
  12. Like
    lucid reacted to jeremyjh in SpriterPlusPlus - a C++ Spriter implementation   
    I think this is a good idea @lucid - I will give it a try as I think it will be cleaner code and may also make certain features easier should I decide to try to implement them, such as integrating the Cocos2d Physics system.
  13. Like
    lucid reacted to labsin in SpriterPlusPlus - a C++ Spriter implementation   
    My SpriterPlusPlusQt is now in a working state. You should now be able to build and run it.
    Using it from QML is very easy.
    I created an example that's more or less the same as the SFML one (creating 100 random entities). Each frame is 10ms, so performance is good.
    Now I need to add more features (sound, ...) and optimize a bit.
    Still a question, are there some dimensions on the animation as a whole I could use? A bounding box.
  14. Like
    lucid reacted to josempans in Spriter R5 Released!   
    Wow! The performance in Mac (I have a Mac-Mini) is really really better, now I can actually work with it,  (I used to work in a PC/Win when using Spriter). Really happy now, congrats! 
  15. Like
    lucid reacted to Ventos in Spriter R5 Bug Thread   
    Yes. Thanks for all the tips. AMD drivers is the problem.
    I should look for that.
    (Mine is Notebook Radeon HD 8600)
     
  16. 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!
  17. 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).)
  18. 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.
  19. 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!
  20. 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)
  21. 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.
  22. Like
    lucid got a reaction from AlisaMesy in Spriter R4 Bug Thread   
    Please post bugs with Spriter R4 here.
  23. 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!
  24. 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)}
  25. 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!
×
×
  • Create New...