Hi everyone — thank you all for beta testing 1.5. Despite a few bugs, I think it has been a very successful release. A lot of that is down to your great feedback and bug reporting.
So now we’re starting on 1.5.1. This one will be a bug fix update.
This release should fix the setContext() issue (and hopefully the crashing it was causing as well). @Jmv38 could you let me know if this is the case? It seems to fix it for me, but given the random nature of the bug I can’t say for sure.
Thank you for a great release 
On beta 1.5.1(1), I have gone through all my projects, opening, running, closing them. Unfortunately, when I reached one in the ‘Gs’ (about 40-odd projects in) I was presented with the ‘buffering’ icon on top of the project icon on the Codea home page for some time (rather than the project opening) and then Codea crashed. When Codea restarted, the project ran just fine.
parameter.text() shows only one line and some pixels of the next line when starting a script even if the initial text is longer than one line. Text box resizes after first editing action.
@Simeon just installed this new version, but i am sorry to report the bugs are still there: random freeze with mpilgrem tween program, random black screen with my windows program. Both repaired by pressing the top left button. Dont give up, you’re going to bust it!
.@Jmv38 I think I’ve fixed the bug in Beta 2. Please let me know how it goes! I’ll be testing here as well.
.@Simeon - I agree, v1.5 is a corker. Some observations on v1.5.1:
It looks like orientationChanged() now gets called ahead of setup(). This used to happen in Xcode using the runtime but not in Codea. I’m not sure if this is new to 1.5.1 or I just hadn’t noticed it in 1.5. Not a bug and it makes sense to make this consistent with the runtime but probably worth mentioning in the documentation as otherwise it can create bugs which are tricky to track down.
I can’t reproduce the problem that @Jmv38 and @mpilgrem has - but I only have 22 projects…
.@Reefwing I think it might have been introduced in 1.5. I’ll have to think about which behaviour is more “correct”.
Looks like you’ve got it! You are THE BEST !!! What was it? (if not too long to explain?)
It occurred because there was an uninitialised handle in the image class.
In C, unassigned variables just get given the value of whatever is in memory at the time. I had added a depth buffer handle to the image struct in an attempt to get depth rendering in setContext(). I hadn’t finished it, but assumed it was safe to leave the integer handle in the image struct.
On deletion (garbage collection) the image would destroy its frame buffer, if it had one, and also its depth buffer. Because the depth buffer was random memory, this most often resulted in no problems. Very occasionally, the random memory was equal to 1 which was the screen’s framebuffer, which got deleted — which is why rendering “froze” and hiding the sidebar would bring it back.
It was a pretty stupid mistake entirely caused by me. In Objective-C, all memory is zero initialised, but in C this doesn’t happen, so I overlooked the necessity of assigning the depth buffer handle a value of zero on creation.
Beta 3 is going up. Fixes one other large bug involving sprite() caching for explicit widths.
Also restores the swipe-to-move-cursor behaviour of previous versions. Let me know if this interferes with anything.
Would fixing the problem of associating a buffer of Lua numbers with a float attribute of a vertex shader delay the issue of Codea version 1.5.1?
A minor point spotted in the in-app reference: under ‘Watching Expressions’ you have parameter.watch(expression) (which makes sense), but then ‘expression’ becomes ‘name’ on the actual page for ‘parameter.watch’.
I think there is a bug in the parameter logic that filters for existing ‘names’: you cannot watch a variable that is a slider and you cannot create a slider for a variable that is being watched. See, for example:
function setup()
parameter.watch("x")
parameter.number("x")
parameter.number("y")
parameter.watch("y")
parameter.watch("z")
end
function draw() background(0) end
Good to see the cursor swipe functionality back. I’ve become used to this and wish apple would implement it in their apps - particularly Mail.
.@mpilgrem good point on float buffers, we’ll fix them for 1.5.1. There is a uniqueness requirement for all parameters, and since watch is a “parameter” it applies there too. I will look at removing it for watch.
.@Reefwing I had no idea this feature was being used. Glad to put it back in.
I know that version 1.5.1 is not for new features, but could displayMode() return the current displayMode?
May I ask why many of the example shaders also flip the texture about a horizontal axis? It seems odd that the application of even the ‘Basic’ shader to a textured mesh then requires the ‘v’ texture coordinate of that mesh to have to be changed to 1 - v.
For example:
supportedOrientations(LANDSCAPE_ANY)
function setup()
m1 = mesh()
m2 = mesh()
local idx = m1:addRect(WIDTH/4, HEIGHT/2, WIDTH/2, WIDTH/2)
-- Need to flip v to get it to work
local idx = m2:addRect(WIDTH * 3/4, HEIGHT/2, WIDTH/2, -WIDTH/2)
m1.texture = readImage("Cargo Bot:Codea Icon")
m2.texture = readImage("Cargo Bot:Codea Icon")
m2.shader = shader("Filters:Posterize")
m2.shader.gamma = 1
m2.shader.numColors = 3
fill(255)
end
function draw()
background(0)
m1:draw()
m2:draw()
end
Hmm, you’re right that it’s an issue. I’ll have to think carefully about how to resolve it.
There is a reason for it, though, if you change this line of your code:
m2.texture = readImage("Cargo Bot:Codea Icon")
To
m2.texture = "Cargo Bot:Codea Icon"
You’ll notice that the mesh no longer requires flipping.
The reason for this difference is that the “string” textures, or sprite keys, are loaded using the built-in iOS image loader. For some reason the raw data is provided upside down from what OpenGL expects.
Internally we deal with this by detecting, for example, when you are rendering an image versus a string with native calls like sprite. We set the appropriate texture coordinates.
Our image class is the right way up.
Now that we have provided shaders, we have also exposed this inconsistency between image data types to users. I’ve modified Codea 1.5.1 (4) to flip the sprite data when loaded from iOS images, I’ll go through and change all the shader behaviour and release a build tonight.