Oh man, I just wasted too many hours of my life trying to figure out why calls to glBlitFramebuffer in my iOS app were returning GL_INVALID_OPERATION. I was targeting iOS 7, so I should’ve been able to use OpenGL ES 3.0 calls, and after all, I’d built against the v3 headers and everything else was compiling and working… right?
Wrong. Well, I really should’ve RTFM. It turns out that ES 3.0 use is not determined just by the OS version, but by the hardware. So even if you’re running iOS 7, you can only use ES 3.0 if you’re on the latest gen: iPhone 5S, iPad Air etc. Check out the full compatibility matrix here.
Here are a few extra tips to help you avoid wasting your time like I did if you’re explicitly targeting OpenGL ES 3.0:
As well as running on the right hardware, you can also use the simulator, which supports emulation of v3.0.
Call glGetString(GL_VERSION) to get a report of which version you’re actually running.
Pass the appropriate parameter to EAGLContext initWithAPI, if you’re using it.
It’s pretty frustrating that you get no indication that the function’s not supported, as opposed to just having being passed bad state. But I guess that’s par-for-the-course with a bare-bones, down-to-the-metal API like Open GL.
On my recent iOS puzzler Wordz, I decided not to reinvent the wheel, and instead use an off-the-shelf 2d game framework. I settled on Cocos2d. It makes it very easy to put together sprite-based games or apps by providing all the basic pieces like a scene graph, animations and integration with a couple of physics engines. It’s built on OpenGL but, happily, hides all that away from you – unless you need it.
No sooner had I released it, than Apple came out and announced a new framework for 2d games: SpriteKit. And it’s remarkably similar to Cocos2d. Here I’ll take a look at a few places where they differ, so you know what to look out for if you’re considering migrating to SpriteKit. Continue reading SpriteKit for Cocos2D developers→
Catchy title, eh? This little experiment came about as I’ve been working on an iOS app where I decided to use an embedded OpenGL view, via GLKit, for a bit more flexibility than a plain-old UIView. This found me falling head-first down a rabbit-hole of OpenGL ES shaders. I ended up putting together a little demo that emulates a lava lamp using a nifty bit of GLSL code. Continue reading An iOS Lava Lamp using OpenGL ES shaders→
Well, we’re a few days into 2012 and no armageddon yet, so it’s probably safe to take a quick glance back over our shoulder at some of the technical stuff that’s flashed past in the preceding 12 months. Continue reading Looking back at 2011→
With the success of iOS games like Angry Birds and its flocks of imitators, there are lots of people looking at creating physics-based games, so I decided to try and create a simple demo using OpenGL ES and the Bullet physics engine. Continue reading Creating a physics-based OpenGL iOS app→
Well, the title says it all really. I just wanted to let everyone know that I’m not dead – despite what you may be thinking based on my lack of blog output – it’s just that I’ve been insanely busy on a project in the day job. Yep, it’s that old excuse of real paying work getting in the way of the fun stuff again.
Hopefully soon I’ll manage to post some new stuff, possibly more ‘transitioning to F#’ posts and bit more iOS development malarkey. In the meantime, keep on keeping on.
I’ve recently been experimenting with the Bullet physics library on iOS. It’s a great way of adding 3d collision detection and realistic looking movement to your OpenGL apps and games. I’m working on a full blog post with all the details, but in the meantime, here’s a quick look at what I’ve been doing: a simple 2.5d ragdoll character running on the iPad simulator. Continue reading Sneaky peek: Physics on iOS→