Codea 1.5 (Beta 20)

This beta (17) could be considered a “release candidate.”

It has a lot of little enhancements relating to handling error messages, polish, documentation and example projects. As always, please report any bugs you find here. The release notes have detailed changes.

From now until submission (when the localisation is finished) I’ll be trying to fix bugs.

Looking nice! Tried a few of my projects and after some tween easing renamings it seems to work fine. The only issue right now is that search results that I click on scroll a bit to little in the editor, especially if the result is in the end on the tab, so that there is no lines below it to scroll.

Might be nice to have an introductory project next to getting started. Or think about the order of the example projects for a beginner. More like lesson 1, lesson 2. Just an idea for future versions. Was a bit surprised to see the ui in swedish. :slight_smile:

17 is blowing up when I create a new class.

Tried your bug @Mark. When i create a new class codea is still alive, but the tab is completely empty (no pre-written functions). Ipad1, ios5.1.

Ah, mine too, crashes with new class. (And I’m afraid to say that the swedish translation is a bit messy, with some faults, but maybe I can change the language of my iPad to avoid that. :slight_smile: )

.@tnlogy is the Swedish translation bad enough that I should remove it from the release? Anyone can edit it at http://translate.twolivesleft.com

.@Mark I am unable to re-create this, does it happen every time for you? In every project?

Yes, you should remove it. I’ve seen so many strange mistakes now I’m afraid. Drives me crazy. :slight_smile: :P. Maybe I can help out later on.

Have only crashed once for me after an evening of tests, so I think it is stable enough, except if that new class error is happening often.

@Simeon Yep, seems to be every time, in projects small and large. When I create a new class, the tab appears empty, without to usual boilerplate text. If I touch this tab, I get kicked out of Codea. When I come back in, the tab is still there, and still blank, but from then on it works normally.

.@tnlogy will do on the removal. What is the new class error? I keep trying to make new classes and am unable to get anything unusual to happen.

Is it possible to describe in more detail? (I.e. step-by-step)

.@Mark thanks for the more detailed explanation. That’s very strange, I am unable to get this to happen on my device — perhaps it is a release mode only bug.

I’m on an ipad2, still running 6.0, if that helps (on 3G at the moment and haven’t spent the bandwidth to move to 6.1)

Downloading now…

I know it’s way too late, but parameters now? Crazy good. Id like a way to make them full screen, ie have a program that was only parameters - sliders and such - and no main screen.

You guys never cease to amaze me, btw. I know people have asked before, but I want to use this environment (or something very similar) on the desktop. Just saying. Love2d, my goto for that, is lovely, but I want the full codea API. But I don’t want to take time away from the iPad version. Is a puzzlement.

Thanks @Mark, it happens to me too, but only with the TestFlight version. I’ll have this fixed soon.

Thanks for the kind words @Bortels! Glad you like it. I want to do a Mac version very much.

Edit: This bug is really odd. Doesn’t happen in anything except the version on TestFlight, which is extremely hard to debug. I’m starting to think the App Package was corrupted in some way.

Okay I figured out the new class bug. Next build will have this fixed.

+1 for the Mac version. Coding graphic intensive apps on Codea is at least an order of magnitude easier than Xcode.

I have almost completed another app headed for iTunes - is there an updated runtime in the works?

Sorry @Reefwing, the new Runtime will take a bit of time. Though given you are a beta tester, I would be happy to start sending you some stuff early so you can try an App Store submission.

I plan to re-design the whole process for Codea Runtime. Having the source is nice, but most people just want to compile their app, and the rest want to add functionality to the runtime.

I’m thinking about a simple static library with a formalised extension architecture, so you can easily add your own extensions. I was hoping to work on some useful pre-packaged extensions too, such as iAds, Game Center, and so on.

No drama .@Simeon, my new app isn’t using any of your funky new bits so the old runtime is fine for now. I’ve been working on understanding the physics library better and will do a tute on that to coincide with the app release.

Happy to test out the new runtime when you get to it.

I agree with your thoughts on a modified workflow. Exporting to an Xcode project format would be awesome. It would also be nice to test iAds and Game Center from within Codea but I suspect that may not be possible.

