Processing.js – Irregular Apocalypse

Surprise

Just as aliens seek to strike suddenly and disappear before X-COM arrives, so to does this blog arise inexorably from the deeps to... do something and go... somewhere before... Well, perhaps that wasn't such an apt comparison after all.

Nonetheless, it returns with tardy tidings of the past and elusive glimpses of the future.

The Light of Ancient Days: Release 0.7

0.7 was not particularly exciting. The only real coding I did was for ticket #156, which converted the contents of a file into a byte array (actually an array of numbers). This effectively piggy-backed off of the preexisting ajax helper function, which returned the contents of a file as a string. From there each char was converted into a number via String::charCodeAt().

• #156 loadBytes()

From release 0.6 one may recall how I noticed a little problem concerning the automatic conversion of character arguments into numbers, making it very difficult to pass chars into functions.

Not able to bring myself to let it pass, I took a crack at it. Indeed, the fix seemed simple: remove these two lines from the parser:
// Force characters-as-bytes to work.
aCode = aCode.replace(/('(.){1}')/g, "$1.charCodeAt(0)");
With those lines removed, the tests came back green and it seemed that particular beast was on its way into the cage. But you know what they say about things that seems too easy.

Corban was quick to show that we still needed the auto-conversion facility and if something was to be done, removing those two lines was definitely not the end of the story. Within six hours, he'd come up with a much craftier solution: a Char class. Now, functions could check if an argument was of type Char and act accordingly. Problem solved!

• #312 Char arguments indistinguishable from numbers

Along the way, Anna poked me to take a look at ticket #360, noting that in this example the yellow letters were appearing white. This was due to the char-to-int conversion issue, and when that was solved, #360 was resolved without any additional work.

• #360 basic letters example displays wrong info

All's well that ends well, yes?

A More Recent Note: Release 0.8

The ride on the 0.8 line started innocently enough with the conversion of some visual tests into unit tests. Two failing tests for binary() had to be corrected. One was caused from an incorrect comparison value (Pjs was otherwise returning the right value). The second error was fixed by converting binary() to detect objects of type Char. Along the way boolean() was changed to throw errors on invalid arguments, instead of returning undefined.

• #414 Converting binary() tests from visual to unit causes two to fail.
• #412 Throw errors on invalid arguments in max() and min().
• #413 Convert visual tests to unit tests.

There was a short stop at ticket #269, concerning whether or not a cloned ArrayList should contain deep copies of items contained in the original. Processing uses Java's ArrayList, which does not deep copy. Since Pjs' ArrayList already conformed to this, the ticket was resolved as invalid.

• #269 ArrayList.clone does not deep copy

A rather longer stop was for printMatrix(). printMatrix() outputs the current transformation matrix to the console. Work started in 0.7 but at the time it only worked when Pjs was working in a 3D context. Why? Because Pjs handles the 3D matrix itself, courtesy of PMatrix3D, and so the values of the 3D transformation matrix were readily accessible. When working in the 2D context, Pjs used canvas' internal matrix. This worked very well, except there was no way to retrieve the values of canvas' transformation matrix, and so there was nothing for printMatrix() to print.

• #174 printMatrix()

printMatrix() was ultimately made ready for 0.8, thanks to work on a new and wonderful class...

PMatrix2D

During a phone conference in early March I proposed the creation of PMatrix2D to get printMatrix() going. This meant replicating everything canvas already did just to be able to get the transformation matrix values. I was hoping I was missing something and that there was another, easier way, but apparently there was not. At the end of March the green light was given to cobble together PMatrix2D. Maybe the canvas API will be expanded in the future to allow the values to be retrieved.

Choosing where to start implementing PMatrix2D for release 0.8 was easy: I coded just what was needed to convert the existing PMatrix3D and PMatrix3DStack tests and examples into their 2D equivalents.

Rather than creating a new PMatrix2DStack class, it was easier to transform PMatrix3DStack into PMatrixStack which handled both 2D and 3D matrices.

• #439 Implement PMatrix2DStack
• #428 Implement PMatrix2D::apply(), PMatrix2D::skewX(), and PMatrix2D::skewY()
• #424 Implement Pmatrix2D::set().
• #432 Implement PMatrix2D constructors.
• #437 Implement PMatrix2D::print().
• #431 Implement Pmatrix2D::reset().

Toward Release 0.9 and 1.0

Things seem pretty clear cut from here on in. For 0.9 I hope to finish off implementing the rest of PMatrix2D's functions. 1.0 will aim to get Pjs actually using it.