code cleanup, bug fixes and a few additions

[racarone]

There's a lot of fixes in the past few pulls, but look at the last one specifically. I moved some code from my mac branch to the master. I removed the GLKKit view and view controller dependencies. It's using a custom view and display link class (based on sprite kits). I don't think there is a performance benefit per se, but there is a definitely a huge stabilization in frame rate. Things run much smoother, as an example run the Benchmark and watch how much longer it runs before dropping out. ~8150 objects @ 60fps on my iPhone4.

[PrimaryFeather]

Note to myself: as a first step, cherry-picked the following commits:

5a074d6 added "destroyBuffers" so quad batch doesn't destroy every time capacity is changed
b959601 fixed some project warnings
c1011ed fixed texture cache bug
c86de3b more hash fixes, changed "allocWithZone:" to "alloc"
30a759c 64 bit fixes
8e7db83 hashing improvements
1a0e395 formatting
8ca0d15 texture cache now uses global flag
10534c7 "isEqual:" fixes and changed "isEquivalent:" to "isEqualToX:"
4663779 minor optimizations to SPMatrix, SPPoint, SPRectangle
d855c2d added very simple texture cache using NSCache, added format and mipmaps property to SPTexture
ab6f269 fixed SPContext bug, would crash if context was nil
f840a85 changed SPContext extension to (Internal) category
6dd2bc4 changed SPTextureFormat to NS_ENUM
a640263 added isEqual: to SPPoint, SPRectangle and SPMatrix, added and hash methods to SPPoint and SPRectangle
a60edda fixed misspellings
2bd9775 slightly more readability with GLKVector2, small texture transform optimization
be29c23 fixed imports for unit tests
a14f570 code reorganization, more coherent ordering of methods and extensive use of pragma marks

[PrimaryFeather]

By merging everything except those three last commits, the benchmark now results in roughly more than 7k objects @ 30 fps (with benchmark objects scaled down to 25%) on my iPhone 4S. Last time I checked, I was a tiny bit below 6k objects. So that's already an amazing speed-up!!! =)

That said, I guess you talk about your iPhone 5, not 4, right? Because even with the latest changes, my 4S achieves "only" about 7800 objects @ 30 fps; Compared to your results with 60 fps, that seems unrealistic. ;-)

In any case, I think for Sparrow 2.1, I think that's how far we should go! I'd postpone that view controller change after the 2.1 release, since it doesn't add any new functionality. Except there's a reason you want to add it to 2.1 already — to make some things simpler for you? Just let me know!

Otherwise, I'd close this pull request and would prefer to merge those changes later in a separate one. And I'd make the current version a release candidate for people to try out.

[racarone]

Hah yes, my iPhone 5 not 4 =). The view / view controller change was mainly to make transitioning to a Mac compatible version of Sparrow simpler, but in the end it actually helped the rendering loop. With GLKit my iPhone5 runs the benchmark around ~6500 objects @ 60 or ~12500 @ 30 and with the replacement view controller it's running at ~8150 @ 60 or ~14000 @ 30. That's quite the jump.

I'm still not completely sure why GLKit is so much different, but I think it might just be keeping the frame-rate more stable which allows the benchmark to run longer. I don't mind if you want to separate this out into another pull request, but it does seem to be working quite well while also narrowing down the iOS dependencies.

[PrimaryFeather]

That performance difference is really amazing — I'd never have expected that. What's happening inside GLKViewController that would cost so much speed ...?!

I hope I'm not asking too much, but could you perhaps really create a separate pull request with that change? In this one, it's somehow split up in the "format fix" change (I think you meant that to be only a fix in the texture class, right?) and the last commit.

Then I'd just add the "touchID" commit from this one (beside the other two, that's the last missing commit from this pull request), and get the rest from the new one.

[PrimaryFeather]

Cherry-Picked commit 644c314, as well.

[racarone]

That performance difference is really amazing — I'd never have expected that. What's happening inside GLKViewController that would cost so much speed ...?!

Ya I still haven't figure out exactly what's going on lol.

I hope I'm not asking too much, but could you perhaps really create a separate pull request with that change? In this one, it's somehow split up in the "format fix" change (I think you meant that to be only a fix in the texture class, right?) and the last commit.

Oh oops, definitely fudged that "format fix" commit. Ya no problem, i'll go ahead and start a new pull request.