Jump to content

API for C or C++ which loads Spriter file into some data structure


Bioz

Recommended Posts

Is there a generic C or C++ library which can be used to load the Spriter exported animations into some class or struct object that can then be accessed with graphical library independance?

 

I am not looking for something that will draw anything to the screen. I am only looking for a library that can be used to access time-based tranformational data required to render. For example, given time=1second and objectID=5, it should be easy to get rotation, scaling and translational information.

 

Also, is there a list anywhere of all the API's?

Link to comment
Share on other sites

  • 2 weeks later...

Hi everyone.  I'm still making progress and it's my primary focus, from now until it's done.  Nothing specific to report now, and I apologize for leaving everyone in the dark, but unfortunately we can't yet share the details of what we're building into the implementation.   I understand the delays are frustrating and inconvenient, but us making the implementation the right way will lead to dramatically better Spriter support across the board much sooner. 

Link to comment
Share on other sites

Hi guys!
me and a friend made this C++ implementation.

it works with SFML, and is based in a .NET implementation..

 

the only class that you need to rewrite to adapt the renderer is in:

SMFLAnimatedSprite.h

 

it could be useful meanwhile.

 

https://www.assembla.com/spaces/spritercpp/

 

svn

https://subversion.assembla.com/svn/spritercpp/

Link to comment
Share on other sites

  • 2 weeks later...
  • 4 weeks later...

Welcome to the Spriter community monkeyBrash. Thanks for creating this implementation. I'm sure it will be helpful to many people.

 

Cheers,

Mike at BrashMonkey

 

 

Hi guys!

me and a friend made this C++ implementation.

it works with SFML, and is based in a .NET implementation..

 

the only class that you need to rewrite to adapt the renderer is in:

SMFLAnimatedSprite.h

 

it could be useful meanwhile.

 

https://www.assembla.com/spaces/spritercpp/

 

svn

https://subversion.assembla.com/svn/spritercpp/

 

 

 

So is this then the official C/C++ api for Spriter?

Link to comment
Share on other sites

Unfortunately we're in a tricky situation regarding what we can report about the reference implementation at the moment.  I can say we're making steady progress  and it advanced a while back from the planning/logistics/design stage (making Spriter Implementations more flexible and ready to support several new features) To the concrete coding/development stage.

 

The tricky part is we can't explain the upcoming and planned features that are the major cause of the delay until the implementation is nearly finished and its still too early to have an even somewhat accurate estimate of when that will be.. because some of the upcoming features are quite complex and also because its never completely possible to estimate how much time will be required to take care of other issues like continued bug-fixes update builds, business and family related stuff etc.

 

Sorry again everyone for the delay and thanks very much for your patience. We're doing everything we can to not only get it done, but make it worth the wait.  We're also determined to help make the porting process to all authoring systems and programming languages go as quickly and smoothly as possible immediately after the reference implementation is finished.

 

I'll report back as soon as there's anything more concrete that we can share.

 

Cheers,
Mike at BrashMonkey

Link to comment
Share on other sites

  • 2 months later...

We're interested in implementing the Spriter-format into the importer pipeline of our DNA Framework (a framework geared towards development of arcade SHMUPS in the style of Gradius V, Ikaruga, etc.). This will however not be possible for as long as there is no decent C API, OR a document providing a correct specification of the (data) format so we can write our own API.

Link to comment
Share on other sites

Welcome Coriiander,

As a big SHMUP fan myself, I'm excited to know you're interested in adding Spriter support to your Framework.  We (BrashMonkey) are also very sorry for the big delay in our full-featured reference implementation.

Edgar is working on it as much as is humanly possible; it's our top priority.

 

You can keep track of its progress in the thread here: http://brashmonkey.com/forum/index.php?/topic/4029-reference-implementation-status-update-752015/

 

In the meantime, I'd love more info about your DNA Framework. Can you give us more info, links, etc?

 

Cheers,
Mike at BrashMonkey

Link to comment
Share on other sites

Welcome Coriiander,

As a big SHMUP fan myself, I'm excited to know you're interested in adding Spriter support to your Framework.  We (BrashMonkey) are also very sorry for the big delay in our full-featured reference implementation.

Edgar is working on it as much as is humanly possible; it's our top priority.

 

You can keep track of its progress in the thread here: http://brashmonkey.com/forum/index.php?/topic/4029-reference-implementation-status-update-752015/

 

In the meantime, I'd love more info about your DNA Framework. Can you give us more info, links, etc?

 

Cheers,

Mike at BrashMonkey

Hey Mike,

Thank you for the quick reply, and especially for the provided link - quite useful! I'll be keeping an eye out to it. As for the DNA Framework, there's nothing much public I can provide. I can explain the goal though, and why we're interested in Spriter.

It's a work in progress by myself and 2 others - we're not a company, just indies (well professionals, but we do this aside in our own time). The aim is to provide a framework (API and tools) to aid in the development of portable SHMUPs - as mentioned. As portability has top priority, the API is being developed in plain C, therefor making it easy to port and have language bindings for it (e.g. C++, C#, Java, LUA). 

We currently have a basic sprite system in place - simply texture atlas-based animation. Multi-sprite models can exist through means of parent/child-nodes in the scene manager. While it suffices for the time being, it is not yet ideal - multi-sprite models should simply be more self-contained and self-driven. Work on it continues during this year. In the meanwhile I was looking around for existing spriting tools and APIs. I came across Spriter - quite impressive. Now, as we will be working on the internal spriting system, it would be great if we could do it in such a way that support for Spriter-material is possible. Availability of the data format would be great for that. If the data format and useability fits in with our design and requirements, we may designate Spriter as the sprite format of choice. Though there's other options as well.

Well, as said, I'll be keeping an eye out to the progress. Good luck!

/|\ Coriiander /|\

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...