Difference between revisions of "Processingjs gamepaper"
(→Introduction) |
|||
| (33 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | = | + | =Any further edits should be made in this section or mentioned to Cathy or Daniel. formatting this into ACM now= |
| + | |||
| + | add changes here or contact cathy or daniel | ||
| + | |||
| + | =Processing.js for Web based Games= | ||
==Introduction== | ==Introduction== | ||
| − | + | Games delivery require fast, highly graphical, interactive, multimedia environments. To accomplish this, games delivered on a web page, have traditionally required some sort of browser plug-in. However due to security concerns and general wariness about plug-ins, delivering content/games in this manner is a barrier to access for some users. Furthermore, browser plug-ins are not available on browsers for all platforms. Even Flash, which is one of the most ubiquitous visual interactive environments, is not available for every browser. The HTML5 <canvas> element, standardized in ...(find citation) allows the programmatic delivery of graphics on a web page without plug-ins. With its inclusion in the soon to be released IE 9, the <canvas> element now represents a means to deliver rich graphical content in all the major browsers. | |
| − | + | The typical way to draw on the canvas is to use JavaScript. However for artists, educators, and other people less familiar with JavaScript, learning to do this can be a barrier to entry. The Processing language introduced by Ben Fry and Casey Reas is a simple and elegant language for data visualization that is already used by artists, educators, and commercial media to deliver rich graphical content called sketches. There is a large body of work around the world which is being developed using Processing. However, Processing is developed in Java and thus delivering Processing sketches on a web page requires that the user install a Java plugin. Furthermore the sketches themselves are self contained items as opposed to being part of a web page. While it is possible to deliver a sketch via a Java applet, the web page serves as a medium of delivery as opposed to being part of the game. | |
| − | |||
| − | |||
| + | Processing.js is an open source, cross browser JavaScript port of the Processing language. It uses the canvas element for rendering and does not require any plug-ins. However, Processing.js is more than just a Processing parser written in JavaScript. It also enables the embedding of other web technologies into Processing sketches and vice versa. This extension allows not only the rendering of sketches without the use of plug-ins but also the ability for a Processing sketch to make use of web technologies to create games. Processing.js seamlessly integrates web technologies with the processing language to provide a framework for multimedia web games. | ||
| − | + | ==Background== | |
| + | 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 (source?). The project, similarly to other open source products, was released with the hope that a developer community would converge around it and contribute to development. In September 2009, students from Seneca College 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 November 2010. | ||
| − | Processing.js | + | ==Processing.js in detail== |
| − | + | The original Processing Language is written in Java and the syntax is Java based. Sketches written in Processing can 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, was first developed, Java was supposed to become the language of the web while JavaScript was a 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 real-time interactive multimedia web applications 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 translate that code to JavaScript. However, if the parser encountered JavaScript code, it would leave the code intact as JavaScript. This method allows not only for the interpretation of existing Processing code but also the injection of JavaScript into Processing sketches. JavaScript code can exist 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 easily make use of common web libraries such as JQuery or pull in resources from web services such as Twitter, Google maps, or Flickr. | |
| − | + | 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 when a web page is loaded. The code produced by 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. In later versions of Processing.js this method of scanning the entire sketch was replaced by the creation of an abstract syntax tree that broke up the sketch into smaller pieces. Each piece was then interpreted separately. This change made the interpretation of the sketch far cleaner. | |
| − | + | ==The Blending of the Web== | |
| − | + | One of the most powerful features of Processsing.js is its ability to blend JavaScript code with Processing code. This results of this blending means that Processing sketches are not simply delivered in a self contained container but can make use of and interact with other elements of the web. This section looks at examples of such blending. | |
| − | + | /* insert descriptions and screenshots of applications for demo reel here*/ | |
| − | |||
| − | |||
==Browser Unification== | ==Browser Unification== | ||
| − | One important feature provided by Processing.js is that it hides the differences between browsers. Web standards are often loosely defined, and thus variations can exist. These variations not only exist between different browser vendors but can even exist between versions of the same browser on different platforms. | + | One important feature provided by Processing.js is that it hides the differences between browsers. Web standards are often loosely defined, and thus variations can exist. These variations not only exist between different browser vendors but can even exist between versions of the same browser on different platforms. Something as simple as key events can vary widely between browsers. When creating content as interactive as games in the web, these small differences can create huge problems for the content creators. |
| − | + | Processing.js hides a large number of these differences from the user by creating a unified method of handling common interactive events. Regardless of the browser/platform, the functions behavior of the event handlers are the same in different browsers. This standardization makes Processing.js an ideal candidate for game developers to develop games without worrying about how the controls will differ between browsers. | |
| − | |||
| − | |||
==3D support== | ==3D support== | ||
| − | The introduction of the <canvas> | + | The introduction of the <canvas> element into the HTML5 specification allowed Processing to be ported to JavaScript. This enables users to run 2D Processing sketches within the browser without additional plug-ins. At the time the Processing.js project began, there was no plug-in free method of delivering 3D content. This limited Processing.js to its 2D functions. WebGL, a JavaScript API that is based on OpenGL ES 2.0, is now being implemented by Firefox, Chrome and Safari. Processing.js 1.0 makes use of WebGL to support its 3D functions. |
| − | + | The matter of porting 3D Processing to Processing.js was simplified because Processing uses OpenGL for 3D graphics. The single largest difference between WebGL and the OpenGL library used in Processing is that in WebGL, the fixed-function pipeline has been removed. Because of this, user-defined vertex and fragment shaders are necessary for lighting operations. Since some shapes in Processing aren't lit and others were, multiple shaders have been written. One shader exists for lit objects such as boxes and spheres, another less complex shader was written for unlit objects such as lines and points. | |
| − | The matter of porting Processing | ||
| − | + | /* shaders to go in a figure on final paper*/ | |
<pre> | <pre> | ||
| Line 70: | Line 69: | ||
</pre> | </pre> | ||
| − | === | + | ==Conclusion== |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | Processing.js seamlessly integrates elements of a webpage to create a viable platform for games on the web. It handles events in a consistent manner between different browsers, making it easier for game developers to create content with it. Furthermore the interpreter was written efficiently. Today's JavaScript engines are highly efficient. This efficiency means that interactive applications such as games can be written in JavaScript. Processing.js makes this process smoother. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==References== | ==References== | ||
Latest revision as of 13:20, 16 January 2011
Contents
Any further edits should be made in this section or mentioned to Cathy or Daniel. formatting this into ACM now
add changes here or contact cathy or daniel
Processing.js for Web based Games
Introduction
Games delivery require fast, highly graphical, interactive, multimedia environments. To accomplish this, games delivered on a web page, have traditionally required some sort of browser plug-in. However due to security concerns and general wariness about plug-ins, delivering content/games in this manner is a barrier to access for some users. Furthermore, browser plug-ins are not available on browsers for all platforms. Even Flash, which is one of the most ubiquitous visual interactive environments, is not available for every browser. The HTML5 <canvas> element, standardized in ...(find citation) allows the programmatic delivery of graphics on a web page without plug-ins. With its inclusion in the soon to be released IE 9, the <canvas> element now represents a means to deliver rich graphical content in all the major browsers.
The typical way to draw on the canvas is to use JavaScript. However for artists, educators, and other people less familiar with JavaScript, learning to do this can be a barrier to entry. The Processing language introduced by Ben Fry and Casey Reas is a simple and elegant language for data visualization that is already used by artists, educators, and commercial media to deliver rich graphical content called sketches. There is a large body of work around the world which is being developed using Processing. However, Processing is developed in Java and thus delivering Processing sketches on a web page requires that the user install a Java plugin. Furthermore the sketches themselves are self contained items as opposed to being part of a web page. While it is possible to deliver a sketch via a Java applet, the web page serves as a medium of delivery as opposed to being part of the game.
Processing.js is an open source, cross browser JavaScript port of the Processing language. It uses the canvas element for rendering and does not require any plug-ins. However, Processing.js is more than just a Processing parser written in JavaScript. It also enables the embedding of other web technologies into Processing sketches and vice versa. This extension allows not only the rendering of sketches without the use of plug-ins but also the ability for a Processing sketch to make use of web technologies to create games. Processing.js seamlessly integrates web technologies with the processing language to provide a framework for multimedia web games.
Background
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 (source?). The project, similarly to other open source products, was released with the hope that a developer community would converge around it and contribute to development. In September 2009, students from Seneca College 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 November 2010.
Processing.js in detail
The original Processing Language is written in Java and the syntax is Java based. Sketches written in Processing can 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, was first developed, Java was supposed to become the language of the web while JavaScript was a 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 real-time interactive multimedia web applications 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 translate that code to JavaScript. However, if the parser encountered JavaScript code, it would leave the code intact as JavaScript. This method allows not only for the interpretation of existing Processing code but also the injection of JavaScript into Processing sketches. JavaScript code can exist 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 easily make use of common web libraries such as JQuery or pull in resources from web services such as Twitter, Google maps, or Flickr.
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 when a web page is loaded. The code produced by 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. In later versions of Processing.js this method of scanning the entire sketch was replaced by the creation of an abstract syntax tree that broke up the sketch into smaller pieces. Each piece was then interpreted separately. This change made the interpretation of the sketch far cleaner.
The Blending of the Web
One of the most powerful features of Processsing.js is its ability to blend JavaScript code with Processing code. This results of this blending means that Processing sketches are not simply delivered in a self contained container but can make use of and interact with other elements of the web. This section looks at examples of such blending.
/* insert descriptions and screenshots of applications for demo reel here*/
Browser Unification
One important feature provided by Processing.js is that it hides the differences between browsers. Web standards are often loosely defined, and thus variations can exist. These variations not only exist between different browser vendors but can even exist between versions of the same browser on different platforms. Something as simple as key events can vary widely between browsers. When creating content as interactive as games in the web, these small differences can create huge problems for the content creators.
Processing.js hides a large number of these differences from the user by creating a unified method of handling common interactive events. Regardless of the browser/platform, the functions behavior of the event handlers are the same in different browsers. This standardization makes Processing.js an ideal candidate for game developers to develop games without worrying about how the controls will differ between browsers.
3D support
The introduction of the <canvas> element into the HTML5 specification allowed Processing to be ported to JavaScript. This enables users to run 2D Processing sketches within the browser without additional plug-ins. At the time the Processing.js project began, there was no plug-in free method of delivering 3D content. This limited Processing.js to its 2D functions. WebGL, a JavaScript API that is based on OpenGL ES 2.0, is now being implemented by Firefox, Chrome and Safari. Processing.js 1.0 makes use of WebGL to support its 3D functions.
The matter of porting 3D Processing to Processing.js was simplified because Processing uses OpenGL for 3D graphics. The single largest difference between WebGL and the OpenGL library used in Processing is that in WebGL, the fixed-function pipeline has been removed. Because of this, user-defined vertex and fragment shaders are necessary for lighting operations. Since some shapes in Processing aren't lit and others were, multiple shaders have been written. One shader exists for lit objects such as boxes and spheres, another less complex shader was written for unlit objects such as lines and points.
/* shaders to go in a figure on final paper*/
"varying vec4 vFrontColor;" +
"attribute vec3 aVertex;" +
"attribute vec4 aColor;" +
"uniform mat4 uView;" +
"uniform mat4 uProjection;" +
"void main(void) {" +
" frontColor = aColor;" +
" gl_Position = uProjection * uView * vec4(aVertex, 1.0);" +
"}";
fragment shader:
ifdef"GLfESf GL_ES\n" +
"prehighpn highp float;\n" endif"#endif\n" +
"vvecinvFrontColorntColor;" +
"void main(void){" +glrFragColoragCvFrontColorntColor;" +
"}";
Conclusion
Processing.js seamlessly integrates elements of a webpage to create a viable platform for games on the web. It handles events in a consistent manner between different browsers, making it easier for game developers to create content with it. Furthermore the interpreter was written efficiently. Today's JavaScript engines are highly efficient. This efficiency means that interactive applications such as games can be written in JavaScript. Processing.js makes this process smoother.
