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!
Closures are also fully supported!
JSON based build file formatThe 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 librariesIt 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 errorsThere’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 fixesThe 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 StringsYou 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 librariesNow 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.
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.
Having human-readable timestamps instead of unix timestamps could be useful from time to time.
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)
- 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.
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 fixesAbout 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 SystemYou 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.