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:
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…)
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!")
--alert("hello")
end
-- This function gets called once every frame
function draw()
-- This sets a dark background color
background(40, 40, 50)
-- This sets the line thickness
strokeWidth(5)
-- Do your drawing here
end
function touched(touch)
alert("touch")
end
@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.
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.
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.
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: 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.