April 2, 2012 by Sensei
Like most iOS developers, I’ve expressed my fair share of rants on the App Store’s discovery woes. I remain hopeful that their acquisition of Chomp could lead to some very interesting/rewarding solutions. In the meantime, however, I’d like to toss out one idea into the mixer that would not require any UI overhauls and I believe would make a drastic difference.
Its a simple feature request: I would like to be able to hide apps from the results. Currently, when I load up the top 25 I’d say over 90% of the results are things I am not interested in. Similar to when I check my mail, I would like to be able to do a swipe gesture on apps in the list and have a red hide button appear over their title. Clicking on the hide button would have a similar result to archiving a read e-mail. The email will no longer appear in my inbox but I can still find it if I search for it. In the case of apps, anything I hide would not appear in my top 25, but I could still find them if I searched. Thus, I could hide all of the apps I own (I believe gizmodo suggested filtering apps you own from the list) and then I could also hide apps I see day in and day out that I know I will never buy.
By adding this simple feature the Top 25 quickly becomes MY top 25. I will be exposed to many more apps and thus will most likely be making more purchases. Apple will most likely see more diversity and healthier numbers in their top 100 as a result.
June 13, 2011 by Sensei
Taking the magic out of compilation gives me a lot of peace of mind. Sometimes there can be some really confusing behavior when it comes to static libraries. Its important to use the tools XCode gives you to get clues to solve your problems. Verifying the steps XCode is taking to create your application provides a much deeper understanding of the compilation process. Here are some tips to help out with linking, build products, and static libraries.
June 10, 2011 by Sensei
Much, much, much has been written on the various processes available to get static libraries to function in XCode. But somehow, these all seemed to have problems for me, in many different ways. In my journey to getting static libraries working I tried all kinds of weird things, and in the end, I think I have something that functions as expected. I have created a sample workspace that illustrates how to set up an ios and osx application that each use two versions of a static library. This entry details the hoops jumped through, and gotchas to avoid.
May 13, 2011 by Sensei
Things have been quiet on the blog front, mainly because we’re busy working on stuff that we can’t talk about. One thing that I have been researching though is protocols and serialization. I’ve had a few conversations about all the various formats out there, and I wanted to talk about a great tech: AMF.
For purposes of this post, I’m going to use the term ‘protocol’ loosely. A protocol to me can mean many things: serialization, deserialization, messages, gateways, code generation, etc. Yes, I know AMF isn’t technically a protocol. Please forgive me, purists.
April 15, 2011 by Sensei
I have received feedback regarding my tests that my numbers were totally off. Michael Perry from Garage Games took time out and ran my tests…and he measured 49fps to my 1fps! Michael was able to get a couple of the people on Garage Games IRC to reproduce his results, meaning we had multiple confirmed reports of 49fps.
April 12, 2011 by Sensei
The performance ‘ceiling’ of a scripting language needs to be high enough to allow for a game designer to express his or her creativity. The more a designer can do in their sandbox, the better the final game. Its important to find that balance, where the big and hard stuff exists in C, and the creativity and fun is expressed in script. Ansca Mobile is a prime example of a company who’s found that balance, and shown that you can do a LOT with a scripting language!
A bit of debate occurred over on the Garage Games forum regarding the unrealistic nature of my second part of the iTorque2D vs. Cocos2D performance tests. The gist is that I shouldn’t be doing what I’m doing with TorqueScript. I should be taking anything ‘related to performance’ and re-writing them in C. I disagreed in the forum:
April 11, 2011 by Sensei
I have just completed documenting and comparing the rendering subsystems of iTorque2D and Cocos2D. What started as a complex foray into graphics performance optimization took some adventurous twists and turns.
Phase 1: Rendering
Rendering systems can’t really be that different, and as such, there isn’t anything major I can say that is different between the two. They both have scene graphs, they both sort the scenes to be displayed. Each iterates over its children and renders the objects using OpenGL. Most of the openGL calls are nearly identical.
So what causes one rendering system to run 100 sprites at 1fps, and the other at 60fps, if they are both so similar?
April 7, 2011 by Sensei
One of the more confusing areas of development for iOS a developer may come across is PowerVR Texture Compression (PVRTC).
What is it?
PowerVR Texture Compression is a great technology developed by Imagination Technologies. They make the graphics chips in Apple’s iOS devices, and the chips come with this technology along with many others. Uncompressed images are big. Images, normally, must be uncompressed to be used on your graphics card. So a 512×512 jpg on your computer may only take up 100KB on your hard drive, when you display it, it takes up about 1 Megabyte of space in your video card.
Think of PVRTC as jpg for your video card. Instead of uncompressing that jpeg and sending a megabyte over to your video card, you can take a .pvr image and send it over, and it does not need to be uncompressed. PVR compressed images have a very specific, fixed compression. They can either be 4-bit, or 2-bit. 4-bit images take up 1/8th of the space of an uncompressed image, and 2-bit images take up only 1/16th.
April 6, 2011 by Sensei
Over the past few days I have been determining the performance of iTorque2D, the game engine we are currently using to build our games. Our criteria for picking a game engine was broad, and we knew when we chose iTorque2D that performance would very possibly be an issue.
In order for me to correctly determine the potential performance on the platform, I created basic tests in both iTorque2D and Cocos2D. I chose Cocos2D because it is a good bar for performance on the iOS platform. They also already have some performance tests which are quite useful.
To put it plainly, Cocos2D blows iTorque2D out of the water when it comes to graphics performance. These tests were run on a first generation iPad.