Howdy, Stranger!

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

Codea Beta 2.3.1 (47)

2»

Comments

  • Posts: 688

    @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.

    :)

  • Posts: 212

    @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?

  • SimeonSimeon Admin Mod
    Posts: 5,360

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

  • Posts: 212

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

  • dave1707dave1707 Mod
    edited April 2015 Posts: 8,382

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

  • SimeonSimeon Admin Mod
    Posts: 5,360

    @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?

  • Posts: 212

    7

  • Posts: 1,255

    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
    
  • SimeonSimeon Admin Mod
    Posts: 5,360

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

  • dave1707dave1707 Mod
    Posts: 8,382

    @Simeon I added this line of code at the end of draw and the memory usage just keeps increasing until it closes.

        text(collectgarbage("count"),WIDTH/2,HEIGHT/2)
    
  • dave1707dave1707 Mod
    Posts: 8,382

    @Simeon It appears mesh isn't releasing memory. If I run the code below, memory usage constantly increases even though collectgarbage() is getting called constantly. If I comment out the mesh line in arc(), memory doesn't increase at all.


    function setup() fill(255) end function draw() background(40, 40, 50) for z=1,20 do arc() end text("memory used "..collectgarbage("count")//1,WIDTH/2,HEIGHT/2) collectgarbage() end function arc() local m=mesh() end
  • SimeonSimeon Admin Mod
    Posts: 5,360

    Thanks @dave1707, that's really helpful!

  • edited April 2015 Posts: 1,703

    Hi All,

    Just a thought - I've been playing around with this and come to the same conclusion as @dave1707, but for my own clarification - is it OK to declare a local mesh in a sub function of draw and then use m:draw() from the sub function? If you move the m:draw() to the draw function after the calls there is an error that m is not declared. I tried building the mesh in the setup and editing the mesh components separately but it didn't work - I'm assuming you have to repeatedly build the mesh to facilitate any changes in it.

    Way above my level - leave it to @Simeon.

    Bri_G

    :D

  • SimeonSimeon Admin Mod
    Posts: 5,360

    Thanks everyone, I fixed the memory leak in mesh. I'll update the Xcode runtime so that everyone who exports apps is not affected, and the next version of Codea will include the fix.

  • edited May 2015 Posts: 282

    @Bri_G

    You said:

    If you move the m:draw() to the draw function after the calls there is an error that m is not declared.

    This would be because m would be a local variable to the sub-function of draw().

  • Posts: 1,703

    Thanks @Saturn031000,

    Brought up on minimising memory etc I don't like the idea of building structures using them, destroying them and rebuilding them. I can see that in animation etc it is necessary. The use of the local definition in a sub function seems a bit counter intuitive. The local aspect should destroy the mesh on leaving the function, but ideally you need to destroy the mesh at the end of each draw() loop outside of the mesh function. I think it may have contributed to the memory drain problem.

    Thanks for confirming my thought processes.

    Bri_G

    :D

  • edited May 2015 Posts: 688

    @Simeon - my beta copy of Build 47 expired 23 minutes ago :(
    Is there another beta in the works or has the latest version been submitted yet?

    (or did I miss the latest version???)

    EDIT - Looks like I did - how did THAT happen! :)

    EDIT 2 - However now I have the issue that I can no longer access files via iExplorer as I've had to install the latest version via the app store :(

  • dave1707dave1707 Mod
    Posts: 8,382

    My version expired also. I had to reload the old App Store version.

  • Posts: 1,255

    And me. Looks like the last release hit its due date. If there's a newer one in Testflight, I don't see it.

  • edited May 2015 Posts: 2,042

    One of the things the old Testflight did better IMO... I liked that the builds never expired.

  • SimeonSimeon Admin Mod
    Posts: 5,360

    @JakAttak eventually old builds expired when the profile expired.

    The latest TestFlight beta you had access to was identical to the App Store version. I will look into the iTunes File Sharing key being enabled for future builds (hopefully Apple will allow).

    Sorry I disappeared for the last week or so. Just had my second child, so I have been pleasantly preoccupied :)

  • Jmv38Jmv38 Mod
    Posts: 3,295

    =D>

  • Posts: 2,042

    @Simeon, I stand corrected :) Certainly they lasted longer than 30 days.

    Congrats on the child! =D>

  • Posts: 688

    @Simeon - congrats dude, I guess now all your (very little) spare time will be spent making amusement and educational app's for babies with Codea (that and feed trackers, height and weight trackers etc etc)

    :)

  • SimeonSimeon Admin Mod
    Posts: 5,360

    @TechDojo I'm not so sure. My three year old and I play Cities: Skylines together constantly. So we'll probably stick with making simulations.

  • IgnatzIgnatz Mod
    Posts: 5,396

    @Simeon - congratulations to you - and your partner! :-bd

  • Posts: 282

    Congratulations!

  • Posts: 1,255

    Not really beta (47) related, but it didn't seem worth a whole thread just to say that I've been running Codea against each step of the iOS 9 beta and have had only a few problems. The most consistent issue is the way the new keyboard is laid out with the cut / copy / paste keys, which pushes the extra codea row higher and obscures more of the screen. However, it's not a huge issue. The appearance of the popup copy / paste options within the editor has become spotty, often forcing me to use those new keys rather than the popup values. This may be Apple's intent, but if there's a pattern to when I get a popup and when I don't, I don't see it. Also, there's sometimes a blank area above the keyboard that extends significantly into the text, but disappears if the keyboard is closed.

    That's about it. Programs compile and execute just fine. I think I've had one complete app-closing failure after a long session of coding, but I saw those occasionally under 8.

  • SimeonSimeon Admin Mod
    Posts: 5,360

    @Mark I have removed the extra keyboard keys in the current dev branch. Thanks for the report on the copy/paste menu items not appearing, I'll give it a try.

  • Posts: 211

    @Mark and @Simeon I'm using iOS 9.0 Beta 4 and it was working fine to me! (my iPad is 3rd generation)

  • Posts: 1,255

    One thing I'm noticing in apps compiled using the latest release version of Codea is that I get a momentary flash of the codea environment between the launch image and the start of the app. For a split second, the side bar,etc shows up even if the first thing in your app is a FULLSCREEN. Not a major issue, but a bit of an eyesore.

  • SimeonSimeon Admin Mod
    Posts: 5,360

    @Mark thank you for the report. The start up sequence is a complicated thing (mainly to allow for you to customise the display of the sidebar and orientation through Lua). I'll see if I can see what you're seeing.

  • Posts: 1,255

    Minor suggestion: it would be very nice to be able to push the keyboard to uppercase or numeric. Perhaps by adding parameters to showKeyboard.

Sign In or Register to comment.