In the weeks since the Github Game Off, I have been working on making my game, PolyBranch, playable in mobile browsers. A huge part of this has been optimization. PolyBranch was written using slightly non-conventional, although hugely beneficial methods in that the core game was written in Processing (Java) and then exported to JavaScript via Processing.js from the Processing 2.0 IDE. This is the standard way of exporting your Processing sketches to the web, however, in addition to this I followed Pomax's guide to bind my Processing.js code and JavaScript code to each other, thus allowing myself to make calls to Processing with the site's JavaScript. This is how the majority of the event binding in the game was done, including the entire menu and any GUI elements. The big advantage of this is being able to write your GUI in straight HTML5. Being designed for making interfaces (websites), it is much easier to write your GUI this way than directly in Processing!
Now, back to my original point, what makes this so important is optimization. When developing HTML5 canvas for mobile, it has been widely accepted that JavaScripts requestAnimationFrame() function offers huge advantages over traditional JS timing functions like setInterval() or setTimeout (see Paul Irish's post for more info as well as the polyfill). Unfortunately, because rAF wasn't around when PJS was first written, it uses setInterval() instead. The good people on the PJS team are aware of this and hard at work on a fix, but just isn't there yet. So, because of this, I found a work around! Because I had already bound PJS and JS together so I could do the interface, I also handed control of the looping to JS entirely! This way, I was able to write a rAF loop which calls pjs.draw(), as I will demonstrate below:
First, binding JavaScript and Processing.js together (see Pomax's guide for more details)
I have had better luck with renaming my .pde file to a .pjs file at this point. This is a practice I have copied from examples around the web, although I do not know why it works. If anyone has an explanation, I would love to know! :)
Now that Processing and JavaScript can communicate with each other, we can use rAF to call Processing's draw function!
This is a very bare-bones demonstration of the draw loop. Be sure to check out Kushagra Agarwal's article on time based animations for best results!
As a disclaimer, I should note that I had moved over primarily to JavaScript development at this point in the process and was using this method so I could retain the logic I had written in Processing. I was no longer working within the Processing IDE! If you are using Processing.js as a JavaScript library, you can also check out this discussion from the PJS google group.
Showing posts with label Processing. Show all posts
Showing posts with label Processing. Show all posts
Thursday, April 4, 2013
Thursday, May 13, 2010
I am The Laughing Man
This is a small sketch I thought I would post just for the fun of it. I am taking an artificial intelligence seminar this quarter and our discussion on augmented reality inspired me to try my hand at OpenCV. I have been having trouble getting the sketch to run efficiently, but I have seen some fantastic OpenCV programs done in Processing, so I know it's possible. Something for me to work on once I have the free time. In the meantime, here is my super awkward screen capture!
Sunday, April 11, 2010
And then there were bubbles!
I oftentimes find that most of my projects are very spontaneous. I think this is why I like Processing so much; I'll be doing whatever I'm doing and then suddenly be like "oh hey I want to program x!"
And then I do.
My latest spontaneous Processing shenanigans were inspired by my motion graphics professor Rafael Macho. He was showing us some of his work and a design from his Aptera Car project caught my eye.
I thought "Wow, a design like that would be incredibly tedious to illustrate, but probably really fun to program" so I pulled up Processing and got to work.
My First attempt was very simple: Create a simple set of rules for how the bubbles look and then for every vertical coordinate create one with a random x coordinate. It ended up looking something like this (or click here to try the applet for yourself):
I liked the result from a visual standpoint, especially since the pattern scrolls infinitely, but I decided I wanted to try and see if I could prevent the bubbles from overlapping. I wanted to try incorporating physics. I found some code in the Processing examples library called "Bouncy Bubbles," by Keith Peters. I tweaked the code to incorporate my aesthetic and ended up with this:
The new bubbles, while amusing to watch, didn't create a pattern I liked as much as the previous attempt. So I returned to my previous attempt and reprocessed it in a different way so that the texture generated statically, without scrolling down the screen. I then decided that since it was a texture, it was important for it to be tileable, so I added a couple checks to make sure the bubbles continued on the opposite side of the screen if they went over the edge. In the end, I was rather pleased with the result:
The difference is not very obvious from taking a snapshot of the program, however when running the program (which features PDF export in the application version) and using the texture, it is now seamless and can be duplicated infinitely in any direction.
Coming soon - "And then there was JavaScript!"
Subscribe to:
Posts (Atom)