luxe alpha-2.0+0010 focus sheet

sign up sign in

It's time to start off the second alpha focus sheet! This one is going to be named after....

Double Zero One Zero™ games

This duo are a team from Skövde, Sweden who jumped on board with luxe at a very early stage and are consistently doing great work with and for the engine.

Not just testing and finding bugs - but for taking the risk in believing that I wasn't going to let them down (yet? hah!) and pursuing a full time, commercially focused product using luxe. This may seem like a normal every day thing for a framework, but keep in mind that they did this about a year ago - months and months before it was close to what it is now, and well before it was released as an alpha.

They are making The Westport Independent, that they have been showing at expos around Sweden and at Comicon and other various events, waving the luxe flag before anybody could look it up online.

Source: this tweet

All in all, they are doing an excellent job on the game so far, even Rock Paper Shotgun has it listed of their best PC games of 2015 to look forward to. They aren't the only ones mentioning the game before either.

Be sure to follow the team on their twitter, and visit their home page for more info.


It's been mentioned already, work has been happening on it for some time, but alpha-2.0+0010 is about sorting out the asset management stuff, making sure resources are easy to manage and ensuring that windowing events are consistent, and easy to handle.

These things were all gutted around the time snow was being implemented into luxe as the backend - this left some portions of the systems incomplete, and some disconnected from the backend.

This pass during the focus sheet will alleviate a lot of the higher level problems, to bring the luxe API on par with the features within snow already, and to address some of the pain points in releasing something that meets user expectations.

Important notes on upcoming changes

As much as can be avoided, all changes during the alpha tend to be mainly semantic - i.e a quick search/replace - and the changes are clearly marked on the repo.

However, changes that are not as easy to follow from a user perspective are behavioral changes, things that need to change to accomodate a better api or workflow, or finalize some aspect of the engine that wasn't in place yet. These type of changes will impact current code and potentially create confusion if the notes about them are missed, because the code from before might still run, but the results are different.

A couple of the changes during alpha-2.0 are like this, regarding the font id's and behaviors of the Luxe.load* functions - which I will be sure to document in commit messages and post about in detail.

These won't be TOO drastic all told - I just want people to be aware that during the alpha period and working from repo, that this is bound to happen and I'll do my best to keep everyone on the same page.

Getting involved

As before, the following information is important to understand the focus sheet process :
focus sheets: how they work
alpha-1.0+parrott focus sheet

I won't reiterate the processes, but read the above links, and be sure to weigh in on the discussion, and pick tasks you would like to get involved with on this github issue.

Last time we saw quite a few contributions, especially for a focus sheet with a lot more lower level and complex stuff, so don't feel like you can't get involved. We are always happy to give you a hand in understanding the work involved, so you can contribute.


As listed above, the discussion goes here as well as the community chat for realtime discussions. Always interested in hearing feedback, so be sure to drop by.

alpha-2.0 sample

Each named alpha focus has a simple sample to address some of the frequently asked questions that aren't written as guides (yet) or don't even fit a guide - just a fun and simple practical code example to learn from.

Use the mouse in the menu,
Press escape in the "game" state to pause,
Press M or Escape from pause menu
click first to enable key input in the iframe

The "game" state is just the snow/particles.
Simpler code is better to demonstrate the goals (described below).

edit: it seems safari is breaking when trying to go back to the menu! will fix.

Click to run sample

The above example can be found inside the repo at samples/alphas/2_0_0010.

While this isn't documentation of any kind for the new text features from alpha-1.0, it does use them to add outlines and glows and use the SDF text rendering for the custom font, to show some of that off. There are some comments about in the code, though. Guides specific to the text features will be done when they are considered a little more final, as mentioned later below, there are some things to resolve first.

Quite a few users had trouble grappling with the state system, and how it could be used for separating "screens" like a menu <-> game transition. This sample demonstrates that in a plain way, as well as demonstrates another type of example for the transient states.

In this example - A menu is a modal state, it is set and is entered. When a state is entered, the previous state is left. Like, a Game state - also a modal state, also set and entered, leaving the menu state. In our example, these modal states are mutually exclusive, you can't have a Menu and Game state active at once - this is what makes them 'modal' to luxe states.

Now, in the Game state, we might want other states to co-exist, i.e stacked on top of the game state. The simplest example of this is a pause state. A pause state is enabled, allowing it to exist at the same time as the Game state. When unpausing, the pause state is disabled. These type of states can be considered transient/stacked, because they are often temporary and are layered on top of the base modal state. A base state is not required, but it helps to think of it this way.

