Oh sweet, good news. I hope the developer's reports are true!

Yes, me too! I've got a rather large workload, currently, but V8 on iOS has been added to the roadmap

It's been a very interesting discussion.

As mentioned I'm going want to get an Ouya game up and running. You(Lorin) mentioned that it's easy to implement native API's. I'm assuming you mean other JAVA api's like the Ouya DK. Could you point to a simple sample at what would be involved to do such work. I sorta dropped heavy programming last year in favour of my writing(fiction and RPG's) work and then found C2 as a wonderful alternative to coding games on my own. So I'm very minimalist right now on coding :P So any direction and pointers for the right direction would be awesome.

That's an interesting and cute naming convention, but please oh please do not name anything based on Hastings :D

In reverse order: Hastings Project...ok, now that you say that, I think it needs to happen :)

To clarify what you want to do: create an API for X (like Ouya controller) and expose it to the Pender JavaScript environment?

The Now

Pender uses Rhino for it's embedded js environment. This allows some fantastic utilities for inclusion of native (Java) code and libraries.

1. Inject a Java API into JavaScript from Native

Easily done, example of syntax here:

github.com/lorinbeer/pender-android/blob/master/src/com/pender/PenderCanvas.java

you'll see the implementation of the Canvas drawImage functions

github.com/lorinbeer/pender-android/blob/master/src/com/pender/renderer/PenderRenderer.java

in setupJS, you can see the simple syntax for injecting a native class into JavaScript. Rhino does the rest. That class can now used to create JavaScript objects, and call native code.

2. Include a Java API's from inside the JavaScript Runtime

Easily done as well, example of syntax here:

github.com/lorinbeer/pender-android/blob/master/assets/penderandroidshim.js]penderandroidshim.js

all you do is initialize a js variable with the "Packages.java.namespace.resolver" syntax. Both native droid libraries and custom java librairies can be included this way.

The Future:

The current version of Pender uses the Rhino engine as it's embedded JS environment. This, as I have mentioned, is being replaced with V8 for superiour performance. V8 requires us to wrap api's we wish to expose in a horribly complex (I'm mean nightmarish, really) template system.

Now, the work I'm doing in VateDroid (initial dump here:

github.com/lorinbeer/vatedroid

addresses this. This will allow for runtime inclusion of native classes even from JavaScript!

A chromium-based wrapper for mobiles initially seems like would be awesome, but what about ios? As far as I've heard, chrome on iOS is actually just a reskinning of the UI Webbview because they aren't allowed by apple to use their own JavaScript compilation methods or such. Is it just because it's a web browser that apple doesn't allow it? But if that's the case, wouldn't any game using chromium basically be a web browser, and potentially rejected as a result? Or do they not care as long as the game stays off the web and only loads local content?

it's true, iOS has had some licence/architecture issues preventing any third party javascript engines from running in fully optimized mode.

However, a recent developer licence change, which prohibited apps from interpreting code in anything but the webview sandbox or the browser sandbox, has been lifted. This happened maybe six months ago?

Now, I very very recently came across a dude who claims to not only gotten V8 to run on iOS, but actually gotten apps based on this tech into the appstore!

github.com/nguyenduong/V8-iOS

I say "claims", because I haven't had a chance to test any of this myself. Suffice it to say that this is an exciting time for mobile html5 game dev!

Ashley

Ok, lost my reply twice now :)

Not really - it got its main performance gains by using GPU acceleration, since all they had to beat was the hideously slow software-rendered UIWebViews which didn't even use the GPU! That's how they got their advertised 5-10x speedup, which is about how much GPU rendering beats software rendering by.

The original DirectCanvas was a hack of the Webkit canvas element, and was released as a code dump about a year ago here: github.com/appMobi. it looks like the repo has since disappeared, likely related to their acquisition.

My point about reflow is: the Construct 2 engine should never incur a reflow

true, Pender?s use case is primarily to run independently, or paired with PhoneGap, in which case reflow is an issue. It would not provide Construct2 with any additional advantage where reflow is concerned.

