Hi folks,

today I have another announcement for you:

Some of you will already know Stencyl and their no-code-instant-release game creation suite called Stencylworks. I am happy to inform you that they have a new product available that may very well be of interest to you: iStencyl.

iStencyl makes you create native iOS games in a no-code fashion and uses the Sparrow Framework to bring it’s games to life! Woo-ha!

Thou shalt also check out this video trailer for Feed My Zombie to see what iStencyl is capable of:

That’s it! Happy holidays!

Hi folks,

today we are very happy to brief you on something a bit aside from this blog’s default candy:

We just got word from Villain that their newest game Lil’ Birds landed in the AppStore today. Lil’ Birds allows you to breed, pet, feed, collect and share birds to your liking. It transforms your device into a feathered cuteness machine.

“But what does this have to do with Sparrow?”, you ask.

Well, for one it’s about thousands of cute little birds and we obviously love birds. But there is more to it than the eye can see:

Lil’ Birds is based on the Sparrow Framework!

Yes you heard right. All those birds are flying by the power of Sparrow. Lil’ Birds is a production of huge value done by a team of experienced game developers. This is exciting news for us since it verifies what most of us already knew:

Sparrow easily carries the weight of a large and professional game production.

By the way: The game is free as a bird and thus I recommend you check it out to see what Villain created on top of Sparrow!

Well, that’s it for today. Happy coding, happy breeding and see you soon!

Hi folks,

I’ve got some busy weeks behind me, working hard on Sparrow’s new sibling, the Starling Framework. I already hinted that a new project is in the works in the Cocos2D Podcast, and some forum members might have read some mysterious remarks on that topic, too. Well, I’m excited that I’m finally able to tell you what this is all about!

What is the Starling Framework?

Most of you should know that Sparrow was heavily inspired by the Flash API. The target of Sparrow has always been to let developers use an API that is very similar to Flash on iOS. So it might come at a surprise when I tell you what Starling is:

Starling is a port of Sparrow to Flash.

Yes, you’ve read correctly! I agree that it sounds weird to port a Flash-port back to Flash — but it makes a lot of sense when you take recent developments of the Flash Platform into account.

Stage3D

Flash Player 11, which was announced today, introduces a new low level 3D API called “Stage3D” (formerly “Molehill”). This allows Flash developers, finally!, to leverage the power of modern GPUs (conventional Flash is rendered almost exclusively by the CPU). Conventional (old) Flash applications won’t profit from this new feature, though: you have to use the new APIs (which are very low-level, just like OpenGL) to get the speed-up.

And this is where Starling enters the stage. It provides you with an API that is almost identical to the Flash (Sparrow) API, but uses Stage3D in the background. That means: if you develop a new game with Starling, you don’t have to learn a new API, and will still have a much better performance than conventional Flash; furthermore, porting an existing game to Starling will be extremely easy.

System requirements

One of the great things about Flash is that you can push SWFs to a plethora of devices. On PCs and Macs, it will run in any browser — this is what Flash is known for. But it runs on mobile devices, just as well: that’s, of course, Android and Windows Phone 7, but also iOS (Apple released the restrictions that prevented Flash content a while ago). The recent versions of the Flash SDK allow you to export to those devices with minimal effort.

Until now, the problem with Flash on those devices has been the performance. It worked, but you reached the limits rather quickly, simply because CPU power is rather limited on mobile platforms. Stage3D with GPU support, however, fixes the performance problem; and Starling provides you with the means to leverage that power easily.

But what about Sparrow?

However, that does not mean that Sparrow, or any other native frameworks, will become obsolete anytime soon. Only a native framework allows you to access all APIs of a system (GameCenter, Photo chooser, iAds, etc.). And a native framework will always have the best performance. That’s just the way it is. Starling shines when you want to create platform independent games, web games running in the browser, or for prototyping (because AS3 code is just much easier to write). Sparrow can show its strength when creating high performance, optimally integrated iOS games.

Thus, I will of course continue to develop and support Sparrow. In fact, when you use Starling, you’re already peeking at Sparrow 2.0, because it will share the same architecture. From the outside, not much has changed, but internally I laid the groundwork for many new features like filters (drop shadow) and 3D content. Thus, Starling is closer related to Sparrow 2.0 than to the current version.

About Adobe

I cannot not end this blog article without mentioning my sincere gratitude for the support and trust I received from Adobe while developing this framework — especially from Thibault Imbert, Adobe’s product manager of the Stage3D initiative. In fact, porting Sparrow to Flash was his idea — of course, I had thought about it myself, but I didn’t think Adobe that would be interested. Well, thankfully, I was mistaken! The Starling development was funded by Adobe, and they are investing a lot of time and effort in spreading the word about it. I can’t thank you guys enough for this opportunity!

Links

Finally, here is a list with many links pointing to more information about Starling.

• Official Homepage — the preliminary homepage of Starling.
• Support Forum — Sparrow users can login with their username.
• API reference — Sparrow users should find it familiar!
• Tutorial book — A huge (100+ pages!) tutorial book from Thibault Imbert that will teach you everything you need to know.
• Introduction video — A screencast from Lee Brimelow, showing you how to get started quickly.
• The particle system you all know from Sparrow is available from the start!
• A Wiki and an extended homepage will be added later.

