Striving For 3D

This week I made some progress towards towards coding 3D rendering!

I remember when I was in my early teens and a bit bored on holidays at my grandparents, trying to code an image of a road with 1-point perspective. I asked my grandfather to show me how to load the version of BASIC he had on his ancient Amstrad PC (it was GW-BASIC).

Back then, I didn’t get the basic idea of 3D perspective, but it isn’t actually very difficult: if objects are in a space in front of you where X is across, Y up and Z forward (and you are at 0, 0, 0), dividing their X and Y coordinates by the Z coordinate will create the necessary distortion.

(It seems that, typically, a small number is added to the Z component first to reduce the strength of the distortion, otherwise things get madly stretched off screen when the Z approaches zero. I bumped into that problem when making my Pink Sparks demo the other week.)

The real issue is that, to keep the code organised, manipulations of 3D data are best done using matrices. This way, a command can become data. Instead of running some code for each manipulation (such as rotating or resizing a shape), you have one piece of code that obeys a data representation of the desired command. This data is a transformation matrix.

You can then conveniently store these commands, for example the operations “Rotate by 30 degrees around the X axis, mirror in a plane with the same orientation as the X-Z plane but 5 units above it, resize to 80% scale” could be represented as three 3×3 matrices.

If you use homogenous coordinates, which are like ordinary coordinates but containing an extra element by which all the others are divided, then the Z-divide for perspective correction can be represented by a matrix which copies the Z value into that extra, dividing element (typically called W).

But enough of my attempts at understanding linear algebra! Let’s talk implementation details.

As usual, I made my demos in JavaScript. Being able to trivially publish stuff on the web, and send no-hassle links to friends or relatives, makes this the most attractive choice.

However, I decided not to use WebGL, the graphics-card-accelerated renderer that now comes with all browsers. I’ve been having a good time with WebGL tutorials, but connecting up buffers and typed arrays introduces more places to make a mistake and lose time debugging. I’ll return to WebGL someday because the raw power, the basic idea of shader language, and the depth-buffer and texture manipulation capabilities all attract me deeply. But for now there was, again, a clear best option: HTML5 Canvas.

This is a graphics API with higher-level features such as line-drawing commands – precisely what I wanted for my demos!

The first one I made demonstrated linear transformations in two dimensions. As you can see if you click here, these all operate around the origin (the centre point where the two axes meet), or to put it another way they preserve the origin. I used setInterval(..) to make the animation – not a good choice as we’ll see in a sec.

Then, I made a demo of affine transformations – a larger category which includes the linear transformations, as well as translations (i.e. just moving shapes around with no distortion) and mixtures of linear transforms and translations. To show the way that affine transformations can occur around any point, I added some quick interactivity to let the user set the centre point and choose a transformation. I also used matrix multiplication to iteratively apply the same transformation to my shape.

Affine transformations -area-preserving squash, in this case, which incidentally describes hyperbolic curves.

Around here I started thinking of possibilities for game graphics:

  • a stick person who squashes a bit before and after jumping
  • a stick person who leans back before and at the end of a run (wind-up and breaking), done with a shear transformation
  • explosions setting off shockwaves that pass through numerous characters on a the screen, squashing them in its direction as it does so
  • interactive objects that cause the player character to change size, Alice In Wonderland-style

(I was definitely channeling some old Flash games from my teens… stickdeath.com, anyone? I think that was the URL.)

I’ll get back to these ideas in a second to discuss what I think would actually be the hard part about making them…

My final demo was in actual 3D. Still working off Greg Tavarre’s nice WebGL tutorials (though NOT following his convention for ordering matrix elements in a 1D array), I implemented homogenous coordinates and a Z-divide. My first attempt had an annoying error in the Y-axis. Turned out everything was working, I had just put my transformation matrices in the wrong order so the up and down bobbing was happening after perspective had been applied!

That’s what it looks like! Click here to see it hosted on my site.

If you look at the working demo, you may see the star seemingly spinning the wrong way, despite the perspective cues, a classic illusion. I think this is just a general fault of wireframe graphics.

