CoronaSDK for OS X - Beta 2: The Reimagining

Perry_Clarke · July 8, 2015, 4:13am

After listening to your feedback and much feverish engineering work we’ve changed the way you build CoronaSDK apps for OS X. Instead of having to link your own app in Xcode with CoronaCards you can now choose File > Build > OS X… in the Corona Simulator and all the tricky work is done for you (see below for sooper sekrit beta instructions to enable this). In the future the best of both worlds will be available, easy app creation with the Simulator or complete control using Xcode though this release just allows builds from the Corona Simulator.

So, building an app for OS X in the Simulator like so:

Results in:

You can tweak things like window size, behavior and title in the app’s build.settings and everything that works in the Corona Simulator on OS X works in OS X apps.

While we’re not quite there yet, the intention is that you will be able to submit your OS X apps to the OS X App Store but the first order of business is to get your CoronaSDK apps working well in the new environment and everything should be ready for that.

To enable OS X builds in any Daily Build from 2015.2675 onward, run this command in a Terminal window:

defaults write com.coronalabs.Corona\_Simulator enableOSXBuild -int 1

Documentation is available here: https://docs.coronalabs.com/daily/guide/osx/

Report your successes or failures here in this forum and we’ll try to fix things just as quick we can. Now that the capability to build OS X apps is in Daily Builds we should be able to turn around fixes pretty quickly.

The most annoying bug to look out for in this beta is that it doesn’t properly handle apps which lack width ,

height or scale set to sensible values in config.lua. So, if your app doesn’t seem to want to run properly, check that these values are set correctly in config.lua (some complex setups can fail to “detect” the new environment correctly resulting in nothing being set).

Glitch_Games · July 8, 2015, 1:07pm

This is awesome news and great timing. Now that FL3 is finally leaving the nest I’m able to carve out some time to play with this.

I’ve built FL3 using the latest daily and from what I can tell most is working fine, however there is an issue that is stopping me from really testing the game ( the HUD isn’t showing up ).

It’s most likely a very specific issue for us so it’s hard to post code until I can find out what the exact issue is but until then, is there a list of known issues anywhere I can look at to see if anything jumps out at me?

Perry_Clarke · July 8, 2015, 4:54pm

If it’s working in the Simulator it should work in an OS X build (barring logic that queries the platform and behaves differently).

You can see any output from print statements, etc that your app generates by looking in the system console when you run it:

Applications > Utilities > Console.app

(along with some debug info I need to tidy up)

Glitch_Games · July 8, 2015, 5:35pm

Thanks!

I’m really not sure what’s going on, I thought I did but then I didn’t. I have it narrowed down to something but it’s weird

Perry_Clarke · July 8, 2015, 9:33pm

The issue turned out to be this line in config.lua :

local aspectRatio = display.pixelHeight / display.pixelWidth

In this build, any attempt to access the display object in config.lua will fail so use hardcoded values for now, e.g.

local aspectRatio = 1.5 -- display.pixelHeight / display.pixelWidth

Perry_Clarke · July 9, 2015, 4:25am

This problem should be fixed in the next Daily Build (2676 or higher). config.lua can once more contain any code you like.

The next Daily Build will also show console/debug output from OS X apps that are run from the Build for OS X dialog in the Corona Simulator Console window (or Corona Terminal if you prefer that). Also “excludeFiles” now works for OS X builds.

Glitch_Games · July 9, 2015, 3:59pm

I can confirm this issue is now fixed

firemaplegames · July 9, 2015, 7:10pm

Hey everybody!

Soooo excited for OSX and Windows builds. Just awesome.

I’m having some trouble setting the App’s window size and could use some help.

For the mobile versions of my games, I am rolling my own letterboxing code, which scales to fit the background elements while repositioning foreground elements dynamically.

As such, I do not have width, height, or scale defined in the config.lua file. I am also using a lot of display.* information to set the size on the devices.

This all works wonderfully, however I am having trouble making it work on the OS X desktop version.

As mentioned on the forums previously, I removed all of the display.* calls and hard coded everything. I also set the width, height and scale in config.lua.

The app keeps launching with a humungous window though, about 4x the size of the simulator. Nothing I seemed to do would affect the size of the window.

