C/C++
Say hi to Pixelwave for the iPhone
Feb 17th
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
Polygon Triangulation
Feb 8th
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.
Creating unique variables within your preprocessor macros
Dec 1st
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.
Calling C functions in your C++ code
Oct 20th
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


