I’m getting pretty frequent freezes out of codea now. It could be my code, but it did not throw an exception when i set the instruction limit. Also the codea buttons stop responding.
Not sure how to debug or report this. Is it possible for me to download an ealier beta to see if it still happens?
I was going to post something similar to ruilov’s previous post. The crashes are back in the latest beta, not as bad as in the version where I mentioned it before, though.
I’m also getting some strange behaviour with meshes and textures. In my Cube/3d shape (the name “cube” is getting increasingly inappropriate) project then I reuse the same mesh for the shapes, even when completely changing the shape. This doesn’t always work smoothly especially where textures are involved. Sometimes the texture doesn’t get rendered correctly, and sometimes it persists when I think I’ve disabled it (though that might just be me not blanking all the pieces: texture and texCoords, I’ll have to investigate). Also, I’m finding it hard to render a texture exactly to, say, a rectangle. I seem to be missing the edge - if you look very carefully at my latest pictures on Twitter then you’ll see in the die that the edges aren’t flush, and in the knot then there’s a curious band around the torus (both of these are done with textures).
Oh, and another thing about meshes: the y-coordinate is upside-down. If I define an image and draw on it, then define a mesh and use that image, then I have to invert the y-coordinate. For example:
m = mesh()
m.texture = myimg
m.vertices = {
vec2(100,100),
vec2(200,100),
vec2(200,200),
vec2(100,100),
vec2(100,200),
vec2(200,200)
}
m.texCoords = {
vec2(0,0),
vec2(1,0),
vec2(1,1),
vec2(0,0),
vec2(0,1),
vec2(1,1)
}
draws myimg upside-down (but correct in the left-right direction).
Definitely sounds like something I’ve messed up. Will look into the crashes soon — thanks guys.
The texture stuff sounds odd. So it doesn’t turn off when you set mesh.texture to nil? That’s a bug.
The texCoords issue I suspect has more to do with precision. The highest precision on the iPad GPU is 16 bits per float. So: not very high.
You are completely correct about the y-coordinate being upside down, we’ll change this. I think for setRectTex it works the right way.
Ah, the problem with fitting a texture to a rectangle is to do with drawing on an image. I was filling the background of the image by drawing a rectangle of a single colour on to it. Something like:
img = image(100,100)
setContext(img)
rect(0,0,100,100)
But that doesn’t quite work. It seems that that doesn’t actually draw a rectangle of side length 100 but rather it draws a rectangle which is guaranteed to be at most side length 100, but perhaps a little less. So I wasn’t actually filling the whole image but leaving a pixel or so along some sides, which becomes noticeable when magnified and distorted on a mesh. Solution: draw a bigger rectangle. Now the die and torus knot look much better.
I’ll upload new pictures, but just checked and you can quite clearly see the missing pixels on the old ones:
The dark band around the torus at just anti-clockwise from the top is what I’m talking about in this one.
The vertical line between the four and six is half-white, half-black. That’s because it is wholly not there and what you’re seeing is the faces behind.
Perhaps it was because the rectangle was drawn with smooth() enabled, which performs some smoothing of the edges. With noSmooth() do the seams still occur?
@ruilov it seems your crashes are occurring in an image update when you are rendering a mesh. That is: you are rendering a mesh that is using an image that is being updated every so often?
So it doesn’t turn off when you set mesh.texture to nil?
I think this was what I wasn’t doing. I’ve now set it to do that on changing shape and it’s now working as I expect (sort of … something weird is happening when I go from a shape with a texture to one without, but I’ll investigate a bit).
I was seeing some very strange effects, though, when reusing a mesh. Again, it might have been due to me not clearing things properly, but there did seem to be some stuff persisting, even between successive runs of a program. I can’t reproduce it now, but if I do I’ll take a screenshot.
It sounds like there are some state bugs in mesh. I’ll have a look for them.
@Simeon: Yes, adding noSmooth fixes it. Great!
And the problem with the vanishing meshes was that I wasn’t setting texCoords to nil in between.
Strikes me that it might be worth having a mesh:reset() function that blanks everything. Especially if one has used the rects to define the mesh, one might not know all that needs to be blanked.
Which gets me onto something I was wondering: I’m reusing a mesh here, but every frame then I reset its vertices (because I recompute their positions). How much am I saving by reusing the mesh? That’s a two-part question because sometimes I’m using a texture (which doesn’t change, though the texCoords does because it has to keep step with the vertices) and sometimes colours (which do change). So sometimes I’m essentially completely redefining the mesh every frame, and others I’m redefining it all except for the texture. Is there a significant benefit to reuse, or would I not notice if I had a new mesh every time? (Might be memory penalties here as all those meshes wouldn’t be garbage collected every frame.)
mesh:reset() is a good idea.
Here’s a breakdown of where performance differs between mesh and sprite.
Mesh, going from Lua code to GPU
Vertices defined in Lua -[set]-> Copied into internal buffer -[draw]-> Copied into GPU memory
Sprite, going from Lua code to GPU
Parameters defined in Lua -[draw]-> 6 Vertices computed internally and copied into GPU memory
The main difference between mesh and sprite is that mesh can submit batches of more than 6 vertices at a time. The biggest overhead comes from moving data from main memory to the GPU. The more often you do this, the slower things get.
If you want to draw 5000 sprites, for example, we do the following 5000 times:
Allocate 6 vertices (+ texture coords), submit 6 vertices to GPU, draw
If you do the same with 5000 quads in a mesh, then we do this once:
Copy 5000 * 6 vertices to GPU, draw
We’re looking at making some modifications to mesh so we can do the following:
Create your vertices in Lua, copy them into a mesh. The mesh creates a write-only buffer in GPU memory and keeps a pointer to the GPU memory. It then exposes a special vertex array object to your Lua code. You can manipulate the vertices individually without having to copy the whole set and they change directly in GPU memory. So there is no copy step when you draw the mesh.
@Andrew I’ve fixed your crash (but not @ruilov’s which appears to be a bit different).
I’ve also fixed the inverted-Y texture coordinate problem. Hopefully this won’t mean too many changes to your code.
Simeon indeed i’ve added functionality to draw an image with setcontext and then i use that as the texture of a mesh. I didnt think the image was ever updated though, i thought i created it once and that was it.
Code that does is in the Layout.makeStepButton in the code i sent you last night
Edit: and SpriteObj.makeSprite in the Utils tab
Thanks @ruilov. I’ve been testing your code on my iPad 1 but have yet to experience the crash. Will look into those two areas.
I did notice the physics slow down on the title screen. It happens after 10 seconds or so on iPad 1 then eventually speeds up again.
Just play the count in binary level and it will usually eventually freeze (i’m on ipad 2, will try on ipad1 now)
It’s still playing out, no freeze yet. It may be fixed. A new build (7) is being uploaded and should definitely fix @Andrew’s bug — and hopefully also your freezing issue.
It played through without issues in 1.3.1 (7). Took longer to play through than to upload the build 
I don’t know how you even managed to build a puzzle so difficult.
I’ve also improved the comment brightness. (And the inactive tab text brightness for @Andrew_Stacey)
I didnt want it to be difficult, i wanted to count in binary and difficulty wasnt going to stop me!