Demystifying bridged cast in Objective-C

Recently as I was developing my 2D game engine on iOS, there was a need to use STL as I didn't really want to reinvent the wheel in Objective-C, especially since it's going to be phased out by Apple in favor of Swift. Inevitably I had to do some sort of casting between both worlds. The best description I came across was this one : Here , which is quite close but not very comprehensive. Now, if you don't believe me, test your knowledge by answering the questions

    id obj = [[NSObject alloc] init];
    CFTypeRef ref = (__bridge_retained CFTypeRef) obj;
    NSLog(@"CF Retain Count %ld", CFGetRetainCount(ref)); //Q1
    CFRetain(ref);
    id obj2 = (__bridge_transfer id)ref;
    ref = (__bridge_retained CFTypeRef)obj2;
    NSLog(@"CF Retain Count %ld", CFGetRetainCount(ref)); //Q2
    id obj3 = obj;
    NSLog(@"CF Retain Count %ld", CFGetRetainCount(ref)); //Q3
    id obj4 = (__bridge id)ref;
    NSLog(@"CF Retain Count %ld", CFGetRetainCount(ref)); //Q4
    //Q5 : How many CFRelease/CFBridgingRelease do we need here to release the object when it goes out of scope?

If you can't answer those, my hint is, there is indeed only 1 reference count in ObjC, whether you use the bridged cast or not.
See the cheat sheet below:
__bridge_retained = CFBridgingRetain = CFRetain + casting
__bridge_transfer = CFBridgingRelease = CFRelease + casting
__bridge : Does nothing other than casting

Unnamed 2D game engine

It has been so long since my last post, partly due to the fact that I have a very boring/tedious day job. It's hardly any excuse though, because everyone has weekends and tons of free time after work. So immediately after participation in GGJ 2013@UC Santa Cruz with our game (done in Unity) voted as the best, I did a lot of research on the existing 2D game engines only to be frustrated. Unity3D only handles 2D sprites well when you buy the 2D Toolkit, which I did. Even so, it just doesn't quite fit into the Unity pipeline, because what you see is usually not what you get. On top of that, the text system is even more frustrating. The problem with Unity3D is that, even though the learning curve is pretty flat in the beginning, you need to buy lots of modules from their asset store(that's how they make money). Since building a 2D game engine is relatively easy (compared to 3D), and I'm too picky about APIs(flixel, cocos2d...etc.), I started building everything from scratch in OpenGL ES. After just a few months, I'm making a lot of progress, given how little time I have spent on it:

It's a difficult decision to make whether I should prioritize the cross-platform capability and port the code base to Android, or instead develop a complete toolchain plus the scripting engine, with both being quite important. But for now I'm just going to enjoy game development with my own API, which many people don't have the luxury of.

Model Viewer in WebGL

As HTML5/WebGL was picking up some momentum earlier this year, I started experimenting with it, naively thinking that it would be the new standard for browser gaming. Little by little I added some code to the small project whenever I remembered it. However it has been sitting on the back burner for a few months without any update. Now that Flash 11 has been release, it's finally time to part with this little project, which could be viewed with Firefox (not guaranteed with any other browsers). External Link Here

Usage: AWSD to move the camera and mouse drag to rotate it.

How it is done:
First I found an open source linear-algebra library called glMatrix.js, which serves as the foundation to all math done here. JSON is a no-brainer for the mesh format because Javascript supports it natively. Pretty much everything else is built from scratch, for example shaders.

A few reasons that HTML5 might not be very feasible for gaming:
1. Lacks a comprehensive IDE for development such as Flash Builder, and thus
auto-completion and spelling check(in Javascript spelling something wrong is fatal)
2. Cross-browser compatibility has a huge question mark(it's still called experimental-webgl), with IE falling behind.
3. Performance concerns. Flash is compiled while Javascript is not, and how(if any) the browsers speed up this is totally up to them.
4. Javascript as a language sucks.

Added May/7/2012

Let's see how Epic's Tim Sweeney sees Adobe Flash and HTML5:

So what about the browser? That's something that relates more to something specific that you guys are working on with Unreal Engine. Where do you see the future of the browser in games?

TS: Well, we would like to see the web browser as another platform. You should be able to take any game -- a PlayStation 3 or iOS game, for example -- and just go to that and play it from any web browser.
We're slowly heading in that direction as an industry. One thing that's happened recently is Adobe Flash. For a decade or more, Adobe Flash was a little scripting language for creating more interactive webpages using a proprietary browser plug-in, but more recently Adobe created a translator.
You give it any C++ program, like Unreal Engine 3, and it translates it to a platform-independent application that can run within Flash, within any web browser or on any platform where Flash runs.

And so now any browser that supports Flash can play any web game that's built with Unreal Engine 3, or any other engine that's cross-compatible with Flash. That's an awesome breakthrough; it shows you the possibilities.

But I think the next step in that is cross-compiling games from C++ or whatever and directly running them as native HTML5 and JavaScript applications within any standard web browser. And you can do that in theory today, but it ends up being slow and unstable just because of the early state of JavaScript implementations, and limited performance, and current web browsers.
In another few years, I think that's going to be a very realistic scenario. And so the web will generally be a platform, and you can have a real application with a full feature set that runs within a web browser; that'll be very welcome. The web is a fairly awkward experience when you use a platform that's not the majority of the install base, and I think we're going to see big improvements