just got the freeze with 1.3.1(7). Also removed the calls to SpriteObj.makeSprite so now I should only be using sprites for mesh textures and still got a freeze. Unfortunately I’ll only get to use an ipad1 tonight to test on it.
Will keep digging.
Only noticed the y-axis inversion because of the die. I made an atlas for it and decided that to get the best accuracy, I’d make an image large enough for 8 sides rather than 6, but left two blank. So I was a little surprised when two faces of the die were missing.
(Incidentally, when thinking about atlases for meshes, given that we currently specify textures using decimals, it’s worth ensuring that the components of the atlas lie at places where one can say where they are using a finite decimal, so atlases should consist of a grid of elements with number of rows and columns some multiples of 2 and 5 - if that makes sense.)
New colours are much better. Liking the look a lot.
Thanks for narrowing it down @ruilov. I’m running the binary counting level at the moment after commenting at the start screen and uncommenting level select. Hopefully it freezes so I can see what’s going on.
Simeon, re my codea freezes, I noticed that if I start directly from the level selection screen, they go away (in setup() just uncomment currentScreen = LevelSelect() and comment out currentScreen = StartScreen())
This makes me think that it has something to do with the physics. I tried showing a very simple screen after touching the StartScreen (instead of the usual level select), simply displaying ElapsedTime as a text string, to see if I could catch it freezing, but it didn’t freeze. So it might be something to do with the interaction between the startscreen and something else I’m doing.
Also tried on ipad1 with 5.0.1 iOS and it did freeze, although only towards the second time I played the binary counting level, so it took some time.
Very mysterious.
No crashes so far, and liking the new colours.
There is definitely something funny going on with meshes. Even when I tear down and set up a new mesh for a new shape then I get strange behaviour after doing that a Couple of times - see just-posted picture on Twitter.
Andrew, for mine I’m more suspicious of the physics than meshes at this point. But who knows…
The mesh problem is separate to the crash, by the way.
I’ve narrowed down the mesh rendering issue to using a texture while recording (which is annoying because I have a fun playlist lined up!).
Is the texture created using setContext during the recording?
sorry, I think we had some miscommunication there. If I start directly from the level select screen then it stop freezing. It’s when I start from the StartScreen that it freezes.
@ruilov I’ve managed to play it through many times with the changes you suggested. I can’t seem to cause the freeze here.
So do the opposite of this? “(in setup() just uncomment currentScreen = LevelSelect() and comment out currentScreen = StartScreen())”
Either way it seems to work, though.
Simeon, see my previous comment.
Also do testflight crash reports show anything useful? Anything I can do to make them more useful?
sorry for the confusion. Yes, do the opposite of that.
That was how I got it to stop freezing.
I finally got the freeze.
It’s interesting. It occurs in this stage of the engine
mesh:draw() → update texture
Update texture happens if the mesh needs to draw a texture but the image that is used for the texture has modified data — so it has to rebuild the texture and send it to OpenGL.
It seems that the texture object and image are pretty corrupt at this point.
It’s telling me the image size is 7340144x7471205 (way too huge). It’s also telling me that the texture is something like the 8194th texture allocated.
The first pixel’s colour in the image is (r,g,b,a) → (5, 34, 14, 153)
I was starting to think I was crazy 
I don’t think I update any mesh textures. My textures are sprites, except for a few of the buttons, where I create an image with setContext. I only create the image once and then the mesh from then on. I’ll review the code closer to make sure that’s what’s happening.
Is that the bottom right pixel? I’ll see if I can find the sprite or image that it corresponds too.
It seems to be a corrupt image texture on a mesh (not a sprite texture). It’s definitely our bug. But if it’s easy enough to do: try to disable rendering of meshes where their mesh.texture has been set with an image, rather than a string.
I did try that, but still got freezes. Will do once again to confirm I did it right and send you a new version.
It seems quite intermittent. I have only managed to get the freeze that one time.
I keep playing the solution through over and over again and haven’t seen it since (with the start screen active).
Perhaps something occurs on the start screen that increases the likelihood of the crash later on.
John, yes it is.
@John: confirmed. I added a caching step so that if an image has already been used then it uses that, otherwise recreates it. In the recording then those that were cached render fine but those that were done using setContext (during the recording) were garbled.