Our renderer is backed by OpenGL ES 2.0 on mobile, and WebGL will have a hard time competing with it.

I'm not sure why you say this, because WebGL basically is OpenGL ES 2.0. It's got some minor tweaks for it to work better on the web, but it's basically the same API.

There are some function silhouette differences, such as when requesting gpu vbo?s and such, but yes they are basically the same API. But that doesn?t mean they are the same implementation of the API. OpenGL ES is implemented with a driver in the device os kernel. WebGL calls that API. Pender architecture flattens out the number of intervening api calls, and attempts to make performance gains there. I?m working on publishing results from my test framework, and will notify when I can post some hard data.

So supporting WebGL would be a good step for Pender.

yes! WebGL support is part of our roadmap.

Really? If you take a look through the Web Audio API specification, is that really trivial to implement in native?

Exposing a native api to pender is trivial.

Implementation an api (such as Web Audio) from scratch? Non trivial.

Implementing a thin wrapper around the analogous native audio api?s that already exist, and exposing that to a js runtime? I won?t call my work trivial or easy, but it is not a lot of work.

Besides, why go to all the work of painstakingly re-implementing all sorts of web standards when it's already been done in Chromium, which is free for you to use?

We don?t re-implement, we use the Native libraries where they already exist, and wrap them so that they conform to Web standards. You have identified the horizon of Pender?s usefullness, and that is right here: we wrap API?s to enhance performance. Where there is no performance enhancement, or no performance enhancement needed, we don?t bother.

I could give Pender a shot, but I'm sure it will run in to all the same problems we have with other DOM-less engines. The compatibility is just a nightmare.

Pender is evolving rapidly, and I think you?ll be impressed with the V8 version. Having had experience with existing web game framworks, I won?t deny that compatibility may be a big issue.

However if you come up with a Chromium-based wrapper that would definitely be exciting and I'd want to investigate closely!

This would be a very exciting project, and something I?m going to look into right away!

On a side note, I?ve worked with Chromium before: I?ve got a project called Gelly, which had Chromium rendering a tab into an openGL texture. This allowed an openGL rendering engine to overlay a UI defined by html/css/js onto an openGL rendering context.

lorinbeer

Since you mentioned pender was a plugin for Cordova. Does that mean if I currently have an entire project built in eclipse with Phonegap, I can just add in the plugin?

—

yessir! Although, in order to use the Pender Canvas API, you would have to modify your project slightly in order to make use of the plugin.

Thanks. Depending on what technologies were available when the game i'm working was done. I was either going to look at GameClosure and work with there Barista layer to add the controller/IAP. However, working directly with source will probably be easier.

I kind of had a inkling that Pender was related to downtown Vancouver. With Pender and Cordova running parallel through downtown core. The naming convention seemed strange. I also had no idea that PhoneGap had it's early starting point at home :P Love seeing local developers :P

Here is another question. Canvas has a limited fillrate capabilities. So overdrawing over the same place wastes fillrate. OpenGl has better rendering methods and overall better performance. So why is that most developers who are building these JS/WEB bridges are focusing on Canvas rather than focusing on creating a OpenGL layer shim bridge instead. is it really that more difficult to overwrite the Canvas2D with a replacement OGL/WebGL layer that has all the same functions as Canvas2D?

Yeah man, Nitobi, creators of PhoneGap, were founded in Vancouver! The naming convention is an interesting (and embarrassing) story. I tell you this only because you're a Vancouverite. We had a cool (and clever) name for the open source version of PhoneGap after the Adobe acquisition, but failed to reserve rights to the domain *after* we announced the rename :P

We had to go through *another* rename, and since PhoneGap was invented while the office was on Cordova street...

Then Pender came about, and we saw an opportunity for a trend.

On Canvas: yes, excellent points, and to understand, we need to delve into what Pender actually is. We don't overwrite any browser Canvas functions, we implement a custom Canvas API and expose that to the javascript engine. A given chunk of javacode doesn't know the difference: it can consume the Pender Canvas api just as it would a browser Canvas api. However, our canvas api is actually a paper-thin layer between JavaScript and OpenGL ES 2.0! This provides precisely the performance you guess is possible.