That’s it for now! Happy coding, my friends!

Hi everyone,

Daniel has already teased this in the recent podcast about Sparrow but now it is official: Our fun little project Kabaam has hit the App Store today. Naturally it’s a single malt Sparrow App seasoned with just a little bit of UIKit.

As if that wasn’t enough happiness for today, there is one more sparrow-related thing I’d like to share that came up during development:

How to convert SPRenderTextures to UIImages

One thing Kabaam does is overlay some text bubbles onto a photo the user shot. The photos/comics can then be exported to email and diverse social platforms. In order to accomplish that the whole display tree has to be rendered to an exportable image. Although we’d love to stay 100% pure Sparrow for most of the time it makes sense to use UIKit to help us here. That’s why I extended the SPRenderTexture to allow rendering it to an UIImage. Many of you most likely already know how to do this, but maybe this snippet still helps one or the other to get earlier results.

Here is the interface extension:

@interface SPRenderTexture (RenderToImage)
- (UIImage*)renderToImage;
@end

And here is the magical part. In short, it makes use of the bundleDrawCalls method on the SPRenderTexture to get to the current GL context. It then allocates memory for the resulting image and reads the pixels from the GL context into the allocated array. After that we can feed that array to a CGDataProvider, a CGImageRef and then to an UIImage. All that’s left to do is tidy up some memory, which is unfortuantely very C-ish in this case: We have to register a releaseRawImageDataBufferCallback with the CGDataProvider in order to release the allocated array when everything is over. Check it out:

@implementation SPRenderTexture (RenderToImage)

void releaseRawImageDataBufferCallback(void *info, const void *data, size_t size)
{
	free((void*)data);
}

- (UIImage*)renderToImage
{
	__block UIImage *image = nil;

	[self bundleDrawCalls:^() {
		float scale = [SPStage contentScaleFactor];
		int width = scale * self.width;
		int height = scale * self.height;
		int nrOfColorComponents = 4; //RGBA
		int bitsPerColorComponent = 8;
		int rawImageDataLength = width * height * nrOfColorComponents;
		GLenum pixelDataFormat = GL_RGBA;
		GLenum pixelDataType = GL_UNSIGNED_BYTE;
		BOOL interpolateAndSmoothPixels = NO;
		CGBitmapInfo bitmapInfo = kCGBitmapByteOrderDefault;
		CGColorRenderingIntent renderingIntent = kCGRenderingIntentDefault;

		CGDataProviderRef dataProviderRef;
		CGColorSpaceRef colorSpaceRef;
		CGImageRef imageRef;

		@try {
			GLubyte *rawImageDataBuffer = (GLubyte *) malloc(rawImageDataLength);

			glReadPixels(0, 0, width, height, pixelDataFormat, pixelDataType, rawImageDataBuffer);

			dataProviderRef = CGDataProviderCreateWithData(NULL, rawImageDataBuffer, rawImageDataLength, releaseRawImageDataBufferCallback);
			colorSpaceRef = CGColorSpaceCreateDeviceRGB();
			imageRef = CGImageCreate(width, height, bitsPerColorComponent, bitsPerColorComponent * nrOfColorComponents, width * nrOfColorComponents, colorSpaceRef, bitmapInfo, dataProviderRef, NULL, interpolateAndSmoothPixels, renderingIntent);
			image = [UIImage imageWithCGImage:imageRef];
		}
		@finally {
			CGDataProviderRelease(dataProviderRef);
			CGColorSpaceRelease(colorSpaceRef);
			CGImageRelease(imageRef);
		}
	}];

	return image;
}

@end

As soon as we have that UIImage in our hands we can (thanks to UIKit convenience) very easily convert this into JPG or PNG format using the UIImageJPEGRepresentation and UIImagePNGRepresentation helpers.

Hi folks,

some of you might have had an unpleasant surprise on their last visit of the Sparrow-Framework pages. They were welcomed not with a cute, innocent, little bird — but with this serious looking security guy:

You can imagine how thrilled I was at his appearance!

Well, the fact is: he was right. Some bad, unfriendly criminal (reportedly he was unshaved and rather fat — not a pretty view!) used a vulnerability in one of our scripts to insert some bad code into our web page.

Being a very cautious person, I’m always keeping the server software up-to-date, and the bad script was already fixed a few days ago. However, it seems that I was a little too late — the intruder had already exploited the vulnerability. However, we found the change he made and removed that code. It will take a while, though, until our domain is removed from Google’s blacklist.

Now, the important part: was this dangerous for our visitors? Fear not, I haven’t heard from any actual harm being done. Most malware does not work on up-to-date browsers and operating systems anyway (and are targeting Windows, while most of you will be running OS X).

So, all I can do now is apologize for the inconveniences this might have caused. We’ll do our best to avoid attacks like that in the future — but as we just learned, there’s no guarantee for anything; not even for our small chicken. Ehm. Sparrow.

EDIT (2011-08-26): Heureka, Google removed us from the blacklist! The warning page has gone.