Jump to content

Spriter cocos2d-x


dr_watson

Recommended Posts

cocos2d-x is a C/C++ port of the popular iOS 2D game engine cocos2d. The latest version supports iOS, Android, Windows, Mac, Linux and Blackberry.

http://www.cocos2d-x.org/

I really like to use Spriter for cocos2d-x and since there isn’t any renderer for cocos2d-x yet, I guess I’ll just give it a shot myself.

This is the first release so I’m sure there will be small issues here and there. I’ll try to keep its update in sync with Spriter itself.

Cheers!

2012.09.14 (v0.6a) – fixed a positioning bug in CCSpriterX class.

2012.09.12 (v0.5a) – added Xcode project.

Screen shot:

spriter1.png

Source (for cocos2d-x v2.0.2):

http://jameshui.com/wp-content/uploads/2012/09/CCSpriterXDemo_v0.6a.zip

Link to comment
Share on other sites

  • 1 month later...

do you have support of the bone animation system ? seems not to find any cocos2dx spriter or andengine support for bone animation.... also i think fliping a stripe in spriter and using it cause problem also, would love to give a hand if you need in adding the bone animation, i have an animation i made if you can get it to work ill appreciate it :)

Link to comment
Share on other sites

  • 4 months later...

Hi @dr_watson,

I wrote a message on your board but I wonder if you can check this board.

I did some update for your CCSpriterX class to support Bones and PLIST

(also changing sprites) but stuck with a problem calculating angles.

It will be nice if you can check my code and release the new code on public.

Either you can give me an e-mail or just write a reply on this post.

Best regards.,

Bruce.

Link to comment
Share on other sites

  • 3 weeks later...
Hi @dr_watson,

I wrote a message on your board but I wonder if you can check this board.

I did some update for your CCSpriterX class to support Bones and PLIST

(also changing sprites) but stuck with a problem calculating angles.

It will be nice if you can check my code and release the new code on public.

Either you can give me an e-mail or just write a reply on this post.

Best regards.,

Bruce.

Hi,

I am facing the same problem as cocos2dx is not supporting bones. So can you please send me your updated code so that I can add it to my project.

Ishan

Link to comment
Share on other sites

Hi @dr_watson,

I wrote a message on your board but I wonder if you can check this board.

I did some update for your CCSpriterX class to support Bones and PLIST

(also changing sprites) but stuck with a problem calculating angles.

It will be nice if you can check my code and release the new code on public.

Either you can give me an e-mail or just write a reply on this post.

Best regards.,

Bruce.

Hi,

I am facing the same problem as cocos2dx doesnot support bone_ref, so can you please give your updated code so that i can integrate it to my project. It will be great help.

Thanks

Ishan

Link to comment
Share on other sites

Hi,

I think your reply was filtered from my Gmail account. I didn't notice that someone replied to my post.

I was waiting for Dr. Watson's response and still my angle calculation is not so good so I thought I better wait rather than disclose.

But I decided to open, because I think my plist, sprite change, and bone support will be helpful to you guys. Please check the attachment and please share if you solve my angle calculation problem.

Regarding the implementation, I tried use transparent CCNodes for handling bones but I was not able to set positions for each sub nodes to the places I intended, and if I apply the scale factor the final result became very ugly. So I did calculations for each level of bones manually.

My test sample (scml) is very simple one os even though it had 3 or more depth of bones, the final scale factor for each sprite became just 1.0f. Actually the designer here didn't want to squeeeze the images he/she made. So maybe mine is not so perfect for handling your very complex animations. The biggest problem is handling 'angle's between the time lines. I am sorry for opening mine in this stage but it is not that ugly than you think.

The static function


static CCSpriterX* create(const char *filename, const char *plist);

