Have you seen the new Sprite Kit in iOS 7 ?
Seems to be a Sparrow like API integrated into iOS.
Sprite Kit in iOS7(38 posts) (19 voices)
Have you seen the new Sprite Kit in iOS 7 ?
yeah, sounds awesome.
it also includes a physics engine.. it will be fun to mess with that
I don't quite understand why they are doing that, where there are already dozens of Objective-C gaming frameworks around. That's going to be super hard for Sparrow.
What do you guys think about this? What does this mean for the future of Sparrow? My guess is that many developers are going to adopt SpriteKit now.
Haven't had a chance to look at SpriteKit yet, so I don't know...
But it'll definitely be really annoying if it looks like the way forward after converting all my stuff bit by bit to Sparrow 2.0!!!
Depends if sprite kit has all the bells and whistles... atlas support, decent sound support built in, heirarchy control etc
Hmmm, having just read through the preliminaries, it sounds like it *does* have the stuff I mentioned.
Info can be found here:
This is a real shame in many ways, and definitely will make it hard to tempt new users to Sparrow...
I think Starling may be the only way to go because of the cross platform stuff...
What about some kind of Sparrow "wrapper" for Sprite Kit... maybe a kind way of using the existing (or similar) classes and functions to call Sprite Kit instead... and filling in the gaps that Sprite Kit doesn't fill... is that Sparrow's future?
I am sure developers will still come to sparrow for a great framework and a great supporting forum.
Mhm, I think so, too, TTStu! What's still an advantage is the similarity to Flash and Starling -- so it stays a very good choice for Flash devs. But for others ... it will be hard to convince them to use Sparrow.
As for the wrapper, I'd have to play around with their API to see if that makes sense. One could create extensions that add missing functionality -- but that would have nothing to do with the Sparrow project.
ERik, thanks for that!
Actually, I totally agree about the forum and support -- getting any help on anything from Apple is almost impossible. And Sprite Kit is not Open Source! Good luck fixing it when it's broken -- which is not that rare with iOS APIs.
How about converting Sparrow / Starling to Haxe OpenFL?
Sprite Kit could never compete with such multiplatform framework that enables publishing to many platforms including IOS...
Actually, Starling is already very close to that.
Except that it uses classic Flash, of course. But yes, multiplatform seems to be the way to go at the moment. Pure Objective-C frameworks are getting more and more abandoned. (Perhaps this was one of the reasons Apple introduced SpriteKit.)
Yep, veeery close.
Too bad that AIR will not come to Windows mobile.
There is already H2D/h3D library that enables using Stage3D with Haxe:
And there's TileLayer library that uses OpenGL for native targets:
http://lib.haxe.org/p/tilelayer (includes a Sparrow spritesheet parser btw.)
I only wish there would be a Haxe version of Starling that could wrap all these possibilities together into a single framework with familiar syntax...
no need to be worry...
there was also cocos2d available and people didnt change to cocos2d because sparrow framework is great! I think they introduced it because some people still develop by using Core animation or Quarz core... The main reason why they developed the spritekit must be because of OSX... to make it easier for developers to port their games and apps... For me the way to go is always your framework or pure OpenGLES 2.0
Even if you use it directly porting stuff is getting much more simple ;D
Thanks for all the nice words about it, guys!
After sleeping over it, I'm much more optimistic. You're right, Schreda -- there always were other 2D frameworks around! Sparrow has several advantages over them, and over SpriteKit:
* There will always be people who prefer Sparrow's simple and flexible approach of creating games.
* It will always be open source!
* Which makes it easy to tinker with, modifying it so that it becomes just the framework you need.
* When it's broken, people can fix it -- or ask me to do that. Good luck with getting such support from Apple!
All in all, I think this image sums it up really nicely:
That's the spirit, Daniel Keep up the good work
I certainly won't be dropping Sparrow any time soon
Thanks for the nice words, guys!
I'm having a good time with Sparrow 2.0, super productive and the performance is amazing. Apps are running smoothly on all my devices (hat tip to TexturePacker). I've just integrated Box2D to wrap bodies/fixtures around sub-textures and it works like a charm. I will eventually share my B2D helper class that wraps these methods with the community.
hcabral, thanks a lot for the feedback! That's great to hear! =)
It would be awesome if you could share that B2D wrapper with us in the future. This is something that Sparrow really lacks -- any help in that respect would be amazing for Sparrow.
LOL, MicusFicus, I read that term a few times yesterday, but didn't know the actual meaning -- made my day!!!
Have to agree on the physics engine. For my money an easy to use physics engine is apple's strongest argument, the only one also i find appealing.
Not that I have done many games, but when i have I think the most difficult parts have been physics, but most of all efficient collision detection, with a big emphasis on efficient.
I think it would be really interesting to see an idiot proof hook into box2d. Could be an amazing thing for many.
Integrating Box2D is relatively easy if you know a little of C++ (and I mean a little, the API is super clean).
What I'm trying to achieve is a hybrid of the the "magic" polygon creator such as the one in PhysicsEditor and the Box2D fixtures, at least simple ones (boxes, circles, polygons).
- (void) addCircleWithObject:(SPDisplayObject*)obj density:(CGFloat)density friction:(CGFloat)friction restitution:(CGFloat)restitution; - (void) addBoxWithObject:(SPDisplayObject*)obj density:(CGFloat)density friction:(CGFloat)friction restitution:(CGFloat)restitution; - (void) addPolygonWithObject:(SPDisplayObject*)obj density:(CGFloat)density friction:(CGFloat)friction restitution:(CGFloat)restitution; (...)
The trick now is to map the polygon vertices to B2D automagically in the code, and keep a low number to conserve performance ( < 20 vertices). All other properties such as position and pivot point come from the SPDisplayObject itself.
Excellent hcabral. Good work. I will keep my eyes open for your helper or look at the source myself, if I get the inspiration. I have done a bit of c++ before, but I would not say I am super confident.
Thanks for sharing anyway hcabral.
I've testet SpriteKit few hours, my two cents, pros/cons versus Sparrow :
- SK is very very simple and very well integrated with storyboard
- SK CIfilters & blend mode are very simple (however CI filters are quite slow)
- Scene API is a good point
- Future upgrade : Since it's an Apple API (v1), we can be sure that Apple will make a lot of new features in futures SDK.
- Integrated physic engine
- Not open-source !!!
- Black-Box (you have no access to shaders, custom vertices or low-level open GL features).
- Locked to Apple
From my point of view, Sprite Kit is (for now) a powerful framework but it's very limited due to the lack of possible low-level extensions. I think professional game studios will not use it & prefer to use some "free" low-level sources code like Sparrow or custom Open GL code, since you can have a total control if you want to build custom effects / objects.
However, for indies developpers or beginers, SpriteKit makes sense : easy & powerful.
Concerning the idea of a wrapper : IMHO, it's not a good idea. Sparrow is more low-level than Sprite Kit. So if you make Sparrow on top of SK, you will be very limited compared to OpenGL 2 raw API. Also, Sprite Kit has its own very simple logic / API (not so bad).
Conclusion : I think that Sparrow will continue to be my first choice if I want custom power / control for special cases. For prototyping or doing very simple things, SpriteKit could do the job.
But this is true "now". Perhaps not in the future. If Apple provide some way to customize Shaders / Vertices, Buffer in future version of SpriteKit, it could begin my first choice.
The other point is, since it's an official Apple API, many publisher/author will probably wrote many books, it's an real advantage for SpriteKit...
So, keep up your good work, Daniel, I'm sure the Sparrow community will continue to follow this project, as It's, right now, the most clean / powerfull / well-coded 2D framework on iOS
thanks a lot for writing down your thoughts about Sprite Kit and its effect on Sparrow! I haven't played with it myself yet, but I watched the video from the WWDC. I came to about the same conclusion as you described in your post.
In addition to your pros, I'd add that for the next 1 - 1.5 years, it will still matter to some developers to support iOS 5 & 6, because there is a considerable number of devices that can't upgrade to iOS 7.
In this timeframe, it would be important to get OS X support and a good physics wrapper ready. Then all the important features would be on par with Sprite Kit, and people could base their decision on the OS vs. black box argument.
Both of those features are definitely feasible! So while Sprite Kit hasn't exactly made life easier for Sparrow, there's still a chance for it to be useful for developers.
Thanks again, Didier!
Watched the WWDC sprite kit video very impressive ! A must see !
I think Daniel hit it on the money in his post two above this one. Especially right now, it is important to still support iOS 6.x devices. A policy I am fond of is supporting the two most recent major versions, if possible. When iOS 8 starts to come out, then it might be time to work on a list of what Sparrow provides over SpriteKit. For now, iOS < 7 support is a good enough reason for anyone I think.
However, on the negative side, a lot of people prefer to use Apple frameworks as opposed to a third party one for two reasons:
1) They don't have to mess around getting it integrated
2) It reduces the size of their binary because Apple frameworks are dynamically linked
I think it's best to use this time to think about how to best convince people that Sparrow is superior to SpriteKit. There may come a day when Sparrow is forced to retire in favor of Starling, but I hope that's not the case.
Thanks, Borrrden! I'm glad to see that you and other see it just like I do. =)
I have been lurking a lot lately in order to find solutions to my programming problems, but always solving them myself. However, your friendly and passionate community has been a real pleasure to read. I have thought a lot about SpriteKit and I would like to offer a possible direction.
Apple's SpriteKit will change many things. We should jump onto the many positive opportunities that comes with it. In programming for iOS (or at least the cutting-edge games we work towards) forwards-compatibility is far more important than backwards compatibility. As importantly (perhaps moreso), customers with the newest iOS version always have the highest buyrates.
Sparrow development should focus around SpriteKit immediately. We should leverage what Apple offers and add what we need. Integration with iOS would be greatly improved by using more native components, which might be good for performance but mostly great for integrating external features such as voice and camera gestures/face recognition. Binary sizes would go down too.
Sparrow could then map to both SpriteKit and the original libraries. We could add bindings for Chipmunk and/or Box2D as well, since it would be good to compare several physics engines before settling on a single one, even on iOS 7... In fact, most of the uncertainty from SpriteKit seems to stem from the physics engine and it would be a definite feature to edit a header and recompile without a mess.
It would be work but I'm up for sharing my code. I'm downloading iOS7 and SpriteKit so we'll share insights.
We then might be able to write a book and put it out before Christmas
thanks for the nice words about the Sparrow community, and for sharing your thoughts on Sprite Kit!
You're right, in the long run, the future versions of iOS is all that counts. Still, many developers will want to support iOS 5 and 6 a little longer, until it's share in the install base is negligible.
I don't quite understand what you mean with "Sparrow could map to both SpriteKit and the original libraries". Do you mean recreating the Sprite Kit API, or extending it?
The way I read it was that you could have (probably a compile time, but it could also be runtime via method swizzling etc) option to map the Sparrow APIs to Sprite Kit, or map them to the original implementation. That would allow two things. Firstly, it would allow the developer to test both methods and see which one performs better for their particular case, and secondly it would allow the developer to easily switch over to SpriteKit in the future when iOS 5 / 6 support becomes less of a big deal. I am on the fence on this one, though. Your focus may be better elsewhere.
You must log in to post.