Codea 1.5 (Beta 13 & 14)

Beta 13 is uploading. It’s mostly fixes and corrections (thanks @mpilgrem!) and polish.

There is one main new feature: sampler2D uniforms can be interacted with in the Shader Lab. So you can choose custom textures to use while coding shaders.

I’ve labeled the Shader Lab as “Beta” in this release. I’m going to do this for the proper 1.5 release — rather than add all the features I would like to the Shader Lab, I’ll release it in more-or-less the current state. This will help get 1.5 released faster, and allow the Shader Lab to be enhanced in future updates.

What is needed, however, are example shaders — if any of you would like to contribute shaders, please let me know. I’d love to have some great examples for people to learn from.

Also: line rendering has been significantly changed. If this causes problems, let me know.

Mmm… I cannot create a project, or open any custom or demo projects after installing this version :stuck_out_tongue:
Codea completely freezes (if I reduce it and reopen it, it will crash).
I have restarted my 3rd gen ipad, too. iOS 6.0.1

Happens when I try to access the Shader Lab too

Still happens after completely deleting Codea and reinstalling it

edit: haha damn it, guess I won’t be coding this evening :stuck_out_tongue: Maybe it’s a sign I should be more social and go hang with the wife and kids ^^

(Update) Fixed in beta 1.5(14).

Hello @Simeon. Below is an Editor bug relating to beta 1.5(12). It happens in portrait and landscape orientation:

  1. Open the Physics Lab example project (being a project with lots of tabs).

  2. Touch the Viewer to call up the on-screen keyboard, and open the in-app reference.

  3. Scroll up, so that the ‘tabs’ bar appears.

  4. Dismiss the on-screen keyboard.

  5. Dismiss the in-app reference, using the top left arrow button.

  6. BUG: The ‘tabs’ bar slides to the left as the in-app reference disappears but does not grow to fill the width of the Viewer.

(Update) Fixed in beta 1.5(14).

Hello @Simeon. Below is a rather subtle Editor bug in beta 1.5(12).

  1. In portrait orientation, open the Physics Lab example project.

  2. Drag the text down and release, to allow the hidden ‘rubber band’ to pull the text back up.

  3. BUG No. 1: The ‘tabs’ bar disappears, leaving a blank strip in its place.

  4. Drag the text up (hiding the ‘tabs’ bar zone).

  5. Drag the text all the way down (beyond row 1) and release, to allow the hidden ‘rubber band’ to pull the text back up.

  6. BUG No. 2: The ‘momentum’ of the text bouncing back up appears to cause the ‘tabs’ bar zone to slip a little (a few rows of pixels) off the top of the Viewer.

  7. However, it is not the momentum, but some sort of mis-match. If you repeat steps 5 and 6, more and more of the ‘tabs’ bar zone slips off the top of the Viewer. After about 50 repetitions, the ‘tabs’ bar disappears off the top of the Viewer.

Ditto on the freeze with 1.5(13).

Sorry about the freeze everyone. @Xavier you can re-install the old version (12) for now, through TestFlight.

Fix is uploaded (B14) - sorry about the bug.

Hello @Simeon. In beta 1.5(14), I think there is a bug with color(gray, alpha):


--
-- Test Card
--

function setup()
    col = color(50, 150, 200, 250)
    grey = color(127)
    transparentGrey = color(127, 63)
    print(col) -- Output: (50, 150, 200, 250)
    print(grey) -- Output: (127, 127, 127, 255)
    print(transparentGrey) -- BUG Output: (127, 127, 127, 127)
end

function draw() background(0) end

Thanks @mpilgrem, bug fixed.

With regard to example shaders, what sort of thing are you looking for? Most of mine are quite closely linked to the code that uses them so wouldn’t be suitable for a general purpose set, but on the other hand might be suitable for examples of what shaders can do.

