Codea Beta 2.3.1 (47)

Also running into situations where I can’t scroll the text. This seems to happen after I’ve pasted addition text into a tab

Hi All,

Just updated to 2.3.1(47) on my iPad2 iOS8.3. Prior to the Codea update I was having a lot of problems with the editing screen in that tabs didn’t seem to respond to touch and the system seemed to slow down a lot. Not sure if it had frozen but it tended to not respond to touches - some similar problems mentioned above. Since the Codea update this behaviour has stopped - much more responsive to touch.

I noted the effect @techdojo mentioned above in a screen splitting effect before and after the update. Easy to see - just press on the twolivesleft logo at the bottom and then back and you should see the redraw of the project lists.

Still having a few problems with Aircode losing focus. I’ve been loading files into --[[ and --]] pairs to avoid issues with syntactical errors in old files with the latest builds. Also right clicking on the Aircode window initially brings up the wrong menu - I have to click off to the right to get the right context menu up - usually needing paste for code pasting.

Thanks All,

Bri_G

:smiley:

@Mark the row of keys popping up over running code should have been fixed in 2.3.1. Hmm. I’ll look into it.

@Simeon - the bug about not being able to set the value of WIDTH & HEIGHT appears to have reappeared in the latest testflight build.

I’m calling supportedOrientations() outside of setup(), and then attempting to set WIDTH & HEIGHT inside setup() before calling displayMode().

@TechDojo setting displayMode will likely cause WIDTH and HEIGHT to be set to new values. Have you tried setting them after?

@Simeon The latest beta crashes if you try to paste code at the last line. It also crashes if the cursor is on the last line and the copy, paste, etc buttons are showing and the screen is touch anywhere.

Thank you @dave1707, I will look into it. I wonder if it’s related to iOS 8.3 too.

@Simeon - sorry my mistake I was trying to set WIDTH & HEIGHT after calling displayMode().

If I set them before then the changes get ignored (as you said), however if I set them after then the values are only correct after you press the reset button and rerun the app - just like the bug the first time round.

@TechDojo I’ll review the code changes between now and then to see what changed.

i just got the latest update from the App Store, and there’s a bug with using the copy button inside the built-in browser. every code snippet i copy results in an error on the first line that is indented. it seems like the character </194> is being copied. i have to manually rewrite any snippets to get them to compile

@matkatmusic thanks for the report, I’ll check it out.

@TechDojo I have an idea what’s changed. I’m unsure if pursuing the settable WIDTH / HEIGHT feature is a good idea (it’s brittle due to the fact that Codea sets WIDTH and HEIGHT). I think we really need the ability to set the canvas size, like displayMode. Perhaps displaySize or something.

@Simeon - I’m totally cool with whichever way you want to implement it. I agree setting WIDTH & HEIGHT directly does seem like a hack to me and I suppose I could just set my own versions of them. I see this as a low priority issue as I wanted to use these variables to “fake” alternative resolutions as I’m currently working on an iPhone app using Codea and when the project is exported this code is never run, I just thought it might be a symptom of a deeper problem with the graphics engine.

However as the number of devices increase then it would be awesome to have a consistent way to emulate other devices to aid in universal app development.

:slight_smile:

@Simeon it’s actually an extra hidden character at the end of every line that’s indented that is being added. maybe some rogue html line return statement?

@matkatmusic are you on Windows? I wonder if it’s the Windows newline character sequence (\\r\ ) instead of the unix newline (\ )

@Simeon this is from within the browser in codea on my ipad.

I tried the COPY command from within the built in browser and I’m not having any trouble with running code that I copied.

@matkatmusic sorry for some reason I thought you were talking about Air Code (forgot to re-read your earlier post on the first page before I replied). What iOS version are you on?

7

I’m seeing some issues with shaders in the latest beta. For example, here’s a simple program using the arc shader. It runs just fine and displays just what I would expect. Only if I leave it running, within a couple of minutes the whole app pops away.

 -- Arcs

displayMode(FULLSCREEN)

function setup()
    
end

-- This function gets called once every frame
function draw()
    -- This sets a dark background color
    background(40, 40, 50)

    strokeWidth(50)
    noFill()
    stroke(131, 180, 97, 255)
    arc(WIDTH / 2, HEIGHT / 2, 350, 60, 120)
    stroke(97, 180, 168, 255)
    arc(WIDTH / 2, HEIGHT / 2, 350, 120, 180)
    stroke(97, 109, 180, 255)
    arc(WIDTH / 2, HEIGHT / 2, 350, 0, 60)
    stroke(157, 97, 180, 255)
    arc(WIDTH / 2, HEIGHT / 2, 350, -60, 0)
    stroke(180, 97, 108, 255)
    arc(WIDTH / 2, HEIGHT / 2, 350, -120, -60)
    stroke(180, 137, 97, 255)
    arc(WIDTH / 2, HEIGHT / 2, 350, -180, -120)
end

--
-- Arc
--

function arc(x, y, radius, a1, a2)
    local m = mesh()
    m:addRect(x, y, radius * 2, radius * 2)
    m.shader = shader("Patterns:Arc")
    m.shader.size = (1 - strokeWidth()/radius) * 0.5
    m.shader.color = color(stroke())
    m.shader.a1 = math.rad(a1)
    m.shader.a2 = math.rad(a2)
    m:draw()
end

Thanks @Mark I’ll give that a run tonight and see how it goes.