Codea Beta 1.5.3

Hi beta-people

It’s been a while since the last beta, sorry about that.

Codea is getting a lot of improvement now, though.

1.5.3 will focus on adding some missing, useful functions to the API (restart, alert, perhaps programmatically creating projects, and so on). As well as optimisations to common rendering scenarios — such as sprite()

This first release integrates an experimental new feature: automatic sprite batching. It is enabled by default, you can see the release notes for more information.

Basically it attempts to draw consecutive calls to sprite as a single mesh(), if possible. This should allow you to do things like render particle systems with sprite(), as well as speed up common uses like lots of the same enemy type being rendered over and over.

There’s also been a lot of other optimisations to sprite() — I’m hoping that many people will find less of a need to implement their code using mesh() due to performance concerns. That is, I’m hoping that sprite() will be “good enough” for a lot of uses.

(mesh() is great, but it requires you to carefully structure your code to work with it. It’s also less intuitive to use.)

If you’d like to see a demo of how sprite batching makes a difference, try out the following Gist:

This renders 1600 sprites using a number of different methods (including mesh()). You can toggle on/off the different uses.

EDIT: Fixed link

UI bug: When I run a fullscreen app, the (new?) icon in the upper left to bring out the sidebar with the console output, when tapped, pops it out, then immediately hides it again. This happens anywhere from 5 to maybe 20 times - ie. I tap, expose/unexpose, I tap, expose/unexpose - then it “fixes” itself, and behaves like you would expect (tap, it exposes the sidebar. tap the close, sidebar goes away).

is there a way to kill that button entirely (and the buttons along the bottom)? FULLSCREEN_NO_BUTTONS (which isn’t listed by the tooltip, but is in the docs) behaves weirdly - I get no buttons until I tap, then they all come back.

Nice to see the sprite optimization - I expect you’ve hit on a common case, this should be helpful in lots of stuff. I’ve been crazy busy with Amazon Web Services, so I’ve neglected my Codea work; there is no AWS library for lua. Hmm. Maybe I should make one… (The AWS API is very fragmented - it would be a chunk of work…)

Hi Simeon. Great news!
Problem with your gist: the project is pulled corrrectly, but:

  • tabs are not in good order : i had to move the Juice class manually just after the main to have it compile.
  • then i get the error:

error: [string “-- Juice…”]:78: attempt to call method ‘draw’ (a nil value).

It seems that you renames rect:draw into rect:drawObject. I created a :draw, then no error. But when i click a choice i get errors again.

  • either you didnt post the good final project.
  • either it is a tab order problem: could you rename the tab in: T00… T01… Etc so they come in the appropriate order?

Oops! Hadnt seen the Juice thread yet! Sorry for posting this.

@Jmv38 drawObject is correctly named. The draw method is in the base class which invokes drawObject

I tried the alert(). Works fine in the setup(). Then i put it in touched(touch) and then when i touch the screen, it goes dim and codea freezes. Have to kill it manully.

-- test alert

-- Use this function to perform your initial setup
function setup()
    print("Hello World!")

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

    -- This sets the line thickness

    -- Do your drawing here
function touched(touch)

@Bortels that’s an odd one. The sidebar button has been there since 1.5 — does anyone else have this issue?

@Jmv38 thanks for reporting the alert() issue. I’ll check it out

@Bortels just a thought — you’re not calling displayMode(FULLSCREEN) at the start of draw()? That would cause the behaviour you’re describing, as it would be resetting the fullscreen mode every frame.

@Jmv38 alert() issue in touched() should be fixed in the next build. It’s an iOS 5.x specific bug that was easy to work around.

I am. Where should it be, in setup?

Yes (or on some action, such as a button press) — if you call it every frame it will keep resetting the screen mode back to full screen. Pressing the sidebar button simply toggles the displayMode, but your code is resetting it back immediately.

@Jmv38 out of curiosity, does the sprite batching make much difference on iPad 1? (You can try it in the gist I linked:

I don’t have an iPad 1 for testing at the moment. So I wonder if it makes a big difference there.

Edit: fixed link

This link is to Juice, which has only 1 sprite?

I tried with Spritely: with 400 sprites the fps oscillate between 50-60 fps, which is, i think, better than before. But to check it i should revert to the previous version of codea.
My other programs use meshes.

Sorry! Wrong link

This is the link:

There should be 1600 sprites

Here are the results:

  • initial 4.0 fps.
  • use string false: 7.7 fps.
  • use mesh or use batch : 14.5 fps.
    So is is about x2 improvement from the regular sprite usage (i always load them in memory). And using the mesh is not better.
    Btw i had a memory crash while playing with the options (setting batch and mesh on).
    When you create your mesh from sprite images, how do arrange them? There may be a lot of lost space when image sizes do not fit? Or do you use a smart algorithm to arrange them?

@Jmv38 Thanks for testing it out. Good to see there is some improvement! Codea won’t auto-batch over multiple textures. It behaves similar to mesh in that there is one texture per batch.

I think the worst-case in the old version of Codea (1.5.2) would have been a lot slower than 4.0 fps on iPad 1, the string (and non-string) lookup mechanism was substantially improved in 1.5.3.

@Simeon: FYI, on a 4th gen iPad, here are the numbers I’m getting:

UseString on: ~12fps
All off: ~25fps
All On: ~52-57fps
Batch on: ~52-57fps
UseMesh on: ~52-57fps
Batch + UseMesh on: ~52-57fps

@Simeon: What do you think the chances are of including the feature to optionally disable tab compilation/execution in the next release? It’s not critical, but my hope is that it might be a simple enough task that it wouldn’t take too long to implement.

@toadkick I would like to but it’s slightly tricky for a number of reasons — the actual functionality is not hard, but the colour schemes will need new states for disabled tabs and dependent projects will need to respect them. I’ll keep it in mind, but I can’t say for sure.