AppMobi or PhoneGap ?

I've seen several posts about appmobi. The talks on this subject was long, many users commented on this issue. These posts have been posted some time ago, so I want to refresh the topic and ask for advice of those people who already have experience in this.

PhoneGap. We don't officially support AppMobi yet.

Edit 28th Jan: now we do support AppMobi :) Sound works better on AppMobi, so that probably tips the balance

delgado, Some users have reported that AppMobi gives a little performance boots and sound works, But i have not tested this myself yet. And there are no step by step instructions if your a beginner.

As soon as i have a prototype to test it with then im going to write a tutorial on it.

I think the performance boost from AppMobi was because it scaled the screen to a lower resolution, probably making the game look worse. Since both AppMobi and PhoneGap work the same way (they use the phone's browser to run the game), they probably have identical performance, but you might measure a difference depending on what resolution they use.

Ashley,

Honestly I wouldn't mind the fact the screen is scaled so much. I make my graphics with a high DPI so its not going to be exactly notable.

Also if the native phonegap export in C2 doesn't get Audio working then AppMobi is the only alternative really, Right?

Hey Ashley,

Ian from AppMobi here - You are incorrect on your assumptions. We do not get "speed performance from scaling down the resolution".

We get speed performance from layering off the canvas calls and using an OpenGL layer. We attempted to explain this to you in the emails about possible integration.

For everyone else, the way DirectCanvas works is we have two "webviews".

1) Normal AppMobi Webview (phonegap would be the same)

2) DirectCanvas webview. This uses javascript core to translate the calls to OpenGL. <-- That is where the performance gains are.

We have a bridge to communicate between the two, but the DirectCanvas webview isn't a normal webview. We have a fake DOM in there, but support is minimal. We implement some of the html5 canvas calls (not all).

This is a short version of it. Here's a slide our CTO did at

NewGameConf

ian - we still don't support DirectCanvas because of the complication of the second context in our engine. I didn't mean to imply AppMobi is slow, it's just a possible reason a user may have seen a slight performance improvement over PhoneGap when both are using a non-accelerated canvas.

I really don't understand why you have two javascript contexts to use this. Are you guys planning on making a single context version? It would be far, far easier for us to implement and that's really important to us when we're a tiny two-man company already working round the clock. For example, when writing WebGLGap all the WebGL calls are made from one context, which means existing code can be used virtually unmodified. The WebGL calls are just saved and passed to a separate rendering thread so rendering doesn't hold up the game code either. I thought this design would be sensible for DirectCanvas to maintain high compatibility with existing code while still minimizing performance overheads.

Hi Guys - this is Sam at appMobi jumping into the discussion a little late.

IMPLEMENTING DIRECTCANVAS

For earlier readers of this thread - implementation details for directCanvas can be found here:

appmobi.com/documentation/index.html

We'll follow-up with new/better versions of the implementation guides as we get get feedback and experience through more engine integrations.

Ashley I'm playing around with converting your engine in my spare cycles (though I don't get too many of those unfortunately - so it's not going to be the quickest process).

To answer your question "why have two contexts?" - the answer is simply that there would be no performance gain. The primary problem is the DOM and re-flow render code of the browser. The Canvas element is still a DOM element and so moving any other element causes a recalculation of the Canvas and it's contained elements. The secondary problem is that to extend the capabilities of the webview you need to have a JavaScript to Native bridge of some sort. On iOS that bridge is essentially a string parser on the native side that reads in javascript strings that are passed to it. Frequent drawing calls would therefore have an offsetting negative impact to rendering outside the DOM.

We have the syntax in place to invoke methods in one context from the other - so could you do something similar today to what you do with WebGL? There answer is yes, but there is the previously mentioned string parsing hit when crossing from the DOM to the directCanvas execution context.

With regard to implementation - my (very) cursory understanding of your code leads me to believe that the conversion to use directCanvas would be relatively straight forward. What I'm playing with is moving everything to the directCanvas context. It doesn't look like you use the DOM extensively so this might not be too bad - but, like I said, I'm just getting into looking at it seriously. For compatibility with standard/desktop browsers we have a directCanvas javascript shim that will transparently work when the dicrectCanvas acceleration is not available.

Anyway, once I look more closely (say next week or so) - let's have a quick chat to sync-up.

Thanks for jumping in appMobiSam!

Our engine is canvas-only, it doesn't do anything visual with the DOM apart from draw to the canvas so reflows shouldn't be a problem.

Also, surely the overhead of stringifying from the webview to native isn't more than the overhead of stringifying to the other context then calling eval()? Do you have performance figures comparing the two? I didn't think there would be much difference between them, but then again WebGLGap didn't work out so well :) Anyway, that's why I've been thinking a single context approach makes much more sense, but that's just from our point of view.

Most of the difficulty of porting comes from lots of little things, really. There are already a lot of games in Construct 2 and even dropping little features breaks some people's games. For everything to work the game needs to know the image dimensions, but only the directcanvas layer needs the actual image. My first naive port of everything-in-directcanvas didn't work, presumably because there are a few DOM references that throw it off. Besides, the three input plugins assume a full DOM is there, Browser and Webstorage assume they're in a real browser, and Button and TextBox are real DOM elements too. DirectCanvas didn't look like it had anything to draw text with, which is no worry - we already overlay a 2D canvas for text rendering in WebGL mode - but then our renderer has to be half-and-half DirectCanvas and WebView. If DirectCanvas doesn't support patterns or texture co-ordinates we have to do something different for tiled background. etc. etc. We'd love to get it working but it seemed to be a lot of work (I never thought I'd have to munge some of the engine in to another context) and we're already knee deep in other projects so I was trying to persuade you guys to do a single-context version! :)

FYI our next release (in about a week) has some minimal tweaks to export an AppMobi-aware game, but it's probably not much different to what you've already done in testing.

It would be great if we could get appMobi speed with our C2 creations

Now construct 2 support appmobi :) So what i must do to make a game with appmobi?

I know phone gap but no this second way ;/

delgado here is a getting started tutorial:

Tutorial- Getting Started

It's not to technical just a lot of steps.

We'll get some proper tutorials written up at some point, but basically you paste the exported files over an existing project in AppMobi then click 'reload project'.

Sorry for the question , but there are a lot of information, not easy to understand for me as newbie and non english speaker. <img src="smileys/smiley9.gif" border="0" align="middle" />

Therefore Please correct me if I'm wrong .

I export the Export Folder to my server, then I copy all the files and paste these over an existing AppMobi-project? Nothing else?

create appmobi project in xdk, from there open the project folder and remove every file from there, then move all the files exported from construct into it (not the folder that was exported, files from it, so the index.html file is in the appmobi project folder) and that should work.