It's also true that many other projects like Pender don't do this, and this could be for a couple of reasons. Foremost being that writing a shim is easier than writing a rendering engine in OpenGL and figuring out a way of injecting it into a javascript runtime.

As to Chrome/Chromium: yes, you can clone, rip, change and otherwise hack chromium and distribute it with your app. It inflates the app distrib size, but whatever :). In fact AppMobi got their performance gains with a custom Canvas element that they stripped of DOM reflow processing!

> To echo your points, the DOM is most certainly an advantage when it comes to layout and the breadth of api's available. However, it kills rendering speed even when hardware acceleration is implemented in the browser.

I disagree! Some of our best performance results on mobile are using Chrome for Android with WebGL enabled (see scirra.com/blog/107/boosting-mobile-html5-game-performance-with-webgl). Basically, although our engine uses lots of browser-level APIs, we don't ever really touch the DOM per-frame. So we don't get any perf hit from DOM manipulation or re-flow. And browsers, especially Chrome, are extremely efficient under these circumstances.

In fact, it is very difficult for DOM-less engines to match the performance of Chrome with WebGL support: unless you re-invent their multi-threaded renderer model which works with WebGL, have a highly optimised pipeline such as being able to read typed arrays from the javascript engine without copying or converting them, and so on, it's likely Chrome will still beat the DOM-less engine performance-wise. Unless you re-invent loads of browser features, Chrome will still beat the DOM-less engine feature-wise. Why re-invent the wheel when you can just use the Chrome browser engine? This is why I'm convinced the future of HTML5 game wrappers on mobile is the Chromium mobile ports.

Ashley

Chrome is hot stuff, and we have members of our team exploring that as well.

Browser reflow can be handled well in an engine like Construct2, but Browser reflow is hard to control outside of a highly controlled environment like an engine such as Construct2. Even accessing DOM element size will trigger reflow. Efficiency of reflow doesn't matter if it's robbing your render loop of resources. AppMobi's DirectCanvas achieved all of it's performance gains purely through stripping a custom webkit Canvas element of its reflow processing. What should have been efficient and negligible gave them a 400% increase in rendering speed.

In fact, it is very difficult for DOM-less engines to match the performance of Chrome with WebGL support: unless you re-invent their multi-threaded renderer model which works with WebGL, have a highly optimised pipeline such as being able to read typed arrays from the javascript engine without copying or converting them, and so on, i

and we do! I'd love to go over Pender architecture with you, but these elements are not as difficult to implement as you make them sound. Any renderer pipeline worth its salt is multi-threaded, and the Pender Renderer is indeed based on an asynchronous rendering model. Our renderer is backed by OpenGL ES 2.0 on mobile, and WebGL will have a hard time competing with it. We can indeed read typed arrays to and from javascript with the embedded js engine api's we use. In fact, we do so in a manner almost identical to chrome in the first place: V8.

I think you seriously underestimate the potential of a DOM-less js rendering engine built like Pender, but I will admit you make salient points:

• With Construct2, you handle the DOM reflow well. This may not be the case with games made with PhoneGap, which is what inspired Pender
• Chrome may indeed be the future of HTML5 Game Wrappers

But let's keep an open mind:

• Pender allows easy exposure of native api's. In fact, in the android prototype mode, you can inject any native api into the js environment with an include like syntax
• wrapping native api's to conform to open standards is also trivial
• the goal of this project is to close the gap between Native and Browser rendering performance. While Chrome offers excellent performance on mobile, it still can't compete with raw native implementations. Pender exists in between browsers and native.

I've been a big fan of construct2 and your blog, Ashley, you've done some really awesome performance breakdowns of the major browsers, platforms and performance.

Currently, I'm working on releasing the V8 version of Pender-Android and Pender-iOS (yes, v8 on ios is possible!) into the wild. Once that's up, I would really appreciate if you would put Pender through it's paces, or point me in the right direction!

