Android and iOS support
Okay, so technically iOS support existed before, but it was pretty flakey. Now both Android and iOS support exist and it�s easier to make a mobile game than ever. Just set the platform ID to javascript-app-ios or javascript-app-android and your 2D mouse-based desktop game is now a touch-based 2D mobile game.Although you might want to add an orientation attribute to the build target to lock the orientation to landscape or portrait, if you want to prevent the default rotation behavior. See the build file documentation for details!
Lambdas and closures
This is the big one. Previously, if you wanted to pass a function pointer as a parameter, you had to create a function using the full function definition syntax which creates namespace and field pollution when all you need is a simple function. Lambda syntax is similar to JavaScript/C#. The comma-delimited parameter list is in parentheses, followed by a => token, followed by curly braces containing the code. Support for more compact variations (e.g. x => 2 * x) is planned but not currently supported.Closures are also fully supported!
function closureDemo() {
x = 0;
return {
"increment": () => { x++; },
"decrement": () => { x--; },
"get": () => { return x; }
};
}
�
cd = closureDemo();
print(cd["get"]()); // 0
cd["increment"]();
cd["increment"]();
cd["decrement"]();
cd["increment"]();
print(cd["get"]()); // 2
x = 0;
return {
"increment": () => { x++; },
"decrement": () => { x--; },
"get": () => { return x; }
};
}
�
cd = closureDemo();
print(cd["get"]()); // 0
cd["increment"]();
cd["increment"]();
cd["decrement"]();
cd["increment"]();
print(cd["get"]()); // 2
JSON based build file format
The XML file format for the project .build file is now a much lighter-weight JSON file. As a bonus, the constants definitions no longer need to have a type defined because JSON can differentiate between a real boolean and integer from strings that look like booleans and integers.More streamlined Crayon-Native interface (CNI) for libraries
It was a mess and relied on consistent naming and special rules that were not documented anywhere. The library manifest now contains a specific list of functions that it will attempt to load from the native code.Better static analysis for type-related errors
There�s an ongoing project to create a Java/C#-like language that targets the same byte code format as Crayon. Much of the work that has gone into the parser has been with introducing types and performing static analysis based on what is known about an expression�s type.Performance fixes
The most notable change here is that most of the export process was dedicated to parsing the raw interpreter and library code and transpiling it to the target platform every time you exported a project to a given platform. No more! All of this has been done beforehand and the final transpiled assets are bundled with the libraries and compiler so the only thing that compiles is the code that you wrote.Raw Strings
You can put a @ in front of a string to de-activate escape sequences. If you�re writing a quick script that does file IO and need to directly reference Windows file paths, this is fairly useful.More libraries
Now that Crayon is starting to expand out from just the games realm, a few notable gaps in a standard programming language have been filled with a healthy addition to the built-in libraries.- CrayonUnit
A unit testing library. This allows you to define any class that extends a specific Test base class and reflection will run all argument-less methods as tests. Includes a comprehensive set of functions for asserting actual and expected values. For a sample, there is a UnitTest project in the Tests/ directory in the source tree. - DateTime
Having human-readable timestamps instead of unix timestamps could be useful from time to time. - Dispatcher
This streamlines and centralizes a way to create timed one-time and repeating callbacks or asynchronous callbacks. This integrates with the Game library, but also the Nori library (mentioned below) as well. Many of the libraries have an asynchronous nature with methods that create some sort of asynchronous process and return a status object that you have to poll to detect completion. Many of these still exist, but will leverage this library in the future to be converted to an asynchronous form that takes a callback. For example, the Http library�s .sendAsync() now consumes a function pointer for a callback. - Nori (experimental)
This is a UI library for creating typical client-side user interfaces that are not Game oriented (read: checkboxes and scrollbars). This is still in the experimental phase but is available for tinkering. Currently this is only supported in the runtime and when you export to JavaScript, Android, iOS, and C# platforms, but Java and Python support are planned. - NoriXml (experimental)
In addition to Nori, this library allows you to quickly define complicated UI�s with a concise XML string in the style of XAML or HTML. - TextEncoding
Converting from bytes to strings and vice-versa are occasionally important. The new text encoding library supports all applicable Endian and BOM permutations of UTF8, UTF16, UTF32, ASCII, and ISO-8859-1.
Bug fixes
About a year�s worth. Too many to list. So I�ve picked the most embarrassing to showcase it here:Running a program from a directory that has a space in the name will cause the runtime to not be able to find the byte code file.
New Version Numbering System
You might have noticed that the version numbering system has changed. The last version was 0.2.0 and the source history refers to this version as 0.2.1 until a few weeks ago when it was suddenly changed to 2.1.0.The diff between 0.1.7 and 0.2.0 was basically a whole rewrite of the language. There were no libraries in 0.1.x, just built-in functions that did game-related things. File imports ran like C-style #includes. This was basically an entirely different language, which deserves a major version increment. The differences between 0.2.0 and 0.2.1 were very significant but not as significant as 0.1.7 to 0.2.0 and will set a precedent for what sort of size of changes constitute a version increase. As this took a year, Iââ?¬â?¢d like to make much smaller and more frequent releases, so Iââ?¬â?¢ve shifted the version numbers to the left. 0.1.7 and 0.2.0 were really a 1.7 and 2.0 in spirit. If a large change occurs to the language, Iââ?¬â?¢ll increment 2.1.x to 2.2.x, but for the scale of changes that I want to start doing on a monthly or bimonthly (every 2 months) basis, I can increment the build component of the version number without 令åâ??Å?-style pomp and circumstance.
I hope you enjoy the new version! Please reach out to me (@blakeohare or @crayonlang on Twitter) let me know if you run into any issues or have any language requests. Or just want to show off what you�ve created.