Open main menu

CDOT Wiki β

Changes

Processingjs gamepaper

444 bytes removed, 05:47, 16 January 2011
JavaScript
The Processing.js project was started by John Resig who wanted to utilize the HTML5 canvas element and take advantage of the Java Processing language. It took about seven months to get a working version, consisting of 5000 lines of code but it was not a complete port of the Processing language. The project, similarly to other open source products, was released with the hope that a developer community will converge around it and contribute to development. In September 2009, we began the work to complete Processing.js. In order to facilitate an architecture for participation the source code had to be readily available and the inner workings of the project and the missing functionality must be publicized. To this end the source code was made available publicly on GitHub and an issue tracking system was used to manage the large number of issues needed to be resolved in order to complete the port. A review process was setup to ensure that the code submitted was of sufficient quality. Processing.js 1.0 was released in ???.
==JavaScriptProcessing.js in detail==
The original Processing Language was written in Java and the syntax is Java based. Sketches written in Processing are can then be compiled into standalone applications or Java Applets. Processing.js interprets Processing sketches and creates JavaScript code that renders on a web page. When the original Processing Language, also known as P5, was first developed, Java was supposed to become the language of the web while JavaScript was client-side scripting language for small tasks. As the web matured, JavaScript, however, became the language of the web, although many of the misconceptions about it still persist. /*cite javascript the good parts here*/ With recent developments in JavaScript technology, JavaScript is now fast enough to handle the demands of realtime real-time interactive multimedia web graphicsapplications such as games.
From it's inception, Processing.js was designed to be more than just a rewrite of the Java functions provided by Processing to JavaScript. John Resig wrote the original Processing.js parser to scan a Processing sketch for hints of Java code and convert translate that code to JavaScript. However, if the parser encountered JavaScript code, it would leave the code intactas JavaScript. This method allowed not only allows for the interpretation of existing Processing code to JavaScript but also the injection of JavaScript into Processing sketches. By allowing JavaScript to exist within a Processing Sketch intact, Java and JavaScript code can exist together inside a Processing sketch without any need to declare the language you are using. Old sketches written for Processing will work but new sketches written for Processing.js can not only have Processing code but can easily make use of JavaScript to interact with other elements common web libraries such as JQuery or pull in resources from web services such as Twitter of the webpageFlickr.
Processing.js is more than just a Processing parser re-written in JavaScript. It is designed in a way that connects the Processing language (also known as P5) with web technologies such as JavaScript, the HTML5 canvas element, JQuery, and various web services. /*Awkward*/ Furthermore, Processing.js is built in such a way as to allow easy integration of new technologies as they emerge. It is designed to be fast and to take advantage of recent JavaScript developments to ensure that the platform is responsive. While JavaScript and Java are fairly similar syntactically, there are some fundamental differences that has made this conversion challenging. The first is that we wanted to do this conversion dynamically in real timewhen a web page is loaded. The code produced by the converter??? Processing.js needed to be fully object oriented and we had to provide support to all native Java functions and objects that are supported by Processing. We also had to take into account the differences between working with web resources vs local resources. Furthermore we had to consider how we would handle some fundamental differences between Java and JavaScript such as typed vs. typeless variables, function overloading and variable name overloading.
The original code for Processing.js used regular expressions to convert Java into JavaScript when it was encountered. It did this by scanning for hints of Java code within the entire sketch and then replaced the Java code with its JavaScript equivalent. Due to the difference in how Java and JavaScript accessed object properties from methods inside an object, the with statement was used as a simple solution to avoid having to prepend all function calls with "this." or "Processing.". However, the use of the with statement also meant that the JavaScript generated would fall off Trace /*cite trace paper here... do we need to talk about trace in the back ground section???*/ making the code run slower than it needed to in some browsers. Later this method of scanning the entire sketch was replaced by the creation of an abstract syntax tree that broke up the code into smaller pieces. Each piece then had the regular expressions applied to change it. This made it was easier to apply the regular expressions correctly without accidentally converting code that was already working. It also made it easier to create proper inheritance structures and attach properties and methods to the correct object in the hierarchy chain as smaller pieces of code was being converted at any one time.