"The JavaScriptCore Framework is still private on iOS. So as it is now, I won't be allowed to distribute the game in the AppStore. But my understanding is, that if I bundle my own copy of the JavaScriptCore Framework (which is part of WebKit and thus freely available) with my game, I should be on the safe side."
This is true. You can compile Javascript Core and include it in your app. I have done this previously as an experiment.
However, there is one HUGE drawback in doing so: no compiled/jitted javascript code is possible.
This is because iOS applications are not allowed to create executable code in the heap or on the stack, so there is no way for JavaScriptCore to compile to native code when it is running as part of a third party application.
So unfortunately there is no good way to get this going at the same speed that you get when linking against the private framework.
Sad. This is also a major problem for other scripting languages. They all can only run in interpreted mode. Which might be good enough but is never the best you can get.
Yep, I hit this roadblock too. For my similar project I ended up using a non-jit version of Spidermonkey for embedded Javascript. Interpreted performance is pretty poor in comparison to jit though, and I ended up moving to a much higher level Javascript API to share between canvas and native implementations. It runs at 60 fps on 2nd gen hardware now with moderate (1 - 2 hundred sprites).
I wonder how feasible it would be to pre-compile the Javascript to machine code before distributing it? Maybe someone determined enough could probably hack one of the existing JIT engines to emit executable machine code to a file?
For a restricted subset of Javascript it wouldn't be that hard.
I'm not sure that solves the iphone problem though - I don't think it's kosher to use non c/c++/objc code. A Javascript to C compiler would work fine, though. That would be quite a bit more work, though.
[Edit]As pointed out below, it might well be ok. I guess you'd have to somehow get the generated machine code into a static library and link it with your application. That might work.
Summary: Technology demo wherein the author takes a Javascript game, runs it as an App (no browser) using OpenGL instead of <canvas> and the Javascript interpreter already in the iPhone for the drawing and gets 60fps.
• The Javascript interpreter interface used is considered private and thus the app can not be distributed in the store.
• There is a history of private to public interface transitions, so perhaps…
• It suggests you could have all the game code be common between a web and a higher performance app version of a game.
• No word in the article about what percent speedup this represents.
The speedup is substantial, at least in this case. Biolab Disaster has to draw lots of small 8x8 pixel squares (about 500 for each frame) to produce the background map - which seems to be awfully slow in the iOS browser.
So it sounds like the source code for game is written in pure javascript (utilizing any special APIs calls provided by Impact). This javascript src is packaged using the Impact Game Engine which creates a Obj-C wrapper around the javascript. When the Game is loaded on an iOS device and run, the Obj-C wrapper (implemented by Impact) executes the javascript src via JavascriptCore.
It sounds like this is basically a Canvas to OpenGL translation layer.
Can only the Canvas object be leveraged when creating games/apps with this? Or could a "account creation" screen be created leveraging HTML elements like forms (I would assume not since its sounds like its executed outside of Safari, and the translation provided is from Canvas > OpenGL)
Yah, the original game is all in pure javascript written to the canvas. I have been poking around with making canvas apps and a few weeks ago I grabbed the source and spent a few hours reading through all of it. Good stuff. If the author wasn't in Poland (corporate doesn't have an office there) I would try to hire him.
There's a lot of interest in the mobile and JavaScript communities for a JavaScript engine you can distribute on iOS. Games are one thing, but with this you could take cross-platform, natively packaged web apps to a whole new level.
Exactly, or like PhoneGap. For example, you could write an Appcelerator or PhoneGap app and call into native code from a JavaScript bridge. Right now, each native API needs to be explicitly wrapped by Appcelerator or PhoneGap.
Make multimedia software, generally games, for iPhone/iPod Touch/iPad using javascript and html5 canvas and make it run almost as fast as a native version.
It is a native app: it uses JavaScriptCore and all Canvas calls are rendered using OpenGL. The implications are that if you write a game for Impact engine you can generate an iOS native app.
It's not quite that simple, though, from the sound of it - the author said he had to 'reimplement' all the canvas calls to use OGL. Fine if you're familiar with it, but for those people who just want to bash out a Javascript game without having to worry about the engine, they might have trouble.
So far I only reimplemented those Canvas API functions needed for the game; the most important one being .drawImage().
What I mean by "reimplement", is providing a .drawImage function for JavaScript that works in the same way as it does in the browser, but uses OpenGL-ES behind the scenes. This reimplementation is done in native Objective C.
The changes I had to make to Impact (the "HTML5" engine) are concerned with the loading of images, scaling, input and getting a reference to the canvas element and its drawing context. But I guess I could provide a dummy "document" and "getElementById" function, so that you can just write some JavaScript using Canvas and run it in the browser and on the iPhone unchanged.
From what I understand he only had to re-implement the canvas calls in the game engine.
"I of course had to make some changes to the engine, but the game source code is exactly the same as for the web version."
This is true. You can compile Javascript Core and include it in your app. I have done this previously as an experiment.
However, there is one HUGE drawback in doing so: no compiled/jitted javascript code is possible.
This is because iOS applications are not allowed to create executable code in the heap or on the stack, so there is no way for JavaScriptCore to compile to native code when it is running as part of a third party application.
So unfortunately there is no good way to get this going at the same speed that you get when linking against the private framework.
Sad. This is also a major problem for other scripting languages. They all can only run in interpreted mode. Which might be good enough but is never the best you can get.