Appreciate the feedback!

• Lorin

Demos? :)

Demos:

github.com/lorinbeer/pender-demos

this currently contains the render stress test "client" demo. It is also embedded in the pender-android repo.

We are currently working on additional game demos and demo videos, I'll post those when their up!

Wink

Thanks Wink! I really appreciate the interest some of the users here have shown in Pender. You've got some passionate, smart people. ArcadEd really went outside his comfort zone in getting Pender running on a windows machine, but he's a top notch dude. After that experience, I recognized the needs of the community here, and created a Pender.jar distributing hosted on bitbucket: bitbucket.org/lorinbeer/pender/downloads

Just drop that into an Android project, add it to the build path, and you have access to the Pender API.

Over the coming weeks, we'll work on getting Construct2 and Pender playing together. There is a large body of experimental work behind Pender, and I have high hopes for compatibility. I have experience doing this sort of thing, and am working with Uxebu on getting Bonsai.js working inside Pender as well. Note that no change to Construct2 will be necessary for the proof of concept I'll make, just a javascript shim. When that's successful, I'll bounce it past Ashley and see if he's interested in further collaboration!

Lot's more to come!

I've barely looked into Pender, just gandered through some of the files a few weeks ago. However I have a few questions.

1. Pender is mentioned to support PhoneGap. Does this mean that Pender can be independent of PhoneGap? Can I just use Pender files to run C2 game.

2. Would it be difficult to implement the Ouya DevKit controller api and IAP. I'm working on an Ouya game and want to make the most minimal effort in regards to persona programming to get my first game out there.

3. Is there enough to get C2 going now?

4. Why is it called Pender?

—

That would be fantastic. I dislike dealing with command line these days. i've gotten lazy :P

1. Yes, Pender operates as an Android Library. Pender can hook into PhoneGap/Cordova through a plugin, or run all on it's own

2. This is definitely something we should look at, and no, I do not think it would be difficult at all. Exposing new API's to the javascript environment on Pender is surprisingly easy. I haven't tested Pender on the Ouya environment, but this has been added to our roadmap!

3. I'm a committer on the PhoneGap/Cordova open source project as well as the creator/maintainer of Pender. Unfortunately, it's going to be a few days before I can look seriously into C2 support. I can write a shim next week to test my ideas. That might be enough to get Ashley interested if it's successful

4. The origins of Pender trace back to a company called Nitobi, located in Vancouver BC. We were acquired by Adobe Systems in 2011.

--edit-- sorry, still can't post links!

maps.google.com/maps

If you zoom out of Street view, a few blocks up, you'll see Cordova Street, which is the namesake of the Cordova project, the open source backend of PhoneGap.

If I have the time in the next week I could easily write a gui based solution in .net that simplifies the process.

I think that's a great idea, ArcadEd! Once you have an executable, I would accept it into the github repo or the static downloads. That would make you an official Pender contributor!

I can write the backend in a windows script that your gui can hook into.

Wink

ArcadEd

I develop in unix environments: linux distros and osx. So terminal/bash are what I use for all the commands shown. Cygwin might tie you over, but the real solution is a windows version of the build tool. This will take a little while, as I have other duties related to phonegap/cordova

Early this morning, I uploaded a precompiled Pender.jar file to the bitbucket downloads section:

bitbucket.org/lorinbeer/pender/downloads

1. Drop the Pender jar AND the rhino jar into your app's 'libs/' folder

2. right click on jars in eclipse and choose "add to build path"

3. use something like what I gave ArcadEd for the main activity

4. copy in the contents of the assets directory from the root of the git repo to the assets directory of the eclipse project

5. Run it!

After that, you should be able to play around with the penderdemo.js file to get different render results, specify different art resources, etc

lorinbeer Sorry I am coming into this late, what platforms are supported, any issues with Windows 8/Windows Phone 8 apps?

no worries, never too late!

Windows8 Phone apps are not currently on our roadmap. They could be added, but the underlying tech would be different. If interest grows, we can certainly explore Windows Phone 8 Pender!