BTW The animation here is handled with the preferred modern JS technique requestAnimationFrame(..).

All this demo-making begs the question: could anything here become reusable software?

The matrix stuff is eminently reusable. To make it convenient, I would need to make an engine or interface allowing a programmer to load geometrical data, transform it and display it, through well-documented, user-friendly functions, while hiding inner workings.

So the last thing I did this week was some design work on a personal 3D library. Eventually this should be in WebGL, but to test the design I might do it in Canvas and maybe just with wireframes. The crucial point is that geometry exists in all these different spaces before it’s fully processed:

  • object space, that is, vertexes positioned relative to the centre of the object they represent
  • world space, so now that object is positioned in a world
  • camera space, now the world is spun around to face the camera
  • screen space, now anything visible is referred to by the position it takes up on the screen (in this case, the rectangular Canvas on a webpage)

All of these have potential for interesting experimentation. What exactly defines an object is an open question – can an object be composed of others, and in what ways might those sub-objects be transformed? Once in camera space, what are the possibilities for fish-eye effects or non-Euclidean geometry? And of course screen space is the traditional domain of the visual artist, the flat sheet.

Well that’s some big talk on the back of a spinning star. Baby steps though!

7 Days

Last Monday I decided I would work on a different coding-related skill each day, for a week. These days I’m familiar enough with my own brain to know that swapping subject areas and deep-diving into topics suit my attentional style. Because motivation can be hard to come by when jobhunting and self-studying during pandemic restrictions, I thought I’d stimulate myself with novelty. It might even help me get psyched up to work on longer-term ambitions, like releasing my ritual Android app Candle Shrine, and also making a portfolio website.

Day 1 – C

On Monday I worked on C programming – an area I haven’t touched since 1999, ha! Yes as a kid I did a summer course which touched on some C. Anyhow, the aim was to set up the compiler and get console input and output. I used a build of Tiny C Compiler nabbed from the Tiny C Games bundle. My project is a simulation of life as experienced by our family cat, Goldie. Actually I’m pretty pleased with this, my sister played it through and enjoyed it. I was inspired by Robert Yang’s concept of “local level design“- a design aesthetic celebrating small-scale social meanings rather than top-down formalism. (This suited me because I don’t yet know enough C to write anything other than this ladder of if statements. Still, it works!)

Day 2 – Linux

The next mini-project was Linux shell commands. I used VirtualBox to dip my toes in -it lets you run any distro on emulated hardware, from a Windows desktop. It nearly locked up on my a couple of times, but in fairness my computer was running two OSes at once so I forgave it. It never fully crashed.

I’d hoped to get into shell scripting, which is the power user technique of saving listings of shell commands (a shell being a console for directly running programs or OS utilities, etc. – like the ol’ Command Prompt in Windows) as text files to be invoked as, effectively, little programs.

But all I had time for was to learn about 20 standard shell commands. However, I really liked this stuff. I can see why there’s a stereotype that devs use Linux. It’s rather satisfying to install stuff, edit files, and set up the file system via typed commands and not all that intimidating either.

Day 3 – Pink Sparks

See it in action here

This one was fun. I made a 3D particle demo – a spinning cube made of flying pink sparks. My focus here was to prove I could make a simple particle system, which indeed wasn’t hard, cribbing off Jonas Wagner’s Chaotic Particles and leveraging the extremely handy Canvas feature in HTML5. I also wanted to do 3D perspective, which was hard. However here I used the simplest possible version, a bare z-divide where x and y coordinates are divided by distance from the viewer. The proper way to do this involves matrices and transforms, but I’m not there yet.

If I get back to this the two things I’ll do are change it to defining line-shaped sources of sparks rather than point-shaped, and make some nicer data than a cube, like say a chunky letter ‘K’. This wouldn’t be particularly hard. Making a display of my initial fits with my interest in what I call ceremonial coding which I believe will be an emerging cultural field in years to come. As life goes online, we’re already finding the need to program and design software for celebrations and community rituals – an example being my graduation from my computer science course, which is being held on Zoom. I am certain that techniques from game design and aesthetics from digital culture will be important to create spiritual meanings and affirmations of identity on computers. My upcoming ritual app for Android phones expresses this conviction.