The extensions are a good idea too. I’m sure the community would put out useful stuff and it would mean that you and the boys at TLL don’t have to do all the heavy lifting. Access to some of the standard UIKit controls would encourage more utility apps.

BTW v1.5 looks fantastic, the documentation format is a lot easier to use and the new animation functionality is great. I’m going to have a play with that next. I still haven’t quite got my head around the whole shader thingy (yet).

I would also enjoy an early release for an app store submission. The current runtime seems to be much slower than Codea 1.5, which is a good rating for the new Codea. :slight_smile:

Would be nice if the runtime would create a community in the future, for adding different functionality.

.@Simeon: some “issues”.

  1. I’m still getting the odd editor issue with long lines where the cursor isn’t where the display thinks it is.

  2. I notice that strokeWidth now takes into account the matrix. This is … interesting. I broadly like it (though have to rejig a few bits of code) except that it is possible to define the scale in 3 directions but the strokeWidth only in one. So if one wants a consistent strokeWidth regardless of the matrix (as was the old behaviour), one is scuppered by scale(10,20) strokeWidth(??) - that is, there’s no value there that ensures a consistent line width. (example in the code below)

  3. The tooltips gets confused by tables. It seems to just count commas but if an argument is a table then the internal commas should not be counted (example in the code below).

  4. The tween documentation could do with a list of the possible loop settings and an example showing how to set both a loop and easing. The Animations sample program helps here, but it would be nice to have an example in the docs.

  5. Also in the tween documentation, in the explanation section you have {x: 10} when it should be {x = 10}. That confused me!

  6. After doing lookup there’s no obvious way to get rid of the documentation window. After a while, I remembered that the triangle did it. Maybe the documentation-eye could also function as a close button here since if I press it once it effectively replaces the lookup view with the documentation view, and then it can be used to close it. So pressing it twice effectively gets rid of the documentation.

Here’s some code demonstrating the strokewidth feature:


function setup()
    x = WIDTH/2
    y = HEIGHT/2
    L = 300
    tw = {xs = 1, ys = 1}
    tween(3,tw,{xs = 21, ys = 1},{loop = tween.loop.pingpong})
end

function draw()
    local xs = tw.xs
    local ys = tw.ys
    local x = x / xs
    local y = y / ys
    local Lx = L / xs
    local Ly = L / ys
    background(69, 69, 69, 255)
    scale(xs,ys)
    strokeWidth(5)
    stroke(153, 141, 26, 255)
    noFill()
    ellipse(x,y,Lx,Ly)
end

(Must admit, I quite like this one!)

Thanks for your great feedback, Andrew.

Interesting example project. It’s probably something you could account for inside a shader. The ellipse you are drawing just uses a simple shader (you can actually see the code in the “Patterns” pack of shaders). You could pass the non-uniform scale into the shader to adjust the stroke widths unevenly, maintaining the width under different scales.

  1. I know about this one, but I can’t fix it without completely rewriting the editor. Which I plan to do after 1.5 (it will take a long time to rebuild all of Apple’s text editing controls from scratch!). I have a workaround that fixes the issue, but performance is quite slow. I guess I could release this workaround as a beta version to see what you think.

  2. I actually changed this behaviour on @mpilgrem’s suggestion. I realise that scale-invariant stroke widths could be useful, but it did seem like the right way to go. The old version of noSmooth() line was drawn using the GL_LINE primitive. This resulted in clipped end caps and, because the line consisted of only two vertices, the scale only affected the end points.

  3. I forgot about that bug. I’ll see if I can fix it now.

  4. I could probably add this to the English docs, but it would be too late to make localisation. I might have to consider this for next release.

  5. Good catch, fixed it. I thought I had fixed all of those occurrences. @John briefly forgot the table syntax when writing the initial draft of the animation docs. We can only put it down to too much javascript.

  6. Using ‘Lookup’ should cause the reference ‘eye’ button to become highlighted. Tapping the eye button will dismiss the documentation as normal. I am unable to create a situation where using Lookup does not highlight the eye button.