subpixels.com | SPXL.TVblog | contactgallery | videoflash | processingmyspace | facebook

Processing 1.0 26 November, 2008 at 9:48 am

Processing sample: Esfera_mod_by_spxl_4

Esfera_mod_by_spxl_4
based on Esfera.pde by David Pena

Source code:
Esfera_mod_by_spxl_4.pde
Hair.pde
Oscillator.pde

Just when I thought I was clever having multiple Processing sketches live in the same folder (to share libraries), along comes Processing 1.0. I’d only just downloaded a newer version, like, yesterday… Okay, I’ll get the official 1.0 release then. Since it’s official and all. :o)

First thing I encountered was Processing 1.0 does not work with the JDK I already had installed. Hmm. Okay, I’ll grab the latest JDK from Sun then, since you’ve already opened a browser window for me. Next problem – can’t unpack the installer, ‘coz my drive is low on free space. Bother. What to do? I know!.. spend a few hours wathing old slideshow videos that are hogging gigs of space, and maybe delete some of the duplicates and otherwise unwanted renders. Aside from the tedium of drive space maintenance, this was quite a pleasant chore, since those videos hold / stir up plenty of memories of fun times back in Sydney (mostly) with friends and out on the town. (Which reminds me, what am I doing here in London again?…)

So, after much messing about to finally get the new version up and running, I’ve had another play with (read: massive hack at) the Esfera example, drastically modifying how the Oscillator class works by making it time based (instead of frame based). It seems that some of the changes I’d made the day before hadn’t saved or something, as I recall having to “re-change” some changes I’d made. Need to keep a better eye on what is actually being “saved” in Processing, I think… it’s too easy to assume that what you’ve just compiled and executed (and works just as you planned) is what is saved in the .pde files, but this isn’t the case!

Everything now revolves around, essentially, millis() – the number of milliseconds elapsed since the applet started. I grab this information at the top of the draw() function and calculate how many milliseconds have elapsed since the previous draw. I’ve put a fudge into the code that pauses and unpauses the applet (on mouse click) to effectively remove the time elapsed whilst paused, so the animation stops and starts cleanly instead of jumping to a non-connecting state. This technique may come in useful one day for something…

I’ve also added some (not so) exciting interactivity to allow adjustment of each of the (now 7) oscillators, including pausing, setting the period (by value or by increment/decrement), reversing the direction, changing the wave shape (sine, triangle, sawtooth, square). The 8 pieces of text (“Hello”) radiating as petals have been replaced by details of each of the oscillators. Pressing any of the bottom row of letters in the QWERTY layout (z, x, c, v, b, n, m) directly selects one of the oscillators. Alternately, use the LEFT or RIGHT arrow keys to go to the previous/next in the list (with wraparound). Details for the currently selected oscillator are displayed at the top left of the applet, and the corresponding petal is hilighted yellow. It looks a bit like some not-so-futuristic, but also not so helpful, flashy interface for something important, and might just pull off being more serious if it didn’t bounce around so much. ;o)

I put some more effort into fixing some previously sketchy comments, and this is partly helped by having a better idea of what is going on in tke sketch, certainly with regards to some of the graphics calls. I’ve also massively over-engineered the Oscillator class in the hopes of reusing it in future, and perhaps even being useful to someone else.

Anyhow, upon exporting the sketch from Processing I have discovered that the library files are different. Are a 986kB jogl.jar file and a 1,131kB jogl.jar file compatible? Unlikely! There are also a bunch of extra gluegen-rt files that I’d not seen before (nor have any current knowledge as to what they’re for). It’s getting pretty messy in there! So I’ve decided each applet shall have its own place in the directory tree. A further consequence that I’d not run into before is that, even though the main .pde file has a different name (I’ve named each version separately), the “inner class” files (the other .pde files) have the same name, and since I’ve completely changed the interface they can’t happily coexist. Keeping things separate perhaps doesn’t seem like such a bad idea after all. Maybe later I’ll work out how to share the larger libraries. I can, if I get around to it, link them on the webserver to save uploading if I need to, but the download bandwidth is still an irritation.

-spxl

Leave a Reply