Again, Robert Yang’s post is very close to the spirit of this: “What if we made small levels or games as gifts, as tokens, as mementos?”

Day 4 – Huffman Coding

I hit a roadblock on Thursday. Huffman coding compresses text, by taking advantage of the fact that certain symbols (for example, ‘z’) occur far less often than others. To make a Java app implementing this was a meaty challenge, requiring binary buffer manipulations, a binary tree, sorting and file I/O. Still should have been achievable – but I let myself down by not rigorously figuring out the data representations at the start. This meant I threw away work, for example figuring out how to flatten the tree into an array and save that to disk, only to twig that the naive representation I’d used created a file far bigger than the original text file.

Though I was working from a textbook with an understandable description of the Huffman coding technique, that was nowhere near enough. I still needed to design my program and I failed to.

So I ran out of motivation as poor design decisions kept bubbling up. This was a stinger and a reminder that no project is too small to require the pencil-and-paper stage. On the plus side, I did implement a tree with saving and loading to disk, plus text analysis.

Hopefully I can reuse these if I come back to this. It’s a fun challenge, particularly the raw binary stuff and the tree flattening (although I don’t know yet if I want to store the tree in my compressed file, I think probably just the symbol table needed to restore the original.)

Day 5 – WebGL Black Triangle

In the spirit of Jay Barnson’s Black Triangles – though I’m sure it’s a million times easier these days!

Now this was pure fun. I used a tutorial to learn how to display graphics on a webpage using WebGL. I… frankly love the feel of OpenGL Shader Language. The idea of using a harshly constrained programming language to express some low-level color or geometry calculations, which is then compiled and run on your graphics card so you can feed it astronomical amounts of data for ultra-fast processing, is so satisfying. (Actually, especially the compilation process, and the narkiness of the parser where for example 1 is different to 1.0… it feels like you’ve loaded a weapon when you’ve successfully compiled at last.) I love graphical magic, but previously have been doing it at several removes, using wrappers on wrappers like Processing. I will definitely be doing more of this.

Day 6 – RESTful API

Another failure! I wanted to make a RESTful API demo as a bullet point on my CV, and host it for free on Heroku. But although I did some good revision on API design, when I got into implementation I totally got tangled up in trying to get libraries to work. Blehh!

I wanted my system to be standards-compliant so I tried using libraries that’d let me use JSON:API instead of raw JSON, which some people say is not good for APIs as it has no standard way to include hyperlinks which are, in fairness, central to the concept of REST (i.e. that instead of the client knowing to use certain hardcoded URLs, each response from the API includes fresh hyperlinks that the client can choose to follow).

But I got stuck when the examples for the library I chose wouldn’t compile because they required a new version of a build tool, Gradle, and despite trying some things off forums my IDE failed repeatedly to automatically install this.

They don’t call it “dependency heaven“!

If I get back to this I’ll use the build tooling I had working already for school projects. Life’s too short!

I wonder if the area of web services – so essential, stolid, bland – might be a natural home for rather pedantic personalities. The type who would make a typology of all things and publish it as a web standard. In any case, wading through some comments and blog posts and Wikipedia pages gave me a stronger understanding of state in web services than I had before.

Day 7 – Pathfinding in JS

Like the previous one, this project spun off into piles of research. But it’s all valuable stuff, I revised a lot of CSS and particularly the grid system, and got deep into JavaScript using this quite good book.

My plan was to implement a classic pathfinding algorithm, Dijkstra’s algorithm. But I wanted to have it so a little monster would chase your cursor around elements on a webpage! Well, as usual, I should’ve thought this through more. The fact is, web page elements are not intended to be processed as 2D shapes. HTML is semantic – web content is structured and manipulated as elements like paragraphs, headings, links that have meaningful relationships in the context of the document itself – with the final presentation of these elements done on the fly according to the user’s needs.

