Friday, June 28, 2013

I recently released an educational game where you play with logic gates. The inspiration for the game came from a JavaScript book that didn't even bother covering logical operations. Logic operations are used to manipulate bytes at the per-bit level making them very useful for optimizing the memory-footprint of data structures. Now that everyone has multiple gigabytes of RAM in their computers, optimizing memory is not as high of priority anymore even if it is fairly easy to do. Instead of preaching about this, I am instead going to give an example of its use and the non-boolean-logic alternative.

For a number of games under development, I have a skill system where players select their bonus skills. Many of the skills have prerequisites. Each skill gets assigned a bit within an integer (if there were more than 32 bits, more than one integer could be used, though for me this isn't an issue as skills are grouped into set that contain 16 skills so only 16 bits are needed). Each skill record has an integer for prerequisites. The character class has an integer for each skill set indicating what skills are known. To see if a skill can be learned, a simple logical AND can be done on the prerequisite and the characters skill set. If the result equals the prerequisite, the skill can be learned.

This can be done without binary logic operators by using an array of booleans. Checking prerequisites the becomes a bit more complicated. First, a meets-prerequisites flag is set to true. A for loop looping through the prerequisites array checks if the corresponding skill flag is set. If it is set, the array of skills in the character sheet then gets checked. If the character sheet skill is false, the meets-prerequisites flag is set to false and the for loop is exited.

As many languages use integers to represent Boolean variables, this is a potential waste of 31 bits. In our example, this would be a memory increase of 16 times the amount. Some compilers have optimizations for memory use in which case the compressing of the bits into a single integer will be done by the compiler, but even in that case the compiler will still have to use the looping code for checking prerequisites with the rather significant speed difference as a result. Of course, in addition to having lots of memory, computers also are very fast now so such concerns can be overlooked. But as writing the code to be efficient in the first place is so easy there really is no excuse for such a waste of memory and CPU cycles.

Friday, June 14, 2013

I have mixed feelings on the new languages that compile to JavaScript such as Dart and CoffeeScript. The problem with these languages is that by producing JavaScript there are people who seem to think they are creating JavaScript projects when they are not. It is possible to take the JavaScript output and edit it as if it were a JavaScript program, but unless those changes are also done in the language source code, those changes are either not part of the project or make the project much harder to maintain. This effectively means that once you start a project in one of these languages you pretty much have to stick with the language. This is not necessarily a bad thing but it does reduce the number of people who can use the source code.

Dart is a bit different from other languages that compile to JavaScript. The compiling to JavaScript is a backwards-compatibility feature designed to allow programs written in Dart to work on browsers that do not support the Dart language. The idea is that eventually browsers will start supporting Dart as one of their script-tag languages. The dart programs then would be run using their native JIT-compiler resulting in better performance. Right now there are not any browsers that support Dart, but Chrome is going to soon as the Dart SDK includes a beta-build of Chrome that has Dart support.

When Dart was first released, I briefly looked at the language but decided I would wait for the 1.0 release before trying it. A Google IO presentation on the language got my curiosity peaked and when I discovered StageXL (which like the CreateJS library is modelled after the Flash API that I am familiar with) I decided that the JavaScript issues I was having with CreateJS might be solved if I used Dart and StageXL. This in fact was the case so I have decided that I will be using Dart to port my Ultimate Retro Project to HTML5.

The Dart language is a proper Object-Oriented language with optional type support. All the type-related issues I have with JavaScript are gone and having proper classes makes working with code great. My favourite feature surprisingly was the switch statement. Dart requires that each case statement within the switch block has a break, continue or return statement making the issue of accidentally forgetting a break statement a thing of the past. This is one of my pet-peeves with all the C-like languages so discovering this feature made my day.

While I am still new to the Dart language, I suspect that by the end of the Ultimate Retro Project port I will be close to an expert with Dart. If like me you are coming to JavaScript from real programming languages, Dart may be the solution. I will be continuing my discussion of Dart as I continue to work on my port, but as this is a side project I am not sure how quick the work will proceed. Perhaps by the end of the project I will have changed my mind, but my current impressions of Dart are exceedingly positive so there will have to be major issues to make me change my mind about the language.

About Me

I am a programmer who can program in a large variety of programming
languages (including some Assembly Language) but am currently focused
on interactive web development which means my current focus is on Flash
and JavaScript. When I am not programming for clients, I am working on my
game site.