#### Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

# Codea 2.3.2 Beta

• Mod
Posts: 2,020

@Simeon

I know the `ellipse` command uses the ellipse shader that comes with Codea, could I ask you whether you can share the shader for `rect` (if it's not already online somewhere)? I'm curious to compare how they do their aliasing.

• Mod
edited October 2015 Posts: 3,295

Sorry if i am outdated here, but can you access your CODEA files via itume? apparently i cant...I've just connected to itune and i cant copy my work on my mac. Is this solved yet? Is it planned?

• Mod
Posts: 8,396

iTunes now shows all of the Codea projects. You can access them to create backups.

• Mod
Posts: 8,396

@Simeon I haven't been able to figure this out. I'm not sure why similar polygons act differently just because they're rotated at different angles. The 1st two polygons go thru the floor to different depths, while the 3rd polygon, which is 1 degree different from the 2nd polygon works OK. This was also a problem in the last release.

``````displayMode(FULLSCREEN)

-- 3 polygons created with the same number of points the same way.
-- 1st polygon creates an arc from 0 to 90 degrees.
-- 2nd polygon creates an arc from 45 to 135 degrees.
-- 3rd polygon creates an arc from 46 to 136 degrees.
-- 1st and 2nd polygons go thru the floor to different levels.
-- 3rd polygon which is 1 degree different from the 2nd polygon works OK.

function setup()
e1=physics.body(EDGE,vec2(0,200),vec2(WIDTH,200))

tab={vec2(0,0)} -- create table of points for first polygon
for z=0,90 do   -- create arc from 0 to 90 degrees
table.insert(tab,vec2(x,y))
end

s1=physics.body(POLYGON,unpack(tab))
s1.x=WIDTH/2-250
s1.y=250
s1.bullet=true

tab={vec2(0,0)} -- create table of points for second polygon
for z=45,135 do -- create arc from 45 to 135 degrees
table.insert(tab,vec2(x,y))
end

s2=physics.body(POLYGON,unpack(tab))
s2.x=WIDTH/2
s2.y=250
s2.bullet=true

tab={vec2(0,0)} -- create table of points for third polygon
for z=46,136 do -- only 1 degree different from second polygon
table.insert(tab,vec2(x,y))
end

s3=physics.body(POLYGON,unpack(tab))
s3.x=WIDTH/2+250
s3.y=250
s3.bullet=true
end

function draw()
background(40, 40, 50)
fill(255)
text("1st and 2nd polygons go thru the floor to different levels.",WIDTH/2,HEIGHT-100)
text("3rd polygon works OK.",WIDTH/2,HEIGHT-150)
text("WHY?",WIDTH/2,HEIGHT-200)
text("They're the same, just different rotations.",WIDTH/2,HEIGHT-250)
stroke(255)
strokeWidth(2)

line(0,200,WIDTH,200)   -- draw floor

pushMatrix()
translate(s1.x,s1.y)
rotate(s1.angle)
p=s1.points
j=#p
for z=1,#p do   -- draw first polygon
line(p[j].x,p[j].y,p[z].x,p[z].y)
j=z
end
popMatrix()

pushMatrix()
translate(s2.x,s2.y)
rotate(s2.angle)
p=s2.points
j=#p
for z=1,#p do   -- draw second polygon
line(p[j].x,p[j].y,p[z].x,p[z].y)
j=z
end
popMatrix()

pushMatrix()
translate(s3.x,s3.y)
rotate(s3.angle)
p=s3.points
j=#p
for z=1,#p do   -- draw third polygon
line(p[j].x,p[j].y,p[z].x,p[z].y)
j=z
end
popMatrix()
end
``````
• Mod
Posts: 3,295

thank you @Dave1707

• Mod
Posts: 8,396

@Simeon Here's a variation of the above program. It uses the same polygon, but you change the starting angle of the polygon with a tap of the screen. The polygon falls thru the floor with the following start angles.

``````0,7,13,17,20,22,31,33,45,50,57,59,60,66,70,77,83,84,90
``````
``````function setup()
ang=0
e1=physics.body(EDGE,vec2(0,200),vec2(WIDTH,200))
setup2()
end

function setup2()
if s1~=nil then
s1:destroy()
s1=nil
end
tab={vec2(0,0)}   -- create table of points for first polygon
for z=ang,ang+90 do   -- create arc of 90 degrees with different starts
table.insert(tab,vec2(x,y))
end
s1=physics.body(POLYGON,unpack(tab))
s1.x=WIDTH/2
s1.y=350
s1.bullet=true
end

function draw()
background(40, 40, 50)
fill(255)
text("Starting angle  "..ang,WIDTH/2,HEIGHT-100)
text("Tap screen for next starting angle",WIDTH/2,HEIGHT-200)
stroke(255)
strokeWidth(2)
line(0,200,WIDTH,200)   -- draw floor
pushMatrix()
translate(s1.x,s1.y)
rotate(s1.angle)
p=s1.points
j=#p
for z=1,#p do   -- draw polygon
line(p[j].x,p[j].y,p[z].x,p[z].y)
j=z
end
popMatrix()
end

function touched(t)
if t.state==BEGAN then
ang=ang+1
setup2()
end
end
``````
• Mod
Posts: 2,020

@dave1707 add a step to the for loop and the bodies no longer fall through the floor `for z=ang,ang+90,5 do`

• Mod
Posts: 8,396

@yojimbo2000 I know about that. In one of my original programs that I was using to try and figure out what's happening, I was doing step values that divided evenly into 90, that is step 1,2,3,5,...,45,90. Those all seemed to work except when I used the step of 1. That's when I tried different rotations and the 2 programs above are a result of that. From what I see in the above programs, even though I create the points for the polygon (I use the physics points table to draw the polygon), all of them don't seem to be used for the collision allowing the polygon to fall part way through the floor. I'm not sure why some angles work OK, and some don't. Since I don't have the actual collision code, I can't see what's happening, so this is about as far as I can go.

• Posts: 1,976

When you search for a project in Codea via spotlight seach, tap on it in spotlight search to open it in Codea, and run it, you don't have access to the project's assets ("Project:Icon", for example), it instead returns the error `Invalid sprite pack name`. Also, if you take a screenshot with the camera icon while the app is running and choose "set icon," nothing happens.

• Mod
Posts: 8,396

@yojimbo2000 I also noticed this in my program that showed the rolling ellipse. Even though the points that I calculated for the ellipse plotted OK, when I rolled the ellipse, there were flat spots. Depending on the step value I used for the calculations, the ellipse rolled OK for some step values, but dipped into the floor for other step values.

Posts: 5,364

@SkyTheCoder good find, will fix.

@dave1707 looking into it, though it sounds like it might be an issue regarding edge cases in Box2D.

Posts: 5,364

@yojimbo2000 these are the basic rect shaders for Codea. They are split up and selected by the runtime based on style conditions.

• Mod
edited October 2015 Posts: 2,020

@Simeon thanks for the rect shaders. I've done a bit of testing with standard derivatives, but I think you'd need to make the rect out of 4 triangles instead of 2, so it's probably only useful in special cases. I'll post a separate thread if I get anything that's presentable.

Thanks for working on adding matrices to mesh buffers! (Ticket: https://bitbucket.org/TwoLivesLeft/core/issues/373/allow-mesh-buffers-ie-vertex-attributes-in ). As requested, here's a very short sample. Unfortunately, I can't get it to work, it crashes Codea:

Edit: fixed 2nd test

``````--# Test2
-- Matrix Mesh Buffer Test

function setup()
m = mesh()
m:setColors(color(255,200,0))

dummy = m:buffer("dummy") --test vec4 attribute
transform = m:buffer("transform") --test mat4 attribute

for i=1,m.size do
dummy[i] = vec4(60,0,0,0) --works, moves rectangle to right
transform[i] = matrix(0,0,0,0,
0,1,0,1, --use second row of matrix to set color
0,0,0,0,
0,0,0,0)
end

end

function draw()
background(40, 40, 50)
perspective()
camera(0,0,400, 0,0,0)

m:draw()
end

vert=[[
uniform mat4 modelViewProjection;

attribute mat4 transform;
attribute vec4 position;
attribute vec4 color;
attribute vec4 dummy;

varying lowp vec4 vColor;

void main()
{
vColor = transform[1]; //GLES mat4s are indexed in two dimensions, and rows return as vec4s
gl_Position = modelViewProjection * (position + dummy);
}
]]

frag=[[

varying lowp vec4 vColor;

void main()
{
gl_FragColor = vColor;
}
]]

--# Main
-- Matrix Mesh Buffer Test

function setup()
m = mesh()
m:setColors(color(255,200,0))

dummy = m:buffer("dummy") --test vec4 attribute
transform = m:buffer("transform") --test mat4 attribute
local mat = matrix():translate(0,100,0) --should move rectangle up
for i=1,m.size do
dummy[i] = vec4(60,0,0,0) --works, moves rectangle to right
transform[i] = mat
end

end

function draw()
background(40, 40, 50)
perspective()
camera(0,0,400, 0,0,0)

m:draw()
end

vert=[[
uniform mat4 modelViewProjection;

attribute mat4 transform;
attribute vec4 position;
attribute vec4 color;
attribute vec4 dummy;

varying lowp vec4 vColor;

void main()
{
vColor = color;
gl_Position = modelViewProjection * (transform * position + dummy);
}
]]

frag=[[

varying lowp vec4 vColor;

void main()
{
gl_FragColor = vColor;
}
]]

``````
• Mod
Posts: 2,020

I added a 2nd test. This one is meant to set the colour to the second column of an identity matrix (so it should come out green), but it appears black, suggesting the attribute contains 16 zero values?

Posts: 5,364

@yojimbo2000 excellent, thanks for the test case. Not surprised there are issues — I haven't had a chance to test this matrix branch yet.

• Mod
Posts: 2,020

One thing to watch out for is that there are only 16 attribute slots, and a mat4 takes up 4 of them.

Posts: 5,364

@yojimbo2000 thanks, your example is pretty helpful. I'll try have it working by next release.

Posts: 5,364

@yojimbo2000 I think I have it fixed. New build coming.

• Mod
Posts: 2,020

• Mod
Posts: 8,396

@Simeon Version 53. Looks like the keyboard with the orientation change is fixed. Keying `print` then pressing `()""` hasn't changed. Still have to pause after typing `print` before pressing `()""`.

• Posts: 489

My test project system works by having a test library full of one tab projects. The test project has some code that loads and saves its Main tab into the test library. So when I specify a new project, it looks for that project in the test library and copies it across to the Main tab, and also saves the current Main tab into the test library.

The code is working, but crashes Codea once it is done.

Here's the switching code (not to be put in the Main tab, but must be executed after it):

``````-- Current Test

-- name of current project, change this to load a new one
local project="ChordBoard"
-- name of test library where the saved projects are located
local library="Test Library"
-- name of this project
local this="A Test Project"

-- save the current setup function
local __setup = setup or function() end
function setup()
-- if no project is specified, list all available projects; this works fine
if not project or project == "" then
displayMode(STANDARD)
local tabs = listProjectTabs(library)
table.sort(tabs)
print(table.concat(tabs,"\n"))
draw = function() end
else
-- the current project gets saved in project data so we know where to save the current Main tab
-- is the new project different to the old one?
if project ~= cproject then
displayMode(STANDARD)
local tab,msg
msg = {}
-- If we have an old project, save it in the library
if cproject and cproject ~= "" then
saveProjectTab(string.format("%s:%s",library,cproject),tab)
table.insert(msg,string.format("%s saved\n",cproject))
end
-- To find the new project, we look through the list of tabs
-- (Don't remember why I did it this way, it made sense at the time)
local tabs = listProjectTabs(library)
tab = nil
for k,v in ipairs(tabs) do
if v == project then
end
end
-- If we loaded a tab, save it in the Main tab of this project
if tab then
saveProjectTab(string.format("%s:Main",this),tab)
saveProjectData("project",project)
else
-- If not, we put a blankish template in place
saveProjectTab(string.format("%s:Main",this), string.format("-- %s",project))
saveProjectData("project",project)
end
-- Display the accumulated messages
print(table.concat(msg,"\n"))
-- Don't run anything when we're swapping tabs
draw = function() end
else
__setup()
end
end
end
``````

I've put various breakpoints in the code (using project data) and seen that it is running the entire code. However, once it is finished then Codea crashes.

This is new in the beta. It works fine in the official version of Codea.

Posts: 5,364

@LoopSpace is it just the switching code that causes the crash? Or only when you run it with your actual projects? I'll give it a try if the former.

• Mod
edited October 2015 Posts: 2,020

Cool, matrix attributes seem to be working in the latest build! I've updated the test code above so that test2 works.

@Simeon do you know whether the second half of the mesh matrix ticket is possible, having a uniform array of matrices ? eg

`uniform mat4 matrixArray[20];`

I must admit, the GLES SL 1.0 spec is a bit vague about whether this is possible (and I haven't found out much by googling either), just saying that "all types can be arrays"

• edited October 2015 Posts: 1,255

Don't know if this has happened to anyone else, but on 54 I've opened tabs a few times and found that font size has gone rather wild, with some lines in itty bitty and others at screaming headline size. Fortunately, when I touch the text to edit, it all seems to snap back to normal.

This is continuing to happen after a few tries. Also getting a blank area of about 1/4 screen height at the base of the screen, which is resolved on touching text to begin edit.

• Mod
edited October 2015 Posts: 8,396

@Simeon Version 54. When I tested the keyboard problem I reported with the code below, the top row of the keyboard stayed with the keyboard the way it should when I tapped the screen to show the keyboard. But going a little further, if I select some code, the popup `cut,copy,paste,re-indent,lookup` is sideways.

``````supportedOrientations(LANDSCAPE_ANY)

function setup()
end

function draw()
end
``````
• Mod
Posts: 2,020

@Mark yes I started seeing that on build 54 too. It happened with the shader test code above.

• Mod
Posts: 2,020

@Simeon I should have thought of this when I wrote the original ticket about matrix attributes:

Would it be possible do you think, as well as passing Codea `matrix` objects into the buffer, to also be able to pass an array with 16 elements? And, following on from that, would it also be possible to allow support for buffers of the other matrix types that GLES supports (mat3 mat2), so you could for instance pass an array of 9 elements to a mat3 buffer?

I feel guilty about asking, seeing as you've already fixed a whole bunch of my feature requests in the last few days!

• Mod
Posts: 2,020

@Simeon Love the new traceback errors, I sometimes used to use debug.traceback with xpcall, looks like I won't have to now.

Posts: 5,364

@Mark sorry about the code editor font size bugs. I've added a bunch of optimisations and one of them has caused some font caching issues. If I can't resolve them I'll just move the beta version back off the code editor optimisation branch.

@yojimbo2000 you could try the uniform mat4 array, I implemented support for it but haven't tested. Having another test case would be quite useful.

Thinking about the float-array-as-matrix idea. Will have to get back to you on that one.

• Mod
Posts: 2,020

@Simeon holy moly I didn't realise you'd implemented uniform mat4 arrays as well! I'll get on it.

• Posts: 489

@Simeon Just the switching code. When the switching code is invoked (ie the `project` variable doesn't match the stored name) then the project code is completely ignored.

• Mod
Posts: 2,020

@Simeon

Uniform mat4 arrays make Codea lockup:
Main uses 2 uniform mat4s, and works.Test is the same, but swaps the 2 uniforms for a mat4 array length 2, but freezes Codea:

``````--# Test
-- Matrix Mesh Buffer Test
--pass two matrices in in a uniform array to distort rect: Codea locks-up.

function setup()
m = mesh()
m:setColors(color(255,200,0))

end

function draw()
background(40, 40, 50)
perspective()
camera(0,0,400, 0,0,0)

m:draw()
end

vert=[[
uniform mat4 modelViewProjection;
uniform mat4 matrices[2];

attribute vec4 position;
attribute vec4 color;
attribute vec2 texCoord;

varying lowp vec4 vColor;

void main()
{
vColor = color;
gl_Position = modelViewProjection * (matrices[int(texCoord.x)] * position); //
}
]]

frag=[[

varying lowp vec4 vColor;

void main()
{
gl_FragColor = vColor;
}
]]

--# Main
-- Matrix Mesh Buffer Test
--pass two matrices in as uniform variables to distort rect: works.

function setup()
m = mesh()
m:setColors(color(255,200,0))

end

function draw()
background(40, 40, 50)
perspective()
camera(0,0,400, 0,0,0)

m:draw()
end

vert=[[
uniform mat4 modelViewProjection;
uniform mat4 modelMatrix0;
uniform mat4 modelMatrix1;

mat4 matrices[2]; //nb count from 1 when declaring array length...

attribute vec4 position;
attribute vec4 color;
attribute vec2 texCoord;

varying lowp vec4 vColor;

void main()
{
matrices[0] = modelMatrix0; //...but index from 0
matrices[1] = modelMatrix1;
vColor = color;
gl_Position = modelViewProjection * (matrices[int(texCoord.x)] * position);
}
]]

frag=[[

varying lowp vec4 vColor;

void main()
{
gl_FragColor = vColor;
}
]]

``````
Posts: 5,364

@yojimbo2000 thank you for the helpful examples, really aided debugging. New release should fix the uniform mat4 array.

@Mark the font issue should be fixed now.

@LoopSpace the project loading crash should be fixed too. Thanks for the sample code!

• Mod
Posts: 2,020

@Simeon excellent, uniform matrix arrays now seem to be working!

Whilst we're working through my Christmas list of feature requests, would you consider adding support for GLES 3.0? [-O<

Posts: 5,364

@yojimbo2000 that should come as part of iOS — I thought iOS supported GL ES 3?

• Mod
edited October 2015 Posts: 2,020

@Simeon when you try to enable 3.0 in the shader, you get a `version 300 not supported` error. See the discussion here: http://codea.io/talk/discussion/comment/60043/#Comment_60043

3.0 is supported on iOS on anything with an a7 chip or newer

Posts: 5,364

@yojimbo2000 looks like you have to mark the shader with a `#version 300 es` directive in the shader source.

From the apple docs:

OpenGL ES 3.0 includes a new version of the OpenGL ES Shading Language (GLSL ES). OpenGL ES 3.0 contexts can use shader programs written in either version 1.0 or version 3.0 of GLSL ES, but version 3.0 shaders (marked with a `#version 300 es` directive in shader source code) are required to access certain new features, such as uniform blocks, 32-bit integers and additional integer operations.

• Mod
Posts: 2,020

@Simeon yes, you get that error if you put `#version 300 es` into the shader string (is that what you meant by "in the shader source")?

Posts: 5,364

Oh I see, I'll look into what's needed to support it.

• Mod
Posts: 2,020

This is shaping up to be the best Codea update ever! Love the new trace reporting in the error messages.

Posts: 5,364

Thanks @yojimbo2000, uploading a build with experimental OpenGL ES 3.0 support (if you have the required hardware). It seems OK in my testing.

• Mod
Posts: 8,396

@Simeon Version 55. The cut,copy,paste popup looks like it's fixed for the orientation problem, but the top keyboard row starts at a right angle to the keyboard for about 2 seconds then rotates to the correct position on the keyboard.

• Mod
Posts: 8,396

@Simeon Update to the above post. If the iPad is laying flat, the top keyboard row and popup are in the wrong orientation, but as the iPad is moved towards a straight up position, they rotate to the correct orientation.

• Posts: 489

@yojimbo2000 What can you do with OpenGl ES 3.0? Is there a reference somewhere?

• Mod
Posts: 2,020

@LoopSpace I have no experience of using 3.0, just reading about it, lots of materials online. It eases lots of the limits of 2.0, so you can have eg 128 attribute slots instead of 16, attributes can be arrays etc. It allows for things like instanced drawing, where you supply an array of matrices and a single draw call draws the geometry at all those transformations, potentially a big speed increase. That last one might take some work on the Codea API side to get working. It would be the biggest step forward for codea 's graphic capabilities since the mesh/shader API launched if all those could be implemented. On my phone right now, can't wait to try this out.

• Mod
Posts: 2,020

Plus it's backwards compatible and an optional inclusion, so no shader code should break

• Posts: 489

@Simeon No crashes confirmed. Thanks.

• Mod
Posts: 2,020

Has the new Xcode runtime been added to the export option in the beta? I can test this later.

• Posts: 211

@Simeon since Codea 2.1, there is a black screen between splash screen and game's begin

• Mod
edited October 2015 Posts: 2,020

@LoopSpace and anyone else experimenting with GLES 3.0, this Apple page is quite a handy cheat sheet to the changes you need to make to the shader language (this is entirely optional and is only active if you put `#version 300 es` in the shader strings): https://developer.apple.com/library/ios/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/AdoptingOpenGLES3/AdoptingOpenGLES3.html#//apple_ref/doc/uid/TP40008793-CH504-SW18

And this is the bible:

https://www.khronos.org/registry/gles/specs/3.0/GLSL_ES_Specification_3.00.4.pdf