Weird behavior on iPhone 5

[Etabubu]

Hi,

I'm working on a game using ChipmunkPro (paid), specifically with ObjectiveChipmunk and Cocos2D. Both libraries are up-to-date to the latest version.
The scene is very simple, just a floor and a CCPhysicsSprite positioned initially a few pixels above the floor.
Gravity is set to a "normal" value (objects fall down at kinda realistic speed).
No collision handler is installed. No other modifications to the space or physics parameters have been done.
When I run this on any sim (iPhone Retina 3.5 inches, iPad, iPad retina and iPhone Retina 4 inches 64 bits) everything works as expected: the sprite collides with the floor and settles there.
If I run it on an actual iPad 1, iPad 3, iPad 4 or iPhone 4 device, it works as expected.
The issue appears when I run the same exact build on an iPhone 5S (64 bit): the sprite falls through the floor!
No matter where I put the sprite or if I lower the gravity (so that it falls slower), it will always fall through.
I think this has to be with the static ChipmunkPro library built for 64 bit devices.
I checked with the "lipo" command and it looks like the library contains the arm64 architecture... and I'm a bit lost.
I use the "iphonestatic.command" script to build the static library.

Any idea?

Thx!

Marco

[slembcke]

Hmm. I don't know what would be up with that. It should certainly work fine on 64 bit, I've been using it on x64 for several years now.

Can you verify that it works correctly if you disable building for 64 bit in your executable? An arm7 binary will run just fine as long for now as long as you don't need every last drop of performance out of it.

Sounds like I might need to pick up one of those 64 bit iPad minis... Hrm.

[Etabubu]

I'll do some more tests with 64bit disabled.

Still it's very weird. I push the same archived build to 3 different devices through TestFlight and the only one that fails is the iPhone 5S.

I'll let you know!

Thx,
Marco

[slembcke]

So one potential issue is that Chipmunk on Mac and iOS is configured to use the same floating point types as CoreGraphics. (doubles on 64 bit and floats on 32 bit) cpFloat is an alias for CGFloat and cpVect is an alias for CGPoint.

Does that strike you as something that could be causing the problem? Is there anywhere in your code where you might be using sizeof(float) to store arrays of cpFloats or something like that?

I'm going to pick up a 64 bit device tonight so I can do some actual testing, but this is the first time I've heard of people having issues with Chipmunk on the 64 bit ARM devices.

[Etabubu]

No, I don't think I'm doing anything like that.
But I did another test and while debugging I found out something interesting that might help you.
It looks like the collision is actually detected (so, nothing wrong with collision detection system), but it's then "discarded" by some other piece of code in Chipmunk.
I couldn't really understand what the code was doing (I was deep into cpSpaceStep I think) but I'm wondering if it could have something to do with the bitwise operations you use to filter collisions with cpLayers.

I'd like to remind you also that this only happens when I compile the Pro version using the iphonestatic.command script. If I run the demo apps from the Chipmunk project itself on an iPhone 5S, everything works.

Thanks,
Marco

[slembcke]

Bah. I thought I replied to this on Sunday. I must have closed the post without submitting or something. :-\

I did end up getting a retina mini and was able to test it out. 10 seconds into testing, I had my "Oh crud" moment and knew what the issue was.

"Is there anywhere in your code where you might be using sizeof(float) to store arrays of cpFloats or something like that?" <- This is where I eat my own words, because thats exactly what I was doing in the NEON optimized solver. It might be possible to rewrite it to use doubles, but I wouldn't expect the performance to be very good. It might even be worse than having NEON disabled.

There are a few solutions:
* Configure Chipmunk to always use floats on iOS instead of CG types (see chipmunk_types.h and ObjectiveChipmunk.h). You lose CGPoint <-> cpVect equivalency which is handy. This is the solution I'm strongly leaning towards for Chipmunk 7.
* Disable the NEON solver on arm64. You lose some performance.
* Don't compile for arm64. Probably the most pragmatic solution right now. You don't really lose out on much right now.

[Etabubu]

Hi!

I'm glad you found the issue!
I'm wondering which solution I should go for.
Probably we won't update to Chipmunk 7 or Cocos2D 3.0, so... is anything gonna break if I go for solution number 1?

Thx,
Marco

[slembcke]

I got a bunch farther along with this over the weekend actually. I found a rather serious collision detection bug on arm64 due to the way it handles rounding compared to Intel, PPC, and arm7 causing it to fail certain degenerate triangle checks. I also got a working float64 NEON solver working. Both fixes are for Chipmunk 7, but it should be pretty easy to backport. I guess I'll do a 6.2.2 soon with that in it.

64 bit NEON solver Woo! Yay! Well.. apparently not so much. Remember how I said a 64 bit NEON solver might not actually be any good. Apparently that is true, but not for the reasons I thought. arm64 actually did double the size of the vector registers, so it was a pretty straightforward 1:1 conversion using some macros. The bummer is that on Apple's A7 CPU the NEON code seems to be barely faster than scalar code. On the plus side, scalar code on the A7 is still way faster than the A6 running NEON code.

I made some poorly labeled benchmark graphs if you are interested:
https://docs.google.com/spreadsheet/ccc ... _web#gid=0

Anyway, going forward I'm going to keep CG type compatibility enabled by default since the A7 seems to be able to handle doubles nearly as well, at least up to a certain simulation size. (I would guess it's L1 cache related) If you want to squeeze every last drop of performance out, it looks like using 32 bit floats on the A7 is the way to go. I'll leave the 64 bit NEON solver in and enabled by default even if it doesn't seem to do much right now. I'd be surprised if the A8 didn't come out in a year and implement proper NEON again.

My recommendation for you is just to disable the arm64 build until 6.2.2 due to the collision detection bug. I'm hoping to have some time this weekend again to finish up the Chipmunk 7 docs and finally do a release. I can push 6.2.2 at the same time pretty easily.

[Etabubu]

Interesting stuff!
I'm happy I discovered this issue, now Chipmunk will be even more reliable

I might need your help still...
I'm trying to follow your suggestion of disabling arm64 for the lib, but I'm not sure how.
If I open the ChipmunkPro xcode project (6.2.1) I can see that in the ChipmunkPro target the Architectures field is already set to $(ARCHS_STANDARD_32_BIT) which, I guess, won't include arm64.
The Valid Architectures field is set as "arm64 armv7 armv7s".
I tried to remove the "arm64" from that field, but then the iphonestatic.command script fails saying that it can't find a valid architecture for the Debug configuration.
Same thing if I update the Architectures field with the "Standard architectures armv7 armv7s", the script will fail.
So... yeah... not sure whether I have to touch anything there or not.
And what about my game? Do I have to disable arm64 there as well?

Thx!
Marco

[slembcke]

You should only need to disable arm64 in your game's build. If that isn't built for arm64 it will ignore the extra architectures in the lib.