creates a CCSpriterX nodes from the plist. You just make your animation with Spriter tool with separate images (because the tool itself don't support plist yet), and you pack those with tools like TexturePacker. Then you just need plist, png, and scml files for creating your own CCSpriter node.

And if you need to change the sprite, or the 'parts' of the animation, you get the CCSprite node from the animation by using following member function.


cocos2d::CCSprite *getSprite(int folderId, int fileId);

If you open the *.scml file, you will see the images are under 'folder' node (of XML file) and the animation happens each 'file' (leaf of the XML file). Each leaf (file)s are represented by CCSprite. So if you know the index number of 'folder' and 'file', you can get the CCSprite node for them and you just change the contents (texture) of the sprite you want to replace.

Finally, as you see mine is not so perfect and I was not able to focus on that because of other work priorities BUT I disclose mine at this stage because it will be good that my humble changes are helpful to you, and surely someone will can solve it simply. If you have another good solution, please SHARE.

I'd like to be the first one when you share yours here, and let me know via my e-mail address.

(brucewang.korea @ gmail . com)

Best regards,

Bruce.

CCSpriter.zip

Link to comment
Share on other sites

Hi,

Did anyone come up with any improvement?

This Friday I gave it a shot for simplifying the problems so that you can catch up the problematic part.

Download and unpack the attached ZIP file and you will find 'Classes' and 'Resources' folder.

Overwrite the CCSpriterX.cpp/h, and HelloWorldScene.cpp of Dr. Watson's original code and add the resources inside the 'Resources' folder into your XCode project.

I made very very simple SpriterX animations with bone object to simplify the problems.

This test seems to be working, but sadly in my actual project which uses more complex animations the result is not so good. More precisely, I call 'calculate_rotation' function in the 'Animation::Update' to transform the location and angles per time changes but this is the place where problem occurs (test project is working fine). And I removed all the 'pre-calculation' of the positions and angles to test my new logic. This must be done for better performances...

20130420_2.zip

Link to comment
Share on other sites

Revised

Hello, I did some improvement on the angle calculation.

Again you unpack the Zip file attached and overwrite source files in the 'Classes' folder and add resources in the 'Resources' folder to your Xcode project.

Angle calucation almost works fine, but still my animation behaves not so fancy.

The problematic part is line 1042~1049 of CCSpriterX.cpp, where you can transform the angles as per the time changes, or just use that one of the first keyframe. If you just use the angle value of the first keyframe then you will see the position is just fine only the angular movement is not happening. And if you use my calculated angle transfromation, it moves but slight ugly behaviors you will see.

So I belive If I or anyone of you can revise this angluar problem then this will be much better.

20130422.zip

Link to comment
Share on other sites

  • 3 weeks later...

good job guys on the progress, but i think most people who bought spriter for cocos2dx are very disappointed, we also gave our shot on trying to fix it, but it seems to do problems with rotation and the bone system.

would like to see some progress from the brashmonkey.com guys to help out on pushing a perfect working cocos2dx implantation.

if u have any new progress please share with us and keep up the good job. i am willing to provide high quality spriter animations i made for testing. (since i am not a programmer i cannot help with code :( )

keep me posted :) thanks

Link to comment
Share on other sites

  • 4 weeks later...

hey, was wondering when 1.0 is planned on release ? i bought it because i thought it will be anytime soon (as it was mentioned on the kick starter), but seems like its not going to see lights anytime soon, and i cannot wait that much since cocos2dx is not working at all and all buggy.. so my spriter license is basically not usable :( . so i had to move to "SPINE" which the implantation works smooth.....and feels really robust.

sorry guys but i do consider that a major screw-up :( even though spriter is not 1.0 you should have pay more attention to the implantation, because your current version works. but even basic animation dont work in some of the pupolar engine like cocos2dx.... (all pivot and rotation is all messed up!)

its makes me really sad. since i like your editor so much!

i think you guys did an amazing job on the front end, the user experience, the ease of use, and the animation approaches! (pivot + bones option!!) i'll give you the credit for that! you did stunning job and did it right! for every animator i know it will be really easy to start using spriter.

just from day one i downloaded your tool in about 2 min i understand how to do anything without reading or watching any tutorial! :) now thats big! really big. you also started a revolution.

but.....as long as i cant use it :| i wait... and wait... and wait... and start loosing time with my game creation just because i wanted to use spriter....

but really, its been too long, i know there have been some health issue involved, and i do feel and hope for the best and a full recover to edgar, this is more important and comes first.

but i do feel maybe you should hire someone that will help you out to reach your goal and what you promised to people. ( or someone that just work on implantation !)

spine did it right on that matter, their app is rock solid, and seems really smooth, all implantation works amazing

but their front end and user experience is not perfect, and not "animator friendly" like spriter is. but i can live with that...

their community is super active, you get response instantly! and they work on improving the front end UX

so it took me sometimes to get to understand spine..and learn how to use it ( its still hard) but im sorry, i had to move on to SPINE, had no other choice.

i think your priority is twisted a bit. i get that you want to wait for the official release so all the code will be fixed, so no changes should be made for the implantation.. but

there is no shortcut here, i would prefer a working implantation of cocos2dx for instance, with the current version, then having the full 1.0 version earlier, since your product works well already! few bugs there and performance is something we can live with... maybe think about it... you lose people using your program just because of that, sometimes its more important to listen to the people then do what u think is best for them, just a thought though.

thank you.

i will still wait and see, and have a room for spriter in my heart.. :}

but now...as hard it is to say it... its just unusable... :| and the whole pre-order thing.. is kind of annoying actually... since i dunno if ill ever see 1.0...:( :( :(

Link to comment
Share on other sites

Hi bobo,

We can't make any specific estimate for when the first fully featured Spriter Pro will be released. We learned that lesson some time after the big delay you already know of blew us far past our initial estimates. We've made Spriter's development as transparent as possible through our forums and releasing useful builds as frequently as possible. (a new build is almost ready for release in fact). There is no more accurate or useful way for us to let everyone know how close Spriter is getting to 1.0.

Of course we are not remotely happy about the delay ourselves, and think its great you have something else to use until Spriter catches up to where it would have been. We're confident once Spriter reaches 1.0 it will be well worth switching back to it.

About support for development platforms, please remember your favorite is by no mean's everyone's favorite. There are so many popular and capable development systems out there trying to learn and develop Spriter support for all or most of them while simultaneously developing Spriter would at the very least have drastically slowed down support of Spriter itself to a disastrous degree and resulted in an inferior tool and data format...conversely if we tried to pick a handful of “favorite” development platforms to create support for asap, it would have lead to much negativity and trolling from those who's favorite development system was not among those first few.

Quite simply, we're doing all we can, and as best we can, but were delayed. We are extremely grateful to you and the rest of Spriter backers for your support and patience...and we know the best way we can show our gratitude is to make Spriter the best tool it can be as quickly as possible, and immediately thereafter shift gears to helping get full Spriter support working for all popular authoring systems.

We're doing what we can to get Spriter with its most critical features fully function as quickly as possible (before the full 1.0 release), and then create and release concise documentation to the community, which will make creating full support for all those key features as quick and effortless as possible for all authoring systems. This should not only allow developers to get all key Spriter features running in their authoring systems of choice, but should also ensure that adding in the remaining few features will also be quick and painless once they appear in Spriter.

Lastly, all I can say is we do listen very carefully to the community, our supporters and developers, and take all suggestions, requests and feedback into very careful consideration. Ultimately we hope that you have faith in our ability to decide how we can best serve all backers, which by necessity must serve at least a slightly more long term mindset... though this was certainly made longer than we'd hoped due to the delay caused from the injury.

Cheers,

Mike at BrashMonkey

Link to comment
Share on other sites

thanks for your comment.

i do support spriter and will wait and see any progress made. but as for now i cannot hold back my studio pipeline.

as for favorite platform, u could just make a generic C++ that works and we will make the cocos2dx port, but there is no generic C++ that works with rotation (we tried making it our own but its full of bugs) once you will make that happened it will be much easier to make ports and implantation for the community.

i do know lots of my friends who preorder spriter for cocos2dx, and this is consider a popular platform, not an "exotic" one. but anyway keep up the good job, and make spriter the best tool out there (see where your competitor succeeded and where they failed and learn from it - nothing bad or wrong learning from others) as i said before i do think your tool will be more popular among animators need, since its super easy to get.

make it happen, and keep the good job going...

but dont forget that even the best car in the world cannot drive without wheels.

thank you.

Link to comment
Share on other sites

Thanks for the encouragement bobo.. We will continue pouring every ounce of time, hard word and careful though as humanly possible into Spriter... it's not just some side thing for us...we're very passionate about doing it right and changing the standards for how fun, flexible and productive an animation tool can be.

cheers,

Mike at BrashMonkey

Link to comment
Share on other sites

  • 1 month later...

Hi Bruce,

Thanks for posting the updates. I tried out your latest version and it mostly works except for a few errors. May be they are trivial for you to solve and you can have a look.

1] First, we can attach one sprite to one bone only. If I attach the same sprite to multiple bones, then only the first sprite is visible, i.e. only 1 copy of a sprite is visible on the screen and all other copies are invisible.

2] I tried this with another sample posted on this forum itself of a Japanese style Demon. The animation behaved a bit differently, I think there is something still a miss with angle calculations.

Thanks,

asloob

Link to comment
Share on other sites

  • 2 months later...

Hi,

I had to bump this, because I don't want to open a new thread because of that.

Is there any update on this coming ?

Does not work in any way on new cocos2dx versions,

I tried to debug it but there are to much errors for me.

I'm not a good debugger.

I going to try Spine atm, because they have support for most platforms,

cocos2dx, too.

Can't wait longer to implement npc's into my game.

Link to comment
Share on other sites

Hi bobo,

Until Spriter 1.0 is feature complete and released/delivered to all paying customers we must remain focussed on that.. However, we're getting close, and once Spiter 1.0 is released, we'll switch focus to helping get Spriter fully supported on all popular authoring systems.

The next Spriter release should be out in a matter of days and will include most of the remaining 1.0 features... stay tuned...

cheers,

Mike at BrashMonkey

Link to comment
Share on other sites

Hello guys!

As most of you probably know, Riq is leaving cocos2d-iphone for the sake of the cocos2d-x, wich is now under Zinga's wing. It makes cocos2d-x primary mobile 2d engine if it isn't already.

While spine is there already, it's not as well engineered as spriter is (personal opinion), and its cocos2d-x implementation is lacking in some ways (for example, it uses custom draw method wich is nice and all, but lacks in many ways, like modifying it to be SpriteBatchNode child is hell of a trouble) for the one making a game with tons of characters rendering simultaneously it could be inexistent as easy.

I would very much like to use spriter. Yet cocos2d-x implementation (or at least well written c++ generic) been missing is very troubling. I mean Very. I myself unfortunately have too much on my hands to make it any good.

I wonder if it is possible to get one for a buck and how much can it cost to be developed? I'm willing to pay any reasonable amount.

If there are people with same interest we can get our funds together and hire somebody to make it.

My primary concerns are: implementation been made robust, well documented, easy to maintain, and if it goes whole way to be in cocos2d-x, actors should be SpriteBatchNode ready.

Will appreciate any cooperation.

Link to comment
Share on other sites

  • 3 months later...

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