Looking at my list I have:

  1. Alpha mask shader: use one texture as a mask for another
  2. A group of shaders that produce the Game of Life simulation: there’s the GoL itself but then also a rendering shader that takes the raw GoL texture and makes it look nicer.
  3. Various fractal shaders.
  4. A vertex shader that defines trajectories for the pieces of an image making it “explode”.

Many of these were explorations in shader capabilities and may not be optimal.

For example, in the Game of Life you need to work with two images: a source image containing the previous iteration and a target image to record the next iteration. So I need to keep swapping between the two. At the moment, both images are registered with the shader and I use a flag to switch between the two. But the conditional thus gets evaluated for ever pixel. If the two textures are always stored in the GPU anyway then calling m.texture = image_a should just reassign a pointer and thus be much, much quicker. But if m.texture = image_a makes a fresh copy of the image then it is expensive.

So is it better to do m.texture = image_[a/b] each draw than evaluating a conditional for each pixel?

m.texture = image_a should simply tell the mesh where in GPU memory to find image_a. If image_a is not in GPU memory, it is loaded and cached (usually the first time you do the assignment). It should be faster than a conditional on every pixel.

With the new sampler2D picker it should be easier to demonstrate slightly more advanced shaders — such as masking and blending between images.

I am curious, do your fractal shaders render in the Shader Lab? Or are there issues that prevent this? They are really cool and would be a great asset to include, if it’s something you would like to do.

Currently the Shader Lab uses a simple Codea project to render your shader preview. I’ve placed the code for the Shader Lab “project” below.

What I’d really love to do (unsure if there is time) is to add a few more of these projects — one with a 3D sphere, one with a 3D cube, and modify the existing “plane” one to subdivide the plane so that vertex shaders have more interesting data to work on. I’d also really like to allow interaction, such as drag to rotate the scene, and pinch to zoom.

The idea was that you would be able to select from these built-in scenes by using the settings button in the upper right of the preview window (this button is hidden in build 13).

The way it works is: the Shader Lab calls the special updateShaderSample function, which uses the special shader key #:SHADERLAB_CURRENT_SHADER (only valid while the Shader Lab is running) to return the currently edited shader. Then, whenever any uniforms are modified with the interactive popups, the Shader Lab calls updateShaderUniform with the uniform name, and new data.

-- ShaderTemplatePlane

-- Use this function to perform your initial setup
function setup()
    m = mesh()
    key = "Cargo Bot:Codea Icon"
    tw,th = spriteSize(key)
    m.texture = key
    rectIndex = m:addRect(0,0,tw,th)
end

function updateShaderSample() 
    m.shader = shader("#:SHADERLAB_CURRENT_SHADER")
end

function updateShaderUniform(uniformName, data)
    if uniformName == "texture" then
        m.texture = data
        tw,th = spriteSize(data)
    else
        m.shader[uniformName] = data
    end
end

-- This function gets called once every frame
function draw()
    -- This sets a dark background color 
    background(24, 24, 32, 255)

    -- This sets the line thickness
    strokeWidth(5)

    -- Do your drawing here
    m:setRect(rectIndex,WIDTH/2,HEIGHT/2,tw,th)
    m:draw()
end