To keep my sanity, I decided to make a very simple test app to try and narrow things down first.

I’m simply trying to display an image.
The image is 1136 x 726.

I set the width and height in config.lua to 1136 x 726

It works fine in the simulator. (I have it set up as a custom 1136 x 726 device)

Whenever I do a build however, it is always the same huge window that opens up.

If I set resizable to true in the build.settings, the same huge window launches - but I can now resize it to any size. And if I do another build, the app will launch at the previous resized size and at the previous window’s location - I assume this is how it supposed to work in OS X.

I am working on a 30" monitor hooked up to my laptop if that matters. But the simulator is on the monitor too and it is fine.

I am attaching my simple test project if anyone wants to take a look. I am trying to open an 1136x726 window to display a 1136x726 graphic.

Any help is appreciated!

Joe

Glitch_Games · July 9, 2015, 7:25pm

Not sure if this is related however our games seem to always open “fullscreen” no matter the setting, maybe it’s trying to set it to full screen of the 30" monitor even if it’s playing on the smaller one?

p.s. will the first Corona built games released for OS X a all be point and click games? We’ll have to make a special day for that

firemaplegames · July 9, 2015, 7:57pm

It does open in a window if I set it to “normal”, but it is huge.

And it does go fullscreen when set to “fullscreen” mode, but the size is all wrong as seems to be basing the size off that huge window.

The huge window is also larger than my laptop’s screen when I drag it over to that screen.

Hmmm.

And yes, Point n’ Click Adventure party!

Perry_Clarke · July 9, 2015, 9:16pm

@firemaplegames make sure you’re running at least Daily Build 2676 as prior versions didn’t work for the situation you describe. If you are already running 2676, let me know that (it always helps to mention the version of the software you’re reporting issues with).

The default window size is set to be slightly smaller than the size of the monitor it opens on (so if your laptop screen was the main screen for OS X, it would be sized to fit on that). But it’s just the default and probably wont suit everyone so you can either set a window size or make the window resizable in your build.settings as documented here. I wonder if we should make the window resizable by default if it’s displaying scaled content at the default size. Perhaps a wise move would be to limit the default size so it’s not humorously large on bit displays.

Glitch_Games · July 9, 2015, 11:05pm

We now have Forever Lost: Episode 3, Cabin Escape, and Ferris Mueller’s Day Off all working flawlessly ( as far as we can tell ) on the Mac builds.

The only things that aren’t working are the Other Game links and the Rate links ( naturally as the games aren’t in any stores yet ) and the Pasteboard plugin ( which isn’t a necessity at all ).

Speaking of stores, is the eventual plan to allow for native Mac ( and Win32 ) builds that we could submit to Steam, GOG, Itch.io etc or will we only be able to do Mac/Windows store builds? I’m really hoping for both options

Now onto getting Forever Lost 1 & 2 working. I fear they will be a harder job as they were built on our pre-Serenity framework i.e. fairly messy code.

firemaplegames · July 9, 2015, 11:55pm

Hey Perry!

Yes, using the latest build. 2676

That must be what is happening, the default window is slightly smaller than my monitor.

I’d prefer that not to happen if possible, so I have tried to explicitly set the window to be 1136x726

It seems to be ignoring that though and going with the default.

In the build.settings I set:

defaultViewWidth = 1136,

defaultViewHeight = 726,

and in content in config.lua:

width = 1136,

height = 726

Not sure what else to set. I attached the sample project in the above post if it helps.

You mention that “The default window size is set to be slightly smaller than the size of the monitor it opens on”… Is it possible to get the exact size of that window so I can position my elements?

TIA, and I will keep playing around!

Joe

Perry_Clarke · July 10, 2015, 4:19am

After some testing I realized that defaultViewWidth and defaultViewHeight were a bit hit and miss due to a disagreement with a system API. Things should be much better in the next Daily Build (2677 or later).

The default window is display.pixelWidth x display.pixelHeight but these are calculated based on the screensize and the aspect ratio of the content width and height so there’s something of a chicken and egg situation. Hopefully now that defaultViewWidth and defaultViewHeight actually work things will be more straightforward.

Any thoughts on how to handle different screen sizes are welcome.

Glitch_Games · July 8, 2015, 1:07pm