Codea 1.5.2 Beta

.@Simeon It happens when displayMode is FULLSCREEN. The left arrow disappears from the button menu in the left hand corner.

EDIT: a workaround is to open the console and type close() in the repl

.@toadkick it happens when you use displayMode(FULLSCREEN) outside of the setup() function. If you put it inside the setup() function then the back button will remain visible. Will be fixed, but that’s an alternative workaround for now.

Haven’t been able to reproduce the sound issue I mentioned, so maybe it was just a freak accident. :slight_smile:

The issues in can also be observed in this version.

Finally got a chance to give this a whirl - in a word amazing! The export is really elegant and if you use dropbox or something similar then importing the generated project into Xcode is a trivial exercise. Some observations:

  1. Putting displayMode(FULLSCREEN) inside the setup() function only fixes the back button disappearance in Codea. In the simulator it is still gone. However, this may be intentional as its functionality in Xcode would be ambiguous. It could quit the simulator (i.e. same as cmd q).

  2. Setting the default screens and icons from Codea will be handy. I look forward to seeing how @Simeon produces an elegant way of handling the hundreds of different icon sizes needed (slight exaggeration).

  3. I expect to see a lot more Codea apps in the app store once this version is released.

  4. Next up I will have a play around with IAP, Game Center and iAd to see if these can still be hooked in. At first glance this doesn’t seem obvious. I can’t see where the LuaState and OSCommand classes have gone! (@Simeon? Runtime Resources?)

@Reefwing thanks for your feedback. Glad you like it!

  1. The back button is now dependent on whether Codea has anything to go back to — in the exported projects, it’s the only view, so no back button. If you integrate it into an app where you have some previous view, a back button will show up so you can go back. (The fact that it’s missing in Codea is a bug, though.)

  2. I will probably just have it generate the following icons from a selected image: Icon-72@2x, Icon-72, Icon@2x and Icon. The rest will have to be taken care of by the user, if they want them. Default screens will be fixed and up to the user to keep or replace on their own (a fairly trivial exercise).

  3. I hope so!

  4. I’ll be bringing it back in a much more well-defined way. I’m still considering an API for “plugin” loading. I’m thinking of the following:

An addition to CodeaViewController:

- (void) registerAddon:(id)addon withName:(NSString*)name;


This adds your addon to the Codea Runtime, which then notifies it for the following events:

@protocol CodeaAddon 

//For registering your custom functions and libraries
- (void) codea:(CodeaViewController*)controller willCreateLuaState:(lua_State*)L;


//For clean up (if necessary)
- (void) codea:(CodeaViewController*)controller didCloseLuaState:(lua_State*)L;

//Handling changes to the viewer state (if necessary)
- (void) codeaPaused:(CodeaViewController*)controller;
- (void) codeaResumed:(CodeaViewController*)controller;
- (void) codea:(CodeaViewController*)controller didChangeViewMode:(CodeaViewMode)mode;

//The reset button is pressed, this will cause:
//  didCloseLuaState and willCreateLuaState to be called again in sequence
- (void) codeaWillReset:(CodeaViewController*)controller;

//Called before and after a frame is drawn
- (void) codeaWillUpdateFrame:(CodeaViewController*)controller withDelta:(CGFloat)deltaTime;
- (void) codeaDidUpdateFrame:(CodeaViewController*)controller withDelta:(CGFloat)deltaTime;



I'd love to get your feedback on this system.

Would be interesting to see an example plugin, to get more feel for how it will work. I’ve just messed with the current objective C files in the old runtime. It will be valuable for customizing the runtime. Good work. :slight_smile:

Hello @Simeon. I do not use Xcode much, but the new feature is excellent and seems to work well.

If Codea 1.5.2 will also fix some bugs, did you see the one reported by @aciolino here? If a vec3 or vec4 uniform is altered in the Shader Lab using the UI sliders then, in the Bindings, the Lua snippet created starts with ‘vec2’, in error.

@mpilgrem I did see that one, it’s in my list of things to fix. Hopefully by the next build.

.@Simeon - that all makes sense. I like the delegate API pattern that you have suggested. I will put together some examples to see what methods may be required.

Sounds great @Reefwing, will be interesting to look at.

For what it’s worth, I used the 1.5.2 beta and its spiffy XCode export to submit BullPuckey to the app store. Everything went smoothly (other than me typo-ing the bundle idea and having a near panic as I worked out how to change it in XCode to match). So far, so good.

That’s great news @Mark. Kind of the ultimate way to beta test this feature. Hope it goes smoothly.

Clip() appears to be giving me different behavior than earlier versions. (I can’t swear it’s 1.5.2 that changed as I haven’t fiddled with Clip in some time)

I’m performing a transform in this order Clip(), Transform(), Scale()

Scaled sprites are appearing outside the are covered by the clip() rectangle.

.@Simeon: is there a flag or something exposed to Codea that indicates whether or not the program is running in an exported project rather than in the Codea app? I ask because since the file structure for tabs and dependencies is different in the exported project, I need a way to be able to generate the correct path to a file when not running in the Codea app. If there is not such a flag, so you think you could get one in for 1.5.2?

Hello @Simeon. A minor bug: searching for ‘output’ in the in-app reference brings up a duplicate entry.

.@toadkick good point. I’ll add something like an EXPORTED_RUNTIME global.

Another minor bug: math.pow seems to have been omitted from autocomplete.

Narrowing down the issue with Clip, it appears to behave differently when screen recording is engaged. When recording, clip() doesn’t work properly, with a clip boundary that seems to be offset.

FWIW, I used the export feature to push ScramWords to the App Store. I tried to do the absolute minimum amount of work in XCode. I selected my project in Codea, then selected export and sent the result to myself through email. I then downloaded the attachment and double-clicked to unzip (not even bothering to move the project out of the downloads directory).

Here are the few things I changed:in XCode.


– Changed the bundle ID (previously defined on Apple’s dev site)

– changed the orientation to portrait-only

– Substituted my own icon and startup screen images

– Changed device support from universal to iPad


I ran it through tests on the simulator a time or two. Then, playing dangerously, I archived it, validated against the App ID I had previously created, and distributed to the App Store without bothering to even download the result onto my iPad.

Worked dandy, and the app was approved after a five day wait. I’d estimate my time from hitting export to uploading the binary was less than ten minutes.