```

.@Simeon Thanks for the pointer on pointers - that’s useful to know.

To my immense surprise, the fractal shader does render in the lab (see latest tweet). It was a bit of a pain with the parameters because I use a switch variable to determine which fractal to choose (mandelbrot, julia set, cantor set, sierpinski triangle, newton-raphson iterations). When setting these from lua, I can set the parameter to a fixed integer. However, it’s quite hard to hit a specific value in the parameter selector in the shader lab. Or at least, if there’s a knack then I didn’t find it. My best seemed to vary between a delta of 0.01 and 0.02, but the 0.02 would set me off course.

Hello @Simeon. Some comments on tween (which may repeat comments on earlier betas):

(1) the in-app reference has the wrong names for easing functions. For example tween.easing.quadIn should be tween.easing.inQuad.

(2) the in-app reference refers to easing functions that do not exist. For example tween.easing.quad.

(3) the in-app reference omits the easing functions tween.easing.inCirc, .outCirc, .inOutCirc, .outInCirc.

(4) the tween() function has the effect of creating global variables easing and loop. I am not sure if that is a bug or by design. I was surprised anything would be created outside of the tween namespace and in the global namespace.

(5) the in-app reference says that tween() returns an ‘int’ but it returns a table.

new drawing rules the new way to draw thin lines make them much thicker. Then my ants are now completely transformed… Then dont look like ants any more, rather like tarantula spiders… Is this new rule here to stay? If so i am going to have to redesign them completely. Please let me know. Btw, i understand there were some problems with previous drawings with thin lines, but i had managed to work with them (at the cost of a lot of work). So now if you solve them, i have back compatibility problem. Usually, it is better to do the improvement, but provide a way to enable back compatibility, so the users dont have to rework everything. But i understand it is not easy for you…
[edit] going from stokeWidth(3) to (1.5) solves most of the problem.

Hello @Simeon. It may be a breaking change for @Jmv38’s ants - which made a feature of a bug (as well as a bug out of a feature) - but I think the new rendering of a smooth line(), at all strokeWidth’s, is much improved.

(Update) However, one (positive) side-effect is that the following ‘patch’ used in the Physics Lab example project is no longer required:

(1) the project (in the PhysicsDebugDraw tab) had a strokeWidth of 2.5 for the circle’s circumference and a strokeWidth of 5.0 for everything else (including in the ‘Test7’ tab);

(2) the strokeWidth of 5.0 for everything else can now be reduced to be 2.5 too.

(Further Update) However, something odd is happening for noSmooth() lines.

The prefix-free global variable names for use with blendMode() are also a positive development, in my view. However, the in-app reference for ‘blendMode’ needs to be updated, accordingly.

Also, something odd is happening in the in-app reference rendering for ‘blendMode’ between the end of the ‘srcFactor’ section and the top of the ‘destFactor’ section.

The Spritely example project will need a little redesign: the ‘Create new image.’ button now falls underneath Codea’s ‘toggle displayMode’ button, and cannot be pressed.

It would be good to document the location of the ‘toggle displayMode’ button zone in the in-app reference (so that it can be avoided in code) - perhaps, currently, in the ‘displayMode’ entry.

In beta 1.5(14), the Sounds Plus example project has not yet been updated fully to use the new parameter API.

Nice shot @mpilgrem :wink: (… a feature of a bug (as well as a bug out of a feature) …)

Actually, the odd behaviour of noSmooth() line() is not new to beta 1.5(14). Below is a slightly modified version of the Lines example project:


supportedOrientations(LANDSCAPE_ANY)

-- The following line is not required
-- t = 0

function setup()
    -- Additional parameter below, for smoothing option
    parameter.boolean("isSmooth", true)
    parameter.number("x1", 0, WIDTH, 100)
    parameter.number("y1", 0, HEIGHT, 100)
    parameter.number("x2", 0, WIDTH, WIDTH - 100)
    parameter.number("y2", 0, HEIGHT, HEIGHT - 100)
    parameter.number("width", 1, 100, 10)
    parameter.integer("lineCap", 0, 2, 0)
end

function draw()
    background(10, 10, 20)
    -- The following line is not required
    -- fill(255,0,0)
    stroke(255)
    strokeWidth(width)
    -- The following lines are no longer required
    -- if width < 3 then
    --     noSmooth()
    -- else
    --     smooth()
    -- end
    -- The following line could be added
    if isSmooth then smooth() else noSmooth() end
    lineCapMode(lineCap)
    line(x1, y1, x2, y2)
end

If noSmooth() then it appears that strokeWidth is capped at about 20, and it is not strictly true - as stated by the in-app reference - that the rendered line has square end caps. (Draw a diagonal line with the maximum strokeWidth.)

If smooth() and strokeWidth(1), the line is rendered with a strange moire pattern-type effect at certain orientations.