Anyway… my point is, I had to compromise to get this going. My original vision was of words arrayed around the page randomly, at different sizes, with a monster sprite threading his way around them.

My solution doesn’t have the words, just boring blocks, and though I think I could do words at a fixed size, having splashy words in different size could be quite a hassle.

As you can see, the paths go through diagonal choke points, something to fix

Nor did I get around to the monster although I have the sprite for when I do:

Heheheheheh.

But the thing that worked well for this mini-project was: web standards! In particular, I made the excellent decision not to hack CSS positioning from JS, but instead take the time to revise the CSS Grid system. Which, as you might imagine from the name, was actually perfect for this use case. Those numbered cells above are arranged by Grid.

Conclusion

That was fun. I might even do it again!

Eleven Favourite Quotes from “Permacomputing”

Apologies for the clickbait format, which is hardly in keeping with the concepts I’ve been absorbing from Ville-Matias “Viznut” Heikkil√§’s remarkable recent article. Think of it not as a push for attention on an ephemeral feed, but respectfully memorialising another’s inspiring vision here on my own site.

Today I will summarise some of that piece’s most remarkable insights for you. I’ll react to quotes, picked for their awesomeness, in turn.

(My WordPress stats suggest that most visitors are here for the jazz content. If that’s you, you are most welcome to stick to that stuff. But consider reading on to ponder alternative visions of the internet and entertainment technology that makes this very blog possible.)

BTW, Viznut is not writing in his first language, and uses “would” where “should” might be more idiomatic, when discussing idealistic futures.

Let’s go!

1. Computers have been failing their utopian expectations. Instead of amplifying the users’ intelligence, they rather amplify their stupidity. Instead of making it possible to scale down the resource requirements, the have instead become a major part of the problem. Instead of making the world more comprehensible, they rather add to its incomprehensibility.

Pessimistic, yet I agree. “Amplifying stupidity” is quite precisely what Twitter does, intentionally spreading wildfires of outrage through our nerves and networks. ICT is projected to take up between 8% and 20% of all energy worldwide by 2030. And incomprehensibility… Jesus. I feel so strongly about how non-technical folk (my parents, for a start) are made fearful and humiliated by corporate tech like antivirus software, operating systems, bank and telecoms billing, touchscreen interfaces, and so on. Yet technologists (I’m one myself) always blindly return to their comfort zone: abstractions, services, always-on internet, new languages and upgrades and frameworks. “Increased controllability and resource use.” And increased incomprehensibility, infantilisation and frustration for everyone else.

Am I being hypocritical? Totally. I depend on myriad frameworks and the seemingly-invisible, actually aggressively-corporate-sponsored development work that keeps big platforms, and our whole civilisation, going. The point is not to deny that but rather observe it and judge it from a dispassionate viewpoint, asking what do we really need, in the long term?

2. Permaculture trusts in human ingenuity in finding clever hacks for turning problems into solutions, competition into co-operation, waste into resources. Very much the same kind of creative thinking I appreciate in computer hacking.

So, Viznut turns to permaculture, a gardening philosophy. Actually, in my long list of article ideas for this site, is one about how my grandfather manages his large garden, despite being in his mid-80s. The point was that due to an inherent rightness in his methods and tools, and a humble reliance on nature to do the work, his garden is still productive and pleasant no matter how physically weak he gets. His work is opportunistic and adaptive. Son-in-law visiting? Make him sharpen my tools. Grandson loafing about the house? Get him to plant lettuces, or pull down vines. Can’t walk much? Put a trailer on the lawnmower. Even when sinking into decay, everything still works, just at a lower level. His old greenhouse, lean-tos and cages are merely waiting for when he has the energy to put one or the other to use.

What has that to do with staring at a screen and tapping away at a keyboard?

3. Any community that uses a technology should develop a deep relationship to it. Instead of being framed for specific applications, the technology would be allowed to freely connect and grow roots to all kinds of areas of human and non-human life.

