Do calls to touched() and collide() happen on the same thread as the draw() call in Codea? I’m seeing some non-deterministic bugs in my code that seem to happen when there are lots of physics bodies hitting each other, and was wondering if I need to worry about access to meshes etc from multiple threads. (it is of course totally plausible that I’ve causing this problem in a less esoteric manner, was just curious about the threading model in Codea)
.@bm212 it’s all on the same thread, but touched() and collide() can happen out of the context of draw().
That is, before draw() is called, some setup is done relating to styles, transforms, OpenGL configuration. After it is called, some cleanup is done. touched() and collide() call outside of this context — but in the same thread.
I wonder if it is threaded at all. Everything should be processed in a well defined order (by intuition and by peeking into the 1.4.x runtime). You’d better add some code to your functions to assert this for yourself.
I’m glad it is all happening on the same thread (@Codeslinger: agree that would be the “right” way to do it). Now I need to figure out what I’ve done wrong… @Simeon: would modifying a mesh (e.g calling setRect) from touched() be potentially problematic due to the opengl cleanup that you mention?
Hmm no, mesh setRect should be valid anywhere.
touched() and collide() can potentially be called multiple times per draw() call. Could it be an issue relating to that?
Possibly I guess, I’ll have to dig. Thanks for the help as ever (and of course for making something as fantastic as Codea in the first place - it gets better and better with every release!)
I think the problem is that I have a vertex shader with a uniform vec4 array. If I make the array too big (not sure what the maximum size is but it seems to be between 64 and 128) I start seeing unpredictable outcomes (occasional graphics glitches and crashes).
.@bm212 do you need an element per-vertex? In that case an attribute would be better to use than a uniform array.
Edit: Some more reading suggests that uniform arrays count towards the maximum number of uniforms (GL_MAX_UNIFORM_LOCATIONS) available in GLSL ES. So you are probably hitting the GLSL ES uniform limit.
I’ve got a set of sprites which I’m representing as polygons in a mesh. I have one array element per sprite (not per vertex) and the vertex shader applies an offset to the polygon coords based on the vec2 array value (indexed by the z coord which I don’t need as I’m working in 2d). The thinking here is I can position my sprite centre by changing the vec2 held in the uniform array and have the vertex shader adjust the coordinates faster than the CPU could do it.
I think you’re right re the uniform limit; I think when I exceeded it I started seeing the effects of memory corruption.