A hypothetical example - A shoot-em-up, the player can die - but be resurrected by a co-op player. alive OR dead - modal, exclusive states. state.set('dead'); would leave the alive state behind. Now imagine the player can be stunned, this is a transient (temporary) state, and only disables the player input. This state is stacked on top of the base 'alive' state, and can influence the gameplay. Power ups, buffs, abilities, lots of stuff can be considered a stackable state!

Hopefully the sample shows the basics, but given that they are quite flexible it's up to your imagination to fit them to your needs.

Recent updates


For the alpha sample, I got frustrated by a few things in the Particles and found a whole boat load of problems (which I sort of expected to be there, as this code was ported from older js projects) but during the transition to Entity/Component based setup - some things got broken and stuff was updating twice, some stuff was ignored - it was quite a mess.

I spent a short bit of time cleaning the heck out of it, fixing a lot of bugs, making the behavior more flexible when the pool cap is reached, removing any allocations when spawning particles from the cache, and made a bunch of minor tweaks around the code base which means overall performance will be better in luxe, too.

They are by no means done yet, but it's significantly better, and perform a whole lot better than they did.


alpha-1.0 included a bunch of text updates, some of which has minor issues - specifically the way text size was calculated from "outside" (drawing was fine), this means that when trying to use width_of to calculate the bounds of a Text item, it would return something unexpected.

This has largely been resolved for horizontal sizes, and depending on the font won't be a problem for vertical sizing, but some fonts have interesting metrics (like the one in the sample) so you may find the bounds not to be as tight fitting when using Text.point_inside,

Oh, and Text.point_inside was just returning false, now it only does that if the point is in fact outside :p

There are still things to be addressed, but overall improved.


arm64 and other architectures
From Feb 1 2015, all iOS submissions to the store require that arm64 architecture is included in your build. HXCPP had already taken care of the c++ part thankfully, but I have completely reworked the latest version of snow and flow to automatically build a fat architecture binary for you, so your apps automatically include the widest range of devices (and rely on the default "standard architectures" from Xcode).

I also built snow as a fat library, for armv6, armv7, armv7s, arm64, sim i386, and sim x86_64 - so you can link to the singular libsnow.ios.a and it will always have a valid architecture. This simplifies things a lot, and is included in the flow build toolchain, so automatically your builds handle this, and of course is configurable/flexible.

What this means in practice : The Xcode "Architectures" node is used directly to build your project - the project template has removed any hardcoded values, and relies solely on what Apple/Xcode version determines to be the standard. For example, armv6 is not even supported by Xcode, so the standard defaults to arm64 and armv7 now.

This requires regenerating your xcode project, with flow build ios --xcode-project. If you have made modifications to your project, and want to persist them, let me know on the chat I can tell you exactly which values to edit to make this work the same.

icons and images

For snow and luxe, I generated new launch images and icons for iOS. This covers all the supported targets now, where previously only iOS 7/8 were covered.

You might want to check out, which has templates to generate icons from Photoshop. I also used to generate the launch images, which is a handy tool.

In luxe/flow/, you will find a Contents.json that uses the appicontemplate version, and in snow/flow/ you will find a normal icon size based one - I made them different for examples.

There are many tools to automate these for you, just be sure to check in Xcode what icons/launch images your app requires for your targeted versions.

App store submissions

This means that all ticks are green out of the box, from building to submission, there are no warnings or errors. Some users are already testings apps through Test Flight, and will submit to the store for review shortly - any issues that arise will be addressed but it's unlikely there will be any problems at this time.

Other news

From the community, anissen has been storing a list of snowkit related links, which you may find useful!

snow native sdk

The native sdk is taking shape quite nicely, I have already used it to write some quick proof of concepts, for example in a very short time (~2 hours?) I was able to add clipboard copy paste, native window embedded (mac) Game Center, and load a custom native window directly from Xcode interface builder on Mac.

The platform that seemed to have the most annoyance in store for it was Android, but with similar easy, I have successfully written an open url plugin with the Haxe/Java target, directly in haxe code, built a jar file from it, dropped it into my project libs/ folder and it worked with no problems. I also wrote the first pass of the JNI interface, it's REALLY easy to use, and automatic - all from haxe as well. This means that I can call Java from haxe, and call haxe from Java too. The in-project custom Java code works the same way too.

I won't ruin any surprises here, but it's not long until it's properly usable for libraries across platforms, and things like Game Center/Video playback/Play Services/etc are a neat isolated plugin.


focus sheet


change logs

I have been writing a more consistent way to find the updates, in a predictable and convenient link - but in the mean time if you're wondering what's changing, find the commit log on the git repo

Finally, if you haven't yet, read the welcome to 2015 with some news and announcements here.