Could technology – or one or a few specific, locally chosen technologies – fit into our lives like a well-stewarded garden? Like leaving a garden to grow in rain and sun, we would let it do what it’s good at. When resources were at hand we would apply them, if not we could wait. We could deploy it in new ways all the time, like using a garden for meals, sunbathing, athletics, meditation, crafting, cooking, drawing, retreat, nature watching and so on. Even with minimal maintenance it would function, while occasional bouts of serious group work would provide exercise, catharsis and new directions.

Dream on, Kevin.

But I’m basing these ideas off a real scene, as Viznut does with the demoscene. Since about 12 or 13 I’ve been interested in Quake modding, a scene in which enthusiasts create new levels, monster types, versions and toolchains for the first person shooter game, Quake (1996, id Software). There’s something more than a little amazing about how this online community has grown while nurturing a set of powerful, well-maintained software tools, and releasing hundreds of fun things to play. Which also provides a strong, common base for engineering experiments. All with no money changing hands!! Just people doing things out of pleasure and dedication, making the world better.

The DOOM community, based around a similar but earlier and simpler game, is if anything even more broadly creative and supportive.

I won’t go on – I think you get how I feel about this.

4. At times of low energy, both hardware and software would prefer to scale down…. At these time, people would prefer to do something else than interact with computers.

This is where the radicalism comes in. Viznut doesn’t believe our current civilisation can continue. His is a worldview directly in opposition to values we absorb in school, college courses, news, and so on. (For example, in my one-year computer science course, it was absolutely unquestioned that e.g. ever-increasing virtualisation and cloud storage, or working in a monopolistic platform giant, were desirable things.) None of my close friends, who work in engineering or finance, would find it digestible. I haven’t read up myself on degrowth ideologies although I did learn a lot from the fearsomely knowledgeable Dutchman Kris De Decker who runs Low Tech Magazine. But the highly unpalatable idea is that we’ll all have to stop depending on things we’re used to: unlimited flashy content, new phones and personal gadgets, and quite a lot more; because they take too much energy which ruins the planet.

5. People would be aware of where their data is physically located and prefer to have local copies of anything they consider important.

There are countless ways, most of them still undiscovered, to make low and moderate data complexities look good…. For extreme realism, perfection, detail and sharpness, people would prefer to look at nature.

My quick take on this is I don’t know. I don’t know if Viznut is right. However, my intuition says yes, it is healthier to check out some bark patterns, dewdrops and butterflies in your local park, than clicking through 1080p videos on YT. And that yes, something doesn’t add up when Google offers to host gigs and gigs of my data forever on a server for free, even though it would be a notable responsibility and an effort if I resolved to keep it safe on a disc at home.

(Y’know, on that seemingly facetious point about going outside: I think that could be the unexpected philosophical realisation from our constant exposure to high-quality computer graphics – yes, we human beings like looking at realistic, crisp, crunchy visuals… and they’re all around us, all day long, lit by the sun for our convenience.)

More broadly: maybe the saturation of network bandwidth and processor power that now surrounds us is neither necessary nor desirable? Maybe this thing that we’ve had for the last ten years and not in the preceding ten millenia isn’t yet being used right. Maybe we don’t benefit enough from guaranteed industrial strength computing and data streaming at our fingertips day and night, to justify the environmental cost.

6. Integrated circuit fabrication requires large amounts of energy, highly refined machinery and poisonous substances. Because of this sacrifice, the resulting microchips should be treasured like gems or rare exotic spices.

A great way of putting it! The demoscene that Viznut came from is all about getting the utmost from old technology and systems instead of relying on Moore’s Law. So he has come up with a sound justification for this aesthetic interest, which can often otherwise relapse into mere nostalgia. He’s careful not to tie himself to “junk fetishism” as an end in itself.

7. The space of technological possibilities is not a road or even a tree: new inventions do not require “going forward” or “branching on the top” but can often be made from even quite “primitive” elements.

And here’s a justification for playing with old tech, from the point of view of innovation. It does make sense. Again, what I like about Viznut’s writing is the confident, autodidactic, outsider’s perspective. From there I can look at computing, whether enterprise systems or game modding or web content management, quite afresh.

8. Computer systems should make their own inner workings as observable as possible.

Another lofty ideal. I am strongly, instinctively behind this one. In all the software I’ve coded, I came back to real-time feedback as a tool again and again. Observing changes in a feedback loop suits my short attention span. In my computer science course, I most enjoyed the sensation of tunneling into the depths of a system and making them comprehensible and useful. Even a routine backend database like I made for my e-commerce project gives me this pleasurable feeling.

My site (made for a college project) plucking content from a backend database.

9. Any community that uses computers would have the ability to create its own software.

I interpret this not as a call for us all to be hackers, or teaching “kids to code”. Rather I think it’s a call for a smooth continuum of complexity to be available, from newbie use to full control of building the software. For example, I would say Excel formulas, Access pivot tables, and any kind of macros are an absolutely legit place to start programming. Same with game modding, or shell scripting, LaTeX, whatever. (This philosophy developed from ideas from the lovely, now-defunct blog by James Hague.)

The tricky part is for each level of complexity to bleed naturally into the next, tempting the learner to try new things.

This is where gated platforms, whether that’s FB posts or software on the cloud, can be the enemy of creativity. I’ve discussed that issue before.

10. The ideal wieldiness [of a program] may be compared to that of a musical instrument. The user would develop a muscle-memory-level grasp of the program features, which would make the program work like an extension of the user’s body (regardless of the type of input hardware).

Not much to say to that, except that most of the programs we use day to day haven’t reached that standard.

11. Artificial intellects should not be thought about as competing against humans in human-like terms. Their greatest value is that they are different from human minds and thus able to expand the intellectual diversity of the world.

Viznut’s interest in AI was perhaps the most disconcerting part of his article and the one that changed my outlook the most.

For the last few years I’ve viewed AI as a tech buzzword whose visible manifestations (neural upscaling, Google DeepMind, GPT-3) are distinguished by aesthetic hideousness. And as you might gather, fear underlies that dismissal. I found the thought of AI disturbing.

Viznut gave me a different view. While emphasising the computational expense of training machine-learning systems, he mostly views AI as a welcome new type of entity for us to exist with. Criticising it for being inhuman isn’t saying anything. Rather it can be judged by how well it helps us humans to survive. Pragmatic, yet (in a nice change from how we started this piece) optimistic stuff!

Thanks for reading!

[Cover image is nabbed from Kris De Decker’s astounding Low Tech Magazine website. Do yourself a favour!]

Thoughts on Beginner Programming Languages

I coded up a prototype recently in a new realm: video compositing in real time. It was enjoyable for a few reasons, one of which was the language I used.

Processing has been around for a while. It’s designed to give instant access to graphics programming. It does that by exposing one-line functions that draw to a window without pretty much no configuration needed, by locking in a folder structure (e.g. images you want to work with go in a “data” subfolder), and tying everything together in a simple dev environment.

It’s ostensibly aimed at visual artists and students, and it fits in a lineage of what we could call “beginner languages” that intentionally hide complexity. Because I’ve now had a variety of encounters with such languages, including QBasic in my teens, a previous failed attempt to learn Processing, and a bit of a tool around with Racket earlier this year, I thought I’d try pin down some thoughts on them.

Let’s maybe take a wide perspective on my whole encounter, from the first thought of “Maybe I could use Processing?”

I DuckDuckGo-ed it, and a nice .org site popped up. Wow! First impressions were really good. The whole vibe of the community and ecosystem is cheerful and welcoming.

A nifty header style from the Processing website

There are pleasing non-jargon phrases all over the front page: “Creative Applications”, “Sketchpad”, “Visual arts”, “books available” – and yet it also feels like extensive technical work has been done, with links to implementations in multiple languages, and the obligatory Github profile, and many sponsors and partners.

I’m gonna go through this experience both from my current point of view, and an imagined one of a total beginner programmer. Both of these would give the Processing site, and related ones like Happy Coding, a hearty

The default installation format is a portable one. That might be a hassle to some. Or maybe it’s actually good. Unzip it and go, no permissions or shortcuts or whatevs.

The splash screen

The IDE loads showing a crisp splash screen with generative vector patterns like the main site. It’s perfectly decent, except for one thing which the docs make a lot of fuss about. Each code file is called a “sketch” – and the folder where these are kept is insistently referred to as “the sketchbook”. This caused me about ten minutes of trying to figure out if the sketchbook was a file format, and figuring out that it was automatically placed in a different location than where I’d unzipped the IDE. Calling it “sketches” would have made that clearer.

But for our absolute beginner, it’s not so bad: the IDE opens with a blank file, and you can copy in some example code and click the run button, and it works straight away. That’s REALLY nice.

This is what I really want to explore today. The trade-offs of simplification.

I think there’s an interesting conflict, in that simplification can make the first steps easier – which again is super valuable – but the next steps harder.

Both times I tried out Processing, I had this sinking feeling of near-betrayal as the light fun of the early steps sank into a morass of what feels like second-guessing the developers.

And I had it years back with the natural-language interactive fiction system, Inform 7, which I gave up on.

Making first steps easier is an illusion – one gets the feeling of accomplishment without really understanding what’s going on.

That can be all right. Computers hide inner workings from us all the time. The issue is finding the right balance of illusion so that the first peek behind the curtain doesn’t shatter fragile confidence.

I explore systems by trying odd things. For example, when I was checking out the Standard Vector Format for geometrical web graphics modifiable with JavaScript, I gravitated to abusing the “dashed line” capability to make weird art. (Overlaying super wide dashed lines to form swimming shapes and random pixel patterns.)

This tendency of mine clashes with the carefully-laid illusions of beginner languages. It took me say twenty minutes and half a screen of code to display one layer of a candle flame and show it, chuffed, to my dad. Implementing my actual goal of compositing a few layers with filtering and interactive controls, took a whole day, much of which was spent in frustration as the seemingly generous affordances of the language turned to cobwebs.

Here were some things that tripped me up after my first joyful success:

  • drawing off-screen required trawling the none-too-voluminous developer docs to figure out the difference between a PImage and a PGraphics object -I’m guessing working on an off-screen a buffer wasn’t considered a fundamental use case for people coming from a visual arts background
  • a Movie object acts like an Image, but its width and height fields are set at 0 until the first call to its read() method (making some initialisation stuff harder)
  • some graphics functions are overloaded so that they can take either the red green blue components of the desired colour or a single component as a greyscale value – but not consistently
  • drawing to an off-screen buffer has to take place inside the single set draw() method, otherwise it randomly will draw to the main window in flickers

And there was more, but this is boring. Once I figured them out, it was okay. Even the rather arcane pipeline I ended up with – a Movie’s read() setting a flag that an update is required, which is checked in draw() which if necessary calls loadPixels(), updatePixels(), beginDraw() and endDraw() on the various buffers, and the actual draw calls and filter calls, in the correct order – is more or less understandable. (I didn’t say optimal!)

It’s just that… there’s a let-down from the initial hey presto! to what feels like debugging a somewhat complex system you don’t understand. Now there’s nothing wrong with that process. That’s how to learn. But could the journey from delight to disappointment be mitigated?

It was that feeling of having waded in a bit beyond my depth and being swept away by uncontrollable factors, that turned me off Processing and Inform 7 before.

However… I don’t think Processing could be much better. The only ways to smooth my experience would be tiny tweaks: if someone rewrote a tutorial, tweaked a line in an example, and so on. I see why people talk of community as a central aspect of high-quality software.

My conclusion is that despite the inevitability of harsh contact with system complexity, beginner languages are great – but don’t start one, join an existing one.

Community building is also behind those good vibes that are maybe even more important than the technicalities, when welcoming interested newbies.

Oh, and yeah, what did I actually code? Glad you asked. Taking some tips from an awesome visual effects tutorial by an enthusiastic fellow called Lendon Bracewell, I made some candle flame effects for a votive shrine app I’m planning. The idea is for this to become a fast prototyping/design tool when I’m assembling my app’s candle animations and effects. Check it.

Till next time.