Howdy, Stranger!

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

Codea 1.5 (Beta 9 and 10)

edited January 2013 in Beta Posts: 489

(Edit) The new beta 1.5(9) does fix the bug that was affecting my 'RectWithHole' code. Thank you.

Tagged:
«1

Comments

  • Posts: 489

    Hello @Jmv38. I wonder if the problem you are having with Tendril is a 1.5(8) beta issue? Does it also occur in beta 1.5(9)?

  • Jmv38Jmv38 Mod
    Posts: 3,295

    Hi @Mpilgrem. I was not aware v9 was released. I'll check once i've installed it.

  • Posts: 489

    Regarding the new 'expression key' in beta 1.5(9): as a 'hunt and peck' touchscreen typist, I prefer the way that this has been implemented in the Shader Lab Editor (which is still 'hunt and peck') rather than in the Editor (which mixes 'peck and slide' with just 'pecking'). I also prefer the way that the placement of the 'expression key' dialog in the Shader Lab Editor does not obscure the last visible line of text (which tends to be the line that I am editing), unlike in the Editor (where the dialog tends to be placed over what I am editing).

  • Posts: 489

    In beta 1.5(9) the Shader Lab Editor appears to be more stable than in earlier betas, but it is still not wholly stable (I have had it crash out of Codea once).

    In the Shader Lab Editor, it is possible to call up the on-screen keyboard without the text automatically scrolling up so that the cursor is visible above the keyboard.

  • Posts: 489

    Below is a further experiment with shaders and noise, from the same source as my first comment on the subject:

    Lua:

    --
    -- WorleyGLSL
    --
    -- Shader makes use of:
    -- Cellular noise ("Worley noise") in 2D in GLSL
    -- Author: Stefan Gustavson
    -- http://webstaff.itn.liu.se/~stegu/GLSL-cellular/
    
    supportedOrientations(LANDSCAPE_ANY)
    function setup()
        m = mesh()
        m:addRect(WIDTH/2, HEIGHT/2, WIDTH, HEIGHT)
        m.shader = shader("Documents:Worley")
        parameter.number("freq", 1, 289, 17)
        parameter.number("jitter", 0, 1, 1)
        parameter.color("col1", color(239, 231, 30))
        parameter.color("col2", color(239, 30, 30))
    end
    
    function draw() 
        m.shader.freq = freq
        m.shader.jitter = jitter
        m.shader.col1 = col1
        m.shader.col2 = col2
        m:draw()
    end
    

    Vertex shader:

    //
    // Vertex shader: Worley
    //
    
    uniform mat4 modelViewProjection;
    attribute vec4 position;
    attribute vec2 texCoord;
    
    varying highp vec2 vTexCoord;
    
    void main()
    {
        vTexCoord = texCoord;
        gl_Position = modelViewProjection * position;
    }
    

    Fragment shader:

    //
    // Fragment shader: Worley
    //
    
    precision highp float;
    
    varying highp vec2 vTexCoord;
    uniform float freq;
    uniform float jitter;
    uniform vec4 col1, col2;
    
    // ---------------------------------------------------------------
    // Cellular noise ("Worley noise") in 2D in GLSL.
    // Author: Stefan Gustavson
    // http://webstaff.itn.liu.se/~stegu/GLSL-cellular/
    // ---------------------------------------------------------------
    // Copyright (c) Stefan Gustavson 2011. All rights reserved.
    // Permission is hereby granted, free of charge, to any person
    // obtaining a copy of this software and associated documentation
    // files (the "Software"), to deal in the Software without
    // restriction, including without limitation the rights to use,
    // copy, modify, merge, publish, distribute, sublicense, and/or
    // sell copies of the Software, and to permit persons to whom the
    // Software is furnished to do so, subject to the following
    // conditions:
    //
    // The above copyright notice and this permission notice shall be
    // included in all copies or substantial portions of the Software.
    //
    // THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
    // EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES 
    // OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
    // NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
    // HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
    // WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
    // FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
    // OTHER DEALINGS IN THE SOFTWARE.
    
    vec3 permute(vec3 x) {return mod((34.0 * x + 1.0) * x, 289.0);}
    
    vec2 cellular(vec2 P) {
        #define K 0.142857142857 // 1/7
        #define Ko 0.428571428571 // 3/7
        vec2 Pi = mod(floor(P), 289.0);
        vec2 Pf = fract(P);
        vec3 oi = vec3(-1.0, 0.0, 1.0);
        vec3 of = vec3(-0.5, 0.5, 1.5);
        vec3 px = permute(Pi.x + oi);
        vec3 p = permute(px.x + Pi.y + oi);
        vec3 ox = fract(p * K) - Ko;
        vec3 oy = mod(floor(p * K), 7.0) * K - Ko;
        vec3 dx = Pf.x + 0.5 + jitter * ox;
        vec3 dy = Pf.y - of + jitter * oy;
        vec3 d1 = dx * dx + dy * dy;
        p = permute(px.y + Pi.y + oi);
        ox = fract(p * K) - Ko;
        oy = mod(floor(p * K), 7.0) * K - Ko;
        dx = Pf.x - 0.5 + jitter*ox;
        dy = Pf.y - of + jitter*oy;
        vec3 d2 = dx * dx + dy * dy;
        p = permute(px.z + Pi.y + oi);
        ox = fract(p*K) - Ko;
        oy = mod(floor(p*K),7.0)*K - Ko;
        dx = Pf.x - 1.5 + jitter*ox;
        dy = Pf.y - of + jitter*oy;
        vec3 d3 = dx * dx + dy * dy;
        vec3 d1a = min(d1, d2);
        d2 = max(d1, d2);
        d2 = min(d2, d3);
        d1 = min(d1a, d2);
        d2 = max(d1a, d2);
        d1.xy = (d1.x < d1.y) ? d1.xy : d1.yx;
        d1.xz = (d1.x < d1.z) ? d1.xz : d1.zx;
        d1.yz = min(d1.yz, d2.yz);
        d1.y = min(d1.y, d1.z);
        d1.y = min(d1.y, d2.x);
        return sqrt(d1.xy);
    }
    // ---------------------------------------------------------------
    
    void main() {
        vec2 F = cellular(vTexCoord * freq);
        float n = 0.1 + (F.y - F.x);
        gl_FragColor = n * (col1 - col2) + col2;
    }
    
  • Posts: 489

    Hello @Simeon. Is the following in the 'Shader Overview' in the in-app documentation correct?

    The documentation states that any uniform variables declared in your shader can then be (typo: docs say 'by') accessed on your mesh as follows:

    myMesh.myCustomUniform = 3.5
    

    Should that:

    (1) be myMesh.shader.myCustomUniform = 3.5; and

    (2) refer to uniform variables being 'set for the shader' (rather than 'accessed' ) on your mesh?

  • Jmv38Jmv38 Mod
    Posts: 3,295

    I had a strange bug on v9 editor: after selecting some text, contextual menu would not appear. I had to kill codea and it was back to normal.

  • SimeonSimeon Admin Mod
    Posts: 5,362

    .@mpilgrem thanks for starting this thread and your feedback.

    Is the following in the 'Shader Overview' in the in-app documentation correct?

    That's incorrect. Thank you for the find, I've fixed it. If you have any issues with the way that chapter is written, please let me know.

    as a 'hunt and peck' touchscreen typist, I prefer the way that this has been implemented in the Shader Lab Editor (which is still 'hunt and peck')

    On "Hunt and peck" versus drag. I will restore the old behaviour (tapping the key to get the popup fixed on-screen). The reason I wanted to encourage drag selection was because it seemed faster — and it follows Apple's own key popover implementation (i.e. if you press and hold the "e" key you can drag to select a diacritic).

    The styling also matches Apple's keyboard popover style, which I much prefer over the generic "popover" design.

    Regarding the way it obscures the last line. It's going to obscure a fixed portion of your text, and depending on your scroll position that may or may not obscure the cursor location. In general I hoped people would know the symbol they were after before pressing the key (at least, after the first few times they used it).

    Good catch that the Shader Lab hasn't been updated to use the latest one. I'll have to fix that.

    In the Shader Lab Editor, it is possible to call up the on-screen keyboard without the text automatically scrolling up so that the cursor is visible above the keyboard.

    Good find. That will need to be fixed.

  • Posts: 1,255

    I like the drag-select on the numerical symbols. One suggestion: how about adding the "." key? I know it's available right there on the screen, but already the rhythm of selecting the rest of a calculation off the pop-up is so slick I miss that one key.

  • Jmv38Jmv38 Mod
    edited January 2013 Posts: 3,295

    Many nice things in this new release. One bad thing is: i've lost all my high scores i had saved with globaldata in my KraizyCircles game... We dont lose the projects when we update Codea, could it be the same for saved data?
    [edit] my mistake, sorry! The data are still there. It is just that localData has been repaired, so my program has automatically swithched to local data save, where it cannot find the score saved in global data... So Codea works fine!

  • Posts: 489

    Hello @Simeon. On the current implementation of the drag selection, I am not sure what I am doing, but sometimes I find I have transitioned from the 'expression key' into 'the drag the cursor around the Editor using the keyboard' functionality when I did not intend to.

    In terms of the design of key input more generally, could there be more than 11 keys in the strip above the standard keyboard? If the keys were narrower, you could fit others in. If the keys were the width of those in the 'expression key' pop up, I think you could fit 17 keys in the strip. My vote would be to move +, -, *, /, [] and {} from the pop up to the strip. That would create space in the pop up for other, rarer, symbols (examples might be ^, :, <=, >=, ==, _).

  • Jmv38Jmv38 Mod
    Posts: 3,295

    .@mpilgrem you were right: with this version your program does notcrash any more.

  • SimeonSimeon Admin Mod
    Posts: 5,362

    .@mpilgrem that's a bug — I think if you have "Keyboard Gestures" turned on (where you can drag anywhere on the keyboard to move the cursor) it interferes with the expression key dragging. I'll have to disable the keyboard gestures while the expression key is active.

    I actually find the keys on the keyboard strip a bit small as it stands — that's one of the reasons for moving to drag-selection for the small expression keys, so you don't have small tap targets. I could always add the rarer symbols to a third row in the popup?

    (And now that you mention it, ":" should definitely be in there as it's not a rare symbol at all.)

    .@Mark that's a good idea. I'll look at adding a "." key.

    By the way, I've been looking at implementing your API suggestions for compass and location data. Compass is a little more complicated than I initially thought — because the OS can display a calibration graphic that is used to direct the user to move their device in a specific pattern.

  • Jmv38Jmv38 Mod
    edited January 2013 Posts: 3,295

    EDITOR BUG there is still this bug of the editor loosing the 'last cursor location in this tab'. I can see that this last location is saved, because when i switch back to previous tab, i see first the cursor at the good location, but after a fraction of a second the display scrolls to a wrong location.

  • Jmv38Jmv38 Mod
    Posts: 3,295

    crashes this version seems to crash more often (my game KraizyCircles crashes 2x more)

  • Jmv38Jmv38 Mod
    edited January 2013 Posts: 3,295

    EDITOR BUG happened twice today: the editor got locked in some weird state where
    1/ the selection contextual menu does not appear on tap.
    2/ the keyboard cannot be removed.
    I had to kill codea manually to recover. Never seen that in previous versions.
    [EDIT] i found what generates the problem: any time i use the special button to popup the special keys... Then it happen! This is reallu annoying then. Please a quick update?

  • edited January 2013 Posts: 489

    I've been thinking further about key input in the Editor. Some keys insert content at the cursor. Other keys do something else (namely: indent, toggle in-app documentation, move cursor left/right, expand selection left/right, search code or run code).

    Below is an imagined keyboard where the strip has keys (no smaller than the current 'expression key' popup keys) for inserting content and a key to the right that toggles on/off a second strip with keys with other functions (and space for more functions to come...).

    image

  • edited January 2013 Posts: 489

    Some further observations on the 'Shaders & Mesh' chapter of the in-app documentation:

    Shader Overview

    In the final paragraph "For advanced users, ...", the example might start with the line:

    myShader = shader()

    mesh

    This does not refer to normals or shader (unlike Mesh Overview).

    mesh.clear

    This is silent about normals and other attribute arrays.

    mesh.normal

    Is there a myMesh:normal(i) equivalent of myMesh:vertex(i)?

    shader

    This does not refer to the properties myShader.vertexProgram and myShader.fragmentProgram that are discussed in 'Shader Overview' (as opposed to the arguments). (Edit) ... And that the properties can be read as well as written.

    triangulate

    This still refers to points having to be in a clockwise order.

  • edited January 2013 Posts: 489

    An experiment with RotationRate:

    --
    -- Rotation Rate Calibration Tester
    --
    
    supportedOrientations(PORTRAIT)
    displayMode(FULLSCREEN)
    function setup()
        if deviceMetrics().platformName == "iPad 1G" then
            print("This code needs a gyroscope."..
                " An iPad 1 does not have one.")
        end
        img = readImage("Planet Cute:Character Boy")
        iw = img.width
        ih = img.height
        f = math.min(WIDTH/iw, HEIGHT/ih)
        iw = iw * f
        ih = ih * f 
        x = WIDTH/2
        y = HEIGHT/2
        ax, ay, az = 0, 0, 0
    end
    
    function draw()
        local w = iw * math.cos(math.rad(ax))
        local h = ih * math.cos(math.rad(ay))
        background(0)
        translate(x, y)
        rotate(az) -- Rotates in degrees
        sprite(img, 0, 0, w, h)
        ax = ax + RotationRate.y
        ay = ay + RotationRate.x
        az = az - RotationRate.z
    end
    
  • edited January 2013 Posts: 489

    Another, more geometrical, experiment with RotationRate:

    --
    -- Cube Rotate
    --
    
    supportedOrientations(LANDSCAPE_LEFT)
    function setup()
        if deviceMetrics().platformName == "iPad 1G" then
            print("This code needs a gyroscope."..
                " An iPad 1 does not have one.")
        end
        local size = math.min(HEIGHT, WIDTH) / 2
        d = 1000
        m = cubeMesh(size)
        dir = vec3(0, 0, 1)
        dir2 = vec3(0, 1, 0)
    end
    
    function draw()
        background(0)
        perspective()
        local mat = matrix()
        local dxa = RotationRate.y
        local dya = - RotationRate.x
        local dza = - RotationRate.z
        mat = mat:rotate(dxa, 1, 0, 0)
        mat = mat:rotate(dya, 0, 1, 0)
        mat = mat:rotate(dza, 0, 0, 1)
        dir = mult(mat, dir)
        dir2 = mult(mat, dir2)
        local x = dir.x * d
        local y = dir.y * d
        local z = dir.z * d
        camera(x, y, z, 0, 0, 0, dir2.x, dir2.y, dir2.z)
        m:draw()
    end
    
    function cubeMesh(size)
        local v = {}
        local c = {}
        for i = 0, 7 do
            local x = (i % 2) * 2 - 1
            local y = (math.floor(i / 2) % 2) * 2 - 1
            local z = (math.floor(i / 4) % 2) * 2 - 1
            v[i] = vec3(x, y, z) * size / 2
            c[i] = color(127 + 127 * x, 127 + 127 * y, 127 + 127 * z)
        end
        local ver = {}
        local col = {}
        for v1 = 1, 3 do
            local v2 = v1 * 3 % 7
            local v3 = 7 - v1
            local v4 = 7 - v2
            local vt = {v[0], v[v1], v[v2], v[0], v[v3], v[v4], 
                v[7], v[v2], v[v1], v[7], v[v4], v[v3]}
            for i = 1, #vt do
                ver[(v1 - 1) * #vt + i] = vt[i]
            end
            local ct = {c[0], c[v1], c[v2], c[0], c[v3], c[v4], 
                c[7], c[v2], c[v1], c[7], c[v4], c[v3]}
            for i = 1, #ct do
                col[(v1 - 1) * #ct + i] = ct[i]
            end
        end
        local m = mesh()
        m.vertices = ver
        m.colors = col
        return m
    end
    
    function mult(mat, vec)
        local v1 = mat[1] * vec.x + mat[2] * vec.y + mat[3] * vec.z
        local v2 = mat[5] * vec.x + mat[6] * vec.y + mat[7] * vec.z  
        local v3 = mat[9] * vec.x + mat[10] * vec.y + mat[11] * vec.z
        return vec3(v1, v2, v3)    
    end
    
  • JohnJohn Admin Mod
    edited January 2013 Posts: 616

    .@mpilgrem

    mesh:normal(i) works (may not be documented at the moment). mesh:clear() clears all buffers including custom attributes. Triangulate is winding order agnostic, will have to update the documentation.

  • SimeonSimeon Admin Mod
    edited January 2013 Posts: 5,362

    .@Jmv38

    [EDIT] i found what generates the problem: any time i use the special button to popup the special keys... Then it happen! This is reallu annoying then. Please a quick update?

    Ah it seems to be an iOS 5.x bug — it works okay in iOS 6.0. I've made Codea use the old-style popover when running on iOS 5.x.

    .@mpilgrem

    That's a fantastic example of RotationRate. Works really well.

    Thank you for the documentation bug report — I've fixed these issues.

    Having a second strip of keyboard keys is a good idea, though I'm finding that I like using the drag-to-select expression keys for symbolic input.

    The next build will fix the bugs with iOS 5, keyboard gestures, and adds an extra row of keys to the expression popup. It will also allow hunt-and-peck style usage like the previous style popover.

  • Jmv38Jmv38 Mod
    Posts: 3,295

    .@mpilgrem what is supposed to be happening with your rotaterate examples? I have just a static image. I am in ipad1 and ios5.1

  • edited January 2013 Posts: 489

    Hello @Jmv38. If the iPad1 does not have a gyroscope, the new RotationRate in beta 1.5(9) will not be meaningful. On an iPad2 or later, in my examples, the image 'stays put' when the iPad is tilted or rotated. (Edit) I've added the following to my examples:

    if deviceMetrics().platformName == "iPad 1G" then
        print("This code needs a gyroscope."..
            " An iPad 1 does not have one.")
    end
    
  • Jmv38Jmv38 Mod
    Posts: 3,295

    Ok! Thanks.

  • Posts: 2,161

    .@mpilgrem Strange, your example doesn't work for me. When I rotate around more than one axis in turn and come back to the start then the cube doesn't return to its initial state. Maybe different versions of iPads return their data differently.

    Here's what I came up after reading far more about Euler angles than I ever wanted to.

    --displayMode(FULLSCREEN)
    supportedOrientations(PORTRAIT)
    
    function setup()
    
        parameter.watch("RotationRate")
        parameter.watch("rot")
        m = mesh()
        m.vertices = {
            vec3(0,0,0),
            vec3(1,0,0),
            vec3(0,1,0),
            vec3(0,0,0),
            vec3(0,1,0),
            vec3(0,0,1),
            vec3(0,0,0),
            vec3(0,0,1),
            vec3(1,0,0),
            vec3(1,0,0),
            vec3(0,1,0),
            vec3(0,0,1)
        }
        m.colors = {
            color(255, 255, 255, 255),
            color(255, 0, 0, 255),
            color(0, 255, 0, 255),
            color(255, 255, 255, 255),
            color(0, 255, 0, 255),
            color(0, 0, 255, 255),
            color(255, 255, 255, 255),
            color(0, 0, 255, 255),
            color(255, 0, 0, 255),
            color(255, 0, 0, 255),
            color(0, 255, 0, 255),
            color(0, 0, 255, 255)
        }
        rot = matrix()
    end
    
    function draw()
        background(40,40,50)
        perspective()
        camera(0,0,5,0,0,0,0,1,0)
        rot = rot:rotate(RotationRate.z,0,0,1)
        rot = rot:rotate(RotationRate.y,0,1,0)
        rot = rot:rotate(RotationRate.x,1,0,0)
        modelMatrix(rot:inverse())
        m:draw()
    end
    
    function touched(touch)
        if touch.state == ENDED then
            rot = matrix()
        end
    end
    

    I'm not convinced that I have the order of rotations right, it would be useful to know exactly what information RotationRate encodes (what I found on the Apple developer docs was useful but there are various things that it could be so it would be useful to know precisely what it is).

  • SimeonSimeon Admin Mod
    Posts: 5,362

    .@Andrew_Stacey RotationRate won't allow you to accurately track the device rotation — the error will accumulate and it will eventually be off. I believe it is supposed to be used in conjunction with the other sensors (like accelerometer) to re-calibrate and reduce errors.

    There is also the device attitude (CMAttitude in the iOS dev docs, if you're interested) — this has a rotation matrix, quaternion, and yaw/pitch/roll representing the orientation of the device. It can be corrected by using a reference frame. This might be useful to expose in the future.

  • Posts: 2,161

    .@Simeon I was very excited to see RotationRate, until I started playing with and reading about it when I realised that it wasn't what I wanted. Nonetheless, it's better than nothing and even if it isn't what I need to do I want to do, I'm sure I'll find a use for it somewhere so learning about it seems a good thing to do.

    What I do want is what the device attitude would give me. If you remember way way back to my "shape explorer", I had it set up so that it would use Gravity to ensure that "down" was always "down". What I'd also like to be able to do is also ensure that "left" was always "left". At the moment, I could combine Gravity and RotationRate to give me something that worked to within a rough amount but then made it possible for the user to correct it. This would fix one inelegance in my current system: that when you go "over the top" then the picture swings wildly due to gravity coinciding (or being close to) the normal vector to the iPad.

    So please, please do expose the device attitude. But also it would be good to know exactly what the RotationRate is saying. The above code seems to work to within reasonable error no matter how I turn my iPad (4th generation).

  • Posts: 489

    Hello @Andrew_Stacey. I think our two examples are mathematically similar, if not the same. I do not think there is a 'correct' order for the rotation operators - I was assuming that if the rotation angles were 'small enough' they would more or less commute and if they were not then reordering would not solve the problem.

  • SimeonSimeon Admin Mod
    Posts: 5,362

    .@Andrew_Stacey the problem with attitude is that it takes a portion of CPU power to compute the corrected rotation matrix. I'm assuming it combines accelerometer and gyroscope in some way to maintain a corrected rotation matrix (I don't think there's any extra data that it's using — as the compass needs user calibration to work). Having it on and available all the time might not be a good thing.

  • edited January 2013 Posts: 489

    Hello @Simeon. When you write up the RotationRate in-app documentation, you might also document the deviceMetrics() function and provide detecting an iPad 1G as a code example.

    (Edit) Another passing thought on in-app documentation: Codea's class() function - it is used so much, perhaps it deserves its own 'Chapter'...

  • Posts: 2,161

    .@mpilgrem That's not a safe assumption. Commutation vanishes to first order but is very definitely non-trivial at second order. So to make that assumption you need to know that second order is insignificant and the magnitude that I see is not sufficiently small for that assumption. More importantly, though, is the fact that you are accumulating the rotations as you are storing them in the vectors dir and dir2. So the errors combine and order becomes very significant.

    I wonder if the difference in our code is to do with the initial orientation of the iPad. I notice that you rotate by y about the x-axis and -x about the y-axis. What orientation do you have the iPad in when you start your program?

    .@Simeon so it's no better (theoretically - I expect there would be some accuracy gains) than accumulating the RotationRate readings? That's disappointing.

  • SimeonSimeon Admin Mod
    edited January 2013 Posts: 5,362

    .@Andrew_Stacey it's probably better than simply accumulating rotation rate readings, as there is probably some basic filtering and correction going on. But it draws from the same sensors.

    After doing some more reading it does use the compass (if available and calibrated by the user) for certain reference frame settings:

    CMAttitudeReferenceFrameXArbitraryCorrectedZVertical

    Describes the same reference frame as CMAttitudeReferenceFrameXArbitraryZVertical except that the magnetometer, when available and calibrated, is used to improve long-term yaw accuracy. Using this constant instead of CMAttitudeReferenceFrameXArbitraryZVertical results in increased CPU usage.

  • Posts: 2,161

    .@mpilgrem Here's my version of your code.

    --
    -- Cube Rotate
    --
    
    supportedOrientations(LANDSCAPE_LEFT)
    function setup()
        local size = math.min(HEIGHT, WIDTH) / 2
        d = 1000
        m = cubeMesh(size)
        dirz = vec3(0, 0, 1)
        diry = vec3(0, 1, 0)
        dirx = vec3(1,0,0)
        mat = matrix()
    end
    
    function draw()
        background(0)
        perspective()
        local mat = matrix()
        local dxa = RotationRate.y
        local dya = - RotationRate.x
        local dza = RotationRate.z
        mat = mat:rotate(dza, dirz.x,dirz.y,dirz.z)
        mat = mat:rotate(dya, diry.x,diry.y,diry.z)
        mat = mat:rotate(dxa, dirx.x,dirx.y,dirx.z)
        dirx = mult(mat, dirx)
        diry = mult(mat, diry)
        dirz = mult(mat, dirz)
        local x = dirz.x * d
        local y = dirz.y * d
        local z = dirz.z * d
        camera(x, y, z, 0, 0, 0, diry.x, diry.y, diry.z)
        m:draw()
    end
    
    function cubeMesh(size)
        local v = {}
        local c = {}
        for i = 0, 7 do
            local x = (i % 2) * 2 - 1
            local y = (math.floor(i / 2) % 2) * 2 - 1
            local z = (math.floor(i / 4) % 2) * 2 - 1
            v[i] = vec3(x, y, z) * size / 2
            c[i] = color(127 + 127 * x, 127 + 127 * y, 127 + 127 * z)
        end
        local ver = {}
        local col = {}
        for v1 = 1, 3 do
            local v2 = v1 * 3 % 7
            local v3 = 7 - v1
            local v4 = 7 - v2
            local vt = {v[0], v[v1], v[v2], v[0], v[v3], v[v4], 
                v[7], v[v2], v[v1], v[7], v[v4], v[v3]}
            for i = 1, #vt do
                ver[(v1 - 1) * #vt + i] = vt[i]
            end
            local ct = {c[0], c[v1], c[v2], c[0], c[v3], c[v4], 
                c[7], c[v2], c[v1], c[7], c[v4], c[v3]}
            for i = 1, #ct do
                col[(v1 - 1) * #ct + i] = ct[i]
            end
        end
        local m = mesh()
        m.vertices = ver
        m.colors = col
        return m
    end
    
    function mult(mat, vec)
        local v1 = mat[1] * vec.x + mat[5] * vec.y + mat[9] * vec.z
        local v2 = mat[2] * vec.x + mat[6] * vec.y + mat[10] * vec.z  
        local v3 = mat[3] * vec.x + mat[7] * vec.y + mat[11] * vec.z
        return vec3(v1, v2, v3)    
    end
    

    Two main changes: the rotations are effected using the current axes, not the standard ones. And the matrix multiplication function is modified since OpenGL uses row vectors and not column vectors so multiplication is with the vector on the left. This now keeps the cube in what I think is "invariant position" on my iPad, even with large rotations, with no precession.

  • Jmv38Jmv38 Mod
    Posts: 3,295

    BETA 10 good to have the key picker working again on 5.1! Thanks. Dont forget to repair the 'copy from output print fields' functionnality. I had an error message but i cant copy it to paste it in the forum: annoying.

  • Posts: 2,161

    .@Simeon but it won't be a "magic bullet". There will still be the same accumulation errors, just smaller.

    What about direct access to the compass? For providing a global frame of reference, then compass+gravity would be better than rotation rate. (Do non-3G iPads have a compass?)

  • Posts: 2,161

    .@Simeon did you notice my request about being able to load specific pages from a PDF via readImage?

  • SimeonSimeon Admin Mod
    edited January 2013 Posts: 5,362

    .@Andrew_Stacey I did notice your request about specific pages. I need to make some modifications to the PDF reader to support this, but it's possible. At the moment I'm focusing on completing the Shader Lab. But I'll see if I can put it in for 1.5. If not it should be soon after.

    On the compass. I'm unsure if non-3G iPads have them, but they need to be user calibrated (i.e., moved in a figure eight, so that the iPad can distinguish between local magnetic fields and the Earth's magnetic field). The OS presents a calibration diagram and dismisses it if the user follows instructions (the app can optionally dismiss it after some time as well).

    The CMAttitudeReferenceFrameXArbitraryCorrectedZVertical setting I mentioned above uses the compass to provide a global frame of reference for "long-term yaw accuracy". But because it uses the compass it also requires a user calibration step.

  • Posts: 1,255

    non-3G iPads have a compass, but not GPS.

  • Posts: 489

    In beta 1.5(10), searching for 'RotationRate' does not yield the new in-app documentation on that subject.

    Some other in-app documentation observations:

    'Vector' chapter

    This could include '4D Vector'/vec4 too, as other parts of the in-app documentation now refer to the vec4 userdata ('buffer').

    buffer

    This refers to four Codea Lua userdata types - vec2, vec3, vec4 and color - and one GLSL ES type float. Should the latter refer to the Lua type 'number'?

    Should how Codea maps/casts Lua types to GLSL ES types be documented, both in terms of buffers and in terms of uniform variables ('Shader Overview').

    background, fill, tint, stroke

    Inconsistent with other parts of the documentation and Lua, this refers to 'int' arguments.

    zlevel, perspective, ortho, camera

    Inconsistent with other parts and Lua, this refers to a 'float' argument.

    This occurs in other parts of the documentation: the type of some arguments is specified to be other than one of the Lua basic types or one of the Codea userdata types.

  • Posts: 489

    Hello @Andrew_Stacey. Your version of the rotating cube has perfected what I was trying to achieve (step 1). Step 2 is to add normals and a lighting shader...

    On the subject of the orientation of the iPad, I believe that the x, y, z axes of RotationRate are aligned with the iPad in portrait orientation (irrespective of what orientation Codea is running in), with clockwise rotation (looking down the increasing direction of the axis) being positive.

    --
    -- Axes Explorer
    --
    
    displayMode(FULLSCREEN)
    function setup()
        setLayout()
        crr = color(255, 0, 0)
        cg = color(0, 255, 0)
        fontSize(32)
        strokeWidth(10)
    end
    
    function draw()
        background(0)
        fill(255)
        text("z:", 30, yl)
        fill(crr)
        text("RotationRate", x1, yh)
        fill(cg)
        text("Gravity", x2, yh)
        stroke(crr)
        line(x1, yl, x1 + RotationRate.z * d, yl)
        line(x1, ym, x1 + RotationRate.x * d, ym + RotationRate.y * d)
        stroke(cg)
        line(x2, yl, x2 + Gravity.z * d, yl)
        line(x2, ym, x2 + Gravity.x * d, ym + Gravity.y * d)
    end
    
    function orientationChanged(orientation)
        setLayout()
    end
    
    function setLayout()
        d = (WIDTH / 4) * 0.9
        x1 = WIDTH / 4
        x2 = WIDTH * 3 / 4
        yl = HEIGHT / 10
        ym = HEIGHT / 2
        yh = HEIGHT * 9 / 10
    end
    
  • SimeonSimeon Admin Mod
    edited January 2013 Posts: 5,362

    .@mpilgrem the int and float use in the documentation is because Lua has no way to distinguish between the two. I guess I could use "integer" and "number" just to be clear to the user about expected values. Would this be better?

    Good catch on RotationRate and search. I forgot to generate an updated search index. Also forgot to add vec4.

    Buffer specifically uses "float" because it maps to a attribute float array in a vertex shader. But we can use "number" as well here — like "color" really maps to a scaled "vec4" in GLSL.

    Should we "rotate" the RotationRate based on device orientation, like we do with Gravity?

  • Posts: 489

    On the 'rotate' the RotationRate question, I would make its behaviour consistent with that of Gravity, and I suggest the direction of the axes is documented in the in-app documentation.

  • Posts: 2,161

    Seconded about RotationRate orientation. I'd also make the order in which the axes work clear in the documentation.

  • Jmv38Jmv38 Mod
    edited January 2013 Posts: 3,295

    EDITOR BUG twice: suddenly, after suppressing some lines, or cut/paste maybe, what appears on the screen is different from what i am typing . I seems the cursor is displayed at 1 location, but i am really editing 20 lines below or so. Closing the project and reopening solves the problem (except for the characters i have deleted by mistake 20 lines below..). First time i ever get this bug.

  • Posts: 1,255

    I'm getting consistent crashes from search. As soon as I type a 'z' in the box... I'm out of Codea.

  • SimeonSimeon Admin Mod
    Posts: 5,362

    .@Mark documentation search? I think I know what this one is. Thanks for the report.

    .@Jmv38 I've hit this bug as well. Any ideas on how to reproduce? It's a hard one to make appear when you want it.

  • Posts: 489

    Hello @Simeon. I've been thinking about the in-app documentation questions. In-app documentation is one of Codea's strengths, and what you have done in 1.5 will take it to a new level.

    Codea Overview

    I wondered if it would make sense to have a new, initial, chapter for the in-app reference called 'Codea Overview' (or something similar). It could cover certain matters that are common to one or more parts of the Codea API.

    At the moment, 'Getting Started' (outside of the reference) covers: 'Getting Started', 'Example Projects', 'Project Basics', 'Editor Basics', 'Editor Features', 'Codea Basics' and 'Troubleshooting'.

    'Codea Basics' (namely, the various functions called by Codea) might be a candidate for a 'Codea Overview' in the reference.

    Other candidates might be:

    • an explanation that Codea uses two different languages: Lua version 5.1, for most code, and the OpenGL ES Shading Language, for shaders. (The latter is stated in 'Shader Overview', but I think the former is not actually stated anywhere explicitly.)

    • an explanation that Codea uses the small number of Lua basic types (including number, string, boolean, function and table) together with userdata types specific to Codea. The userdata types could be listed, with related links to the parts of the reference where they are written up: body, image (codeaimage), soundbuffer (codeasoundbuffer), color, contact, joint, matrix, mesh, shader, touch, vec2, vec3, vec4.

    You might add that the elements of Lua tables indexed by integers 1, 2, 3 to 'n' are referred to as 'arrays'. (The term 'array' is used, for example, in the documentation of triangulate() and buffer.)

    • an explanation of Codea's class() function

    • an explanation of the distribution of code between 'tabs' and the use of 'dependencies'.

    Arguments, properties and results of functions

    It seemed to me that the following were distinct things:

    • the type of an argument, property or results of functions
    • the acceptable range of values for an argument or property
    • what the function does, precisely

    Most arguments or properties are type 'number'. In a 'Codea Basics' chapter, you might state: "If the type of an argument or property is not stated, it can be assumed to be number." That would avoid a lot of references to 'number' elsewhere in the documentation.

    For example, in the case of zLevel(z), the argument z could simply be described as "The amount of depth for future drawing operations. Use positive values to draw in front and negative values to draw behind." without any reference to 'number' (or 'float', as is currently the case).

    Take this code for example:

    --
    -- Arguments
    --
    
    function setup()
        col = color(1000.5, 255, -127.5)
        print(col) -- Output: (1000, 255, -127, 255)
        fill(col)
        print(fill()) -- Output: 1000 255 -127 255
        strokeWidth(5)
    end
    
    function draw()
        background(0)
        ellipse(WIDTH/4, HEIGHT/2, 200)
        ellipse(WIDTH * 3/4, HEIGHT/2, -200) -- Draws a square with a circular hole
    end
    

    Currently, the in-app reference says that color takes four 'float' values from 0 to 255 and that fill takes four 'int' values from 0 to 255.

    It would be more accurate to say in both places that:

    "Distinct colors of different opacities are represented by four integers with values from 0 to 255 (red, green, blue and alpha (opacity))."

    For color() it would be more accurate to say that "The function rounds arguments to the nearest integer". For fill() it would be more accurate to say that "If an argument is less than 0 or greater than 255, it is treated as if it were 0 or 255, respectively."

  • Posts: 1,255

    @Simeon -- yep, documentation search.

    BTW, one thing that keeps happening to me: when trying to select text, I end up having the documentation slide in. It sometimes happens so readily that I have a hard time selecting text.

  • SimeonSimeon Admin Mod
    Posts: 5,362

    .@mpilgrem I agree with your suggestions for the documentation. I plan to rewrite the "Getting Started" section to bring it up to date and make it more visual (less text). When I do this, I'll try to incorporate your suggestions.

    A generic "Codea Overview" section would also be good. I'm not sure if I can get around to this before 1.5 — there's so much left to do (namely, the Shader Lab).

    .@Mark I've fixed the "z" search issue for the next build, thanks for reporting it.

    Regarding the documentation sliding in — I've disabled the swipe gesture to open/close documentation sidebar.

Sign In or Register to comment.