Thought it might be useful to some members here. The code is for Unity. Might or might not be useful for other environments (the principles probably are, the code not so much). http://mudloop.com/creating-resolution-independent-2d-games/
Oh, Unity. That one carries its own bag of problems. The default tools from the 4.5x version really has issues with letting users select sprites by the pixel from a spritesheet. Which means you might get bizarre effects when trying to achieve true pixel perfect displays. This might be due to the scale of one unit corresponding to a hundred pixels, while we all work with multiples of eight. :/ Some bloke here ran a test btw comparing Unity 2D and MonkeyX and the later came ontop in terms of performance, although the method and details were largely undisclosed. Managing resolutions is a nightmare sometimes, so your article is more than welcome! Once it was argued that developing on iOS made such things easier because of the limited resolutions and screen shapes, but it's not the case anymore. I totally agree on using the Retina as a default. Caring about non-Retina displays is totally moot by now. iPhones 4 are the oldest relevant models, and most of them barely make it to iOS7, and they come with retina. It's especially true if you start a project now. By the time it's completed, iPhone 6's sales will be in full swing and talks of an hypothetical iPhone 6 "deluxe" or iPhone 7 will only be a semester away at best.
It was a member of these forums who did the Monkey X tests. Yes it performs better in certain situations and also assumes you have no interest in any of the features of unity other than the rendering engine. There was a lot of debate on the unity forums about it if anyone is interested I am sure a search there would be easy to find. My recollection was that it was faster but not as much faster as he thought.
Tada! http://forum.unity3d.com/threads/speed-comparison-2d-unity-vs-monkey.248926/ I think I asked him if he had any similar test regarding memory management and the odd mem purge, which I think is equally important, if not more (because his test is really unrealistic,while mem management is extremely relevant to mobile development). Besides, when developing on mobiles, framerates and the occasional hiccup hardly are detrimental to the success of one's app. Customers don't care about FPS and the mini-freezings unless the game is really coded by a bunch of... monkeys. Still, if you're aiming for a quality game with potential for ports and cast on a TV, you may care about the gain in FPS.
I have, but I much prefer working with Unity's default sprite system. I really like the workflow for that, it's fast and works well.
And yeah, Unity is probably not the fastest engine out there and has its problems. But the editor and workflow are amazing, and I love working with it. I don't care about high-end 3D graphics (though it's good at that too). I care about making fun games
It also depends how you define fast! I am sure if you started using the built in functionality all of a sudden it would compare a lot better. The bottom line is it is perfectly fine for 2D games especially with devices getting faster and faster. It was an interesting read. I liked how OP drew all the different resolutions on the screen. This just as applicable for whatever type of game you are making.