Wow, it’s been a while since we first revealed Pixelwave. I’m delighted to announce that Pixelwave is now publicly available to everyone.

Today marks the official birth day of Pixelwave as it leaves the warm womb of the private beta phase and enters the real world. We are very thankful to our awesome testers who gave us priceless feedback and support. But, as Simon would say, enough with all the self-indulgent nonsense. What are you waiting for? Give it a go.

Where do I start?

We’ve created a comprehensive documentation center to help ease the learning curve as much as possible.

Your very first step should probably be the getting started guide.

What’s Pixelwave all about?

Pixelwave is the framework we’ve always wanted to use. It lets you easily create fast, efficient, hardware-accelerated 2D games and interactive applications for iOS. Being game developers with a background in web, we were inspired to model it after the ActionScript 3 API.

Pixelwave was designed with the following goals in mind:

• Speed – We try to get the most out of the device by coding all the core stuff in C and doing lots of invisible OpenGL optimizations.
• Simplicity – Above all, we believe a great framework must be easy to use. Pixelwave’s interface is written in pure object-oriented Objective-C. We labored over each class, method, and property name to create an intuitive and accessible interface.
• Documentation – At the end of the day, even the greatest open source project would be unusable by most without proper documentation. We’re actively trying to avoid that.
• Open source – What started out as a small internal project has already grown into something much bigger. We’re thrilled to see where the open source community can take this project now that it’s out in the wild.

You can read more about the ideas behind Pixelwave in the 5 minute intro to Pixelwave over at the documentation center.

What can I do with it?

Pixelwave is all about creating interactive 2D games and applications that need to be fast and efficient.

If you want to create a clone of Mail, for example, you’re probably better off using UIKit. But if you’re looking to make a real-time hardware-accelerated 2D game, Pixelwave is the right tool for the job.

You can learn more about Pixelwave’s capabilities in the hulky manual.

Who’s using it?

Though the framework is still in its early stages, Pixelwave’s private beta has already produced a couple of App Store games (Sneak Out!, KickBox), some in-development projects, and there’s even a class being taught with it.

What does it come with?

When you download PIxelwave you get:

• The Pixelwave framework.
• The PixelKit framework, which adds useful tools for game developers.
• A bunch of samples to get you started.
• Several useful Xcode templates.
• A complete API reference (Including a native Xcode docset).

And there’s always the documentation center with lots of yummy articles.

And all of this is free?

Yep, it’s available under the (very) permissive zlib license. Why? Because we believe in the power of open source.

In conclusion

This is the start of something pretty big. We have high hopes for this framework and hope you enjoy it as much as we intended you to. So feel free to join the forums, follow us, fork us, tweet about us, and help us get the word out about Pixelwave.

Cheers!

Today I’m really excited to introduce something we’ve been working on for quite a while here at Spiralstorm.

It’s called Pixelwave and it’s a complete framework for building 2D games and applications on the iPhone, based completely on the Flash AS3 API.

The idea started around mid-2009 when we realized that there really weren’t any good 2D engines out there for the iPhone that wrap OpenGL ES in a clean, object orientated framework, while running in a really fast, optimized way.

We’ve also been using Flash for ages, and decided to start out by using the same class and function names used in Flash to make our lives easier.

The engine has come a really long way since, actually getting overhauled twice until we had something we’re really happy with.

Our main goals were ease-of-use and optimized rendering. The end result is an optimized C-based core, with an easy to use Objective-C interface.

The framework now replicates a lot of the core functionality of Flash in Objective-C. We chose to go with Objective-C over C or C++ because of it’s inherent similarities to Actionscript 3, at least as far as sharing the same concepts for classes/interfaces/methods in a very clean and simple API.

To keep things as fast as possible though, the engine’s core is built completely in C, and wraps OpenGL very intelligently, doing a lot of optimizations for the user for free.

So when we realized just what an awesome tool this creation has become, we decided we need to share it with the world, and open-source it for everyone!

So lets talk features. Here are the big ones:

• Super optimized OpenGL rendering. You just tell Pixelwave where to draw, it’ll take care of the rest
• Very clean API, following the Flash ActionScript 3.0 framework structure.
• Simple event dispatching model, just like Flash. Event bubbling and capture phase included.
• Handles native iPhone features with style. (ex: Listen to touch events just like you would mouse events in Flash, very intuitive)
• Native vector drawing, using the Graphics class
• TextFields with native or custom fonts.
• One line texture loading, supporting many different texture types
• Simple sound playback
• Very easy to extend the engine’s functionality (if you know OpenGL) by subclassing the DisplayObject
• Plays nice with Cocoa Touch, contained completely within a single UIView

So we know all those features are awesome for general use, but seeing as we are all about creating games we thought we’d also share our useful utility classes specialized for games. Since these aren’t a part of the core engine we grouped them into the PixelKit, a collection of classes for game makers to use with Pixelwave. It’ll all be in the same package, pre-integrated for everyone to enjoy.

Main PixelKit features:

• Resource Manager – An efficient, object-oriented resource manager that can handle any file type + sync/async loading
• Animation Importer – Turn your Flash MovieClips into PixelKit AnimationClips with the PixelKit animation importer and the Flash animation exporter (more on that below)
• Tweening engine – A must for any real app, integrated with PIxelwave
• A Particle System – An optimized particle system for use with Pixelwave
• Physics engine bindings – We like Box2D

The Flash exporting conversion tool is another, completely separate app we’ve been working on for a while. It lets you turn your Flash animations into PixelKit AnimationClips, and control them with commands like gotoAndPlay, gotoAndStop, etc. We’re going to keep this one on the down-low for now, expect more info on this in the future.

This framework shines when it comes to code. Things that would take dozens or hundreds of lines before can be achieved in only a few. Whether you’re familiar with the Flash API or not, this framework provides a clean, easy-to-learn API that just makes sense.

Creating a vector shape:

PXShape *shape = [PXShape new];
[shape.graphics lineStyle: 1];
[shape.graphics drawRect: 0 : 0 : 100 : 100];

shape.x = 50;
shape.y = 50;
shape.rotation = 45;

[self addChild: shape];
[shape release];

Loading and displaying an image:

PXTexture *smiley = [PXTexture textureWithFileName: @"smiley.png"];
[self addChild: smiley];

Listening to an event:

[self addEventListener: PX_TOUCH_EVENT_DOWN listener: PXListener(onSmileyTouch:)];

- (void) onSmileyTouch: (PXTouchEvent *)e{
    smiley.x = e.localX;
    smiley.y = e.localY;
}

If you’re a Flash developer, we also want to know what you DON’T like about Flash. Yup, we figured if we’re already getting our hands dirty we might as well fix those little nuances that drive us crazy with Flash every day. For example, in AS3 you probably find yourself writing this alot:

sprite.scaleX = sprite.scaleY = 0.5;

Well, in Pixelwave the DisplayObject has an extra, derived property called ‘scale’. Changing scale modifies both the scaleX and scaleY property.

sprite.scale = 0.5;

As you can see we’ve been very busy here at the Spiralstorm offices. We’ve been developing all these tools for internal use, but we think the community can take them to places we’ve never even imagined. Everything will be open-source, I can’t wait to see what will happen.

So please, tell us what you think! We’re nearing the beta testing stage soon.
If you want to help us test all this, please contact us. We’ll keep you updated.

I, (Oz) also have the great honor of speaking at 360|Flex and 360|iDev these upcoming two months, and guess what I’ll be demoing…
If you’re going to be attending 360|Flex or 360|iDev (and you should in any case), come check it out!

We also have a new dedicated site: www.pixelwave.org

Progress update: read more

If you’re using OpenGL, you may have a need to triangulate your polygons in order to draw them.

A common algorithm to do this is the ear clipping algorithm. We’ve been on the search for a solid implementation of this for a while, and have finally found one:

http://www.flipcode.com/archives/Efficient_Polygon_Triangulation.shtml

It’s written in c++ and has no dependencies (except for stl). It was really easy to use, and worked well in our tests.

Sometimes in your macros you need to use a variable, but you can’t scope it to the macro. If you use this macro more than one in the same scope you get a duplicate variable warning.

For example, let’s say this is your macro:

#define LOOP_10_TIMES \
int i = 0; \
for( i = 0; i < 10; ++i)

And this is your implementation:

LOOP_10_TIMES{
	x += i;
}

This is fine, but what happens when you want to use this macro twice? Like so:

LOOP_10_TIMES
	num += i;

LOOP_10_TIMES
	mun += i;

You’re sure to get a nasty error (or at least a warning).
This is because your code now declares the variable ‘i’ twice in the same scope.

So how do we solve this? Our macro needs to create its own unique variable each time and use that instead. This is where the __LINE__ preprocessor directive comes into play

Using __Line__ you can figure out what on what line in the file the call to the macro is located. So if you combine the current line with the name of your variable you can create a unique variable which will never repeat within the same source file twice.

So how do you generate a unique variable? Use this handy code:

#define _LINENAME_CONCAT( _name_, _line_ ) _name_##_line_
#define _LINENAME(_name_, _line_) _LINENAME_CONCAT(_name_,_line_)
#define _UNIQUE_VAR(_name_) _LINENAME(_name_,__LINE__)

You’re probably wondering why this code does in 3 nested calls what it can do with just one… well if you consolidate these three lines into one it just won’t work.. try it out. This works though, I promise.

Ok so now that the hard part is over, here’s how you use it

So here’s a little usage example:

//Note the line that the code is actually on

int _UNIQUE_VAR(myVar) = 5;
int _UNIQUE_VAR(myVar) = 10;
int _UNIQUE_VAR(myVar) = 20;

//This is what the output is

print( myVar3 ); //output: 5
print( myVar4 ); //output: 10
print( myVar5 ); //output: 20

I hope that helps you, it took a while to figure out but it’s definitely useful in a sticky macro situation

Have you ever wanted to call a c function located in one file within a different c++ (.mm / .cpp) file?

If you did, you probably know that it can be a royal pain if you don’t know the trick.
So if like me you’ve been looking for the solution, it’s very easy! Just use the extern “C” keyword (not to be confused with plain extern). Here’s an example:

extern "C" #include "my_c_code.h";

This also works with the Objective-C #import keyword:

extern "C" #import "MyObjCClass.h";

or alternatively for multiple includes

extern "C" {
#include "my_c_code.h"
#include "my_other_c_code.h"
}

And that’s the way you include someone else’s C code into your C++ files. Easy!

But…
If you’re writing brand new C code and you want it to be automatically compatible with other C++ code you can build it in a way that will make it #include’able into any source file.

Using the __cplusplus preprocessor variable you can check if the current build target is a c++ file and if so, surround your code with extern “C”

So for example let’s say this is our current C header file:

//my_c_header.h:

int addOne(int n);
int globalVar;
//..etc

To make this code C++ friendly, we’d do this:

//my_cpp_friendly_c_header.h:

#ifdef __cplusplus
extern "C" {
#endif

int addOne(int n);
int globalVar;
//..etc

#ifdef __cplusplus
}
#endif

Now in your C++ file you can just write

// my_cpp_code.cpp

#include "my_cpp_friendly_c_header.h"

So if you know that your C code will be included into C++ source, it’s always a good idea to wrap it in extern “C” { … } to avoid headaches later on…

More info over at: http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html