Not every project uses the stuff-on-the-left, and sometimes screen real estate is useful, so how about a full-screen mode without those dialog stuff (would still need the control buttons, I guess).
It’s in the current build (this will come as soon as 1.1.2 is approved and we submit the next version!). There’s a new Display library. The API is:
-- Display the parameter + output area
displayMode(STANDARD)
-- Display the project full screen, Back / Pause / Play / Reset buttons overlaid
displayMode(FULLSCREEN)
-- Display the project full screen, no buttons
-- We'll probably put in some fail-safe like triple-tap-three-fingers to exit
displayMode(FULLSCREEN_NO_BUTTONS)
-- To query the current display mode:
if displayMode() == FULLSCREEN then
...
We will also include an exit() function so you can build your own back / exit buttons.
The rest of the library contains
backingMode(STANDARD)
backingMode(RETAINED)
Great! That’ll be very useful.
Now, how about a split-screen mode for when using the VGA adapter? With the option to draw stuff just on the iPad screen. Then you could have a simulation running on the main screen with lots of handy buttons/keys/sliders on the iPad version that can be altered without obscuring the view on the main screen.
I’ve been thinking about display-output. It might even be nice to have the code on the iPad and the game running on the display. Editing code could show changes immediately, would be cool with AirPlay. It’s something to explore a bit further down the track.
We have a related new feature though. John wanted split screen in his physics demo game, so added a scissor test function. You can set up multiple viewports and draw to them. We’ve been using it to play the game multiplayer, split screen, using Nat’s analog controller class.
Yeah! Those analog dual stick controls can really be put to use now. Great news indeed.
C’mon apple. It’s been almost a month. Can’t wait for the updates.
Unless you’re disabling the home button - there is no need for a magic-hidden-exit-gesture. I fear anything done will inevitably conflict with what some user wants to do - but the home key has no such conflict. It’s easy to implement our own exit gesture, if we actually desire one.
“Unless you’re disabling the home button…”
Though I fear unless the user releases the app from memory (quits via the multitasking bar) – relaunching the app will return the app to the full screen mode (last state the app was in). Perhaps this behavior can be changed… at least this is how the app behaves now.
Ahhhh… Good point.
I’m comfortable with this. But I also acknowledge it would very quickly be a FAQ.
But I suspect even with a magic exit gesture, it’ll be a FAQ. I can’t imagine “three-finger-drag-up” or whatever being more obvious than “home then kill the app”
Maybe simply adding some “exit fullscreen” boilerplate code?
If you do indeed add a magic exit gesture - it should work in any mode.
Yes, it would be non-obvious, but it would also be located in the entry for FULLSCREEN_NO_BUTTONS in the reference documentation.
Maybe the exit gesture can just call displayMode(STANDARD) rather than close().
Possibly these would cover most situations
DisplayMode(STANDARD) - the way thing are today
DisplayMode(FULLSCREEN) - full screen mode except any swipe from the left would display the parms on top of the full screen, similiar to how messages can be displayed in all apps by a swipe from the top
DisplayMode(NOPARMS) - true fullscreen that would rely on exiting Codea state in the tray (or the program calling another display mode)
[edit: that’s pretty much a restatement of the above, FULLSCREEN_NO_BUTTONS/NOPARMS, would require tray exit if not handled well. The FULLSCREEN description is a slight change to the behavior]
On a related topic, considering that we will be able to save states soon, should there be a standard closing() function available? This would be used for things like saving data etc. on exit. It may have to be constrained to not allow certain activities or only allowed to be active for a set amount of time. It should be similar to what is available when the iPad button is pressed to exit an application (though I’m not familiar with how that works in detail).
@Ipda41001 yeah the displayMode() API is fully functional in the current build of Codea. Which we will submit as soon as Apple makes a decision on 1.1.2 
I’m unsure about closing() - if you want to add support for save-on-close you could use displayMode(FULLSCREEN_NO_BUTTONS), then place your own “exit” button on screen, and when that is tapped do your clean-up and exit by calling the new close() function.
I was thinking of the user scenarios where they click the iPad button, the power button, the reboot sequence, or battery life shut down (due to Codea being so addictive).