Wouldn't have made the purchase if it was free.

i don't right now, but my next game I will. I also listed the Hydra achievement board and Ouya ODK. Also I did mention monetization through Ouya is a must. Which I can't access through HTML5. So it's really not just about Steam.

I think this thread has been fabulous a lot has come out of it :) As an example I'm still a naysayer, but I drove me to do the performance testing with different settings. Result was that i was able to increase performance by a lot. Also I went about going through different websites and found some interesting facts.

Canvas rending SUCKS. Even Cocos-x on android isn't all that good. While we are annoyed with 20fps issues they are having troubles with 30fps issues with the same sprite circumstances. There are gaming blogs that report game design considerations once you hit more than 30 sprites. With that part of the problems lay in the Tegra 1 and 2 where any transparent rendering has flaws which also drops performance.

What however changes is oddly enough OpenGL 3d based rendering. Strangly enough a full on 3d engine doing 2d can render 250 sprites animated at 30fps on a Tegra 2. I'm not sure why the difference or what's going on. but it is insightful. None of this would come to light if discussions aren't there.

Now to something important which I don't think the HTML5 choice will ever get over. Which is the other problem. Let's remove the entire performance speed issue. let's assume we are in happy land :) heres the problem

hydra.agoragames.com

devs.ouya.tv/developers/odk

anything that is native code access

even the day HTML5 becomes this great at gaming. We can't access Steam Achievements. So there we go. Completly reliant on CoocoonJS which is closed platform at this time. Though apparently CoocoonJS has an extension manager in the works. Till that day :(

I have no idea how to monetize my Ouya game for a sale. I can't access the Ouya store. If I use Clay.io and am allowed to sell the game. this will require users to enter in the pay system by another method and well people don't like that :(.

I'm still a naysayer, but I'm willing to put performance to rest for now. I feel I can pull enough performance out what there is right now for my games. Though that doesn't change other factors :(

Anyways I thank everyone for speaking there minds and having an opportunity to speak my mind. Also Ashley participating and giving us a lot of company making decisions :)

as a final note on that however. I still think Scirra should do a kickstarter to gain funding for a 1 year staff to make the Exporter Development Kit. Once that's done. just let the community do the rest and Scirra can stay hands off towards maintaining. As Ashley pointed out Chrome was a communal developed project from many different code snippets and improvements. The EDK's exporters and plugins could operate under the same standards. Scirra can stay hands off past that entry point. But hey. That's it for me.

I hope many of you have learned as much s I have :)

Well a couple of things I should note.

The tutorial was created before ForID. The D&D behaviour was a requirement at the time. You can phase out the D&D behaviour and instead rely using ForID. The tutorial will be updated to reflect this when I have more time.

Here is the fix.

dl.dropbox.com/u/14087254/spaaaaaaaaaaace.capx

oh. I did some fidly for testing. If I missed anything I'm sure you can fix it for mobile :)

For Android, make sure to use the Letterbox scale integer. Also check your devices resolution and available screen size. 800�480. part of developing mobile is that C2 scales to the aspect ratio. If your game is on a different aspect ratio it will lead to blank areas.

Often the best idea is to create your game play and layout at a higher assumed resolution. Then change the viewport as needed.

Personally I tend to use an art program to create advances looking text. Makes life easier.

Thanks for the link to Spritefont plugin. I was thinking about this the other day.

well you could use primary pre created shapes then pin them together as needed. If you need more detailed graphics looks I suggest Rojohounds Canvas plugin.

however there is no way to dynamically set collision shapes. So you can go back to the primary shapes again :D

Wow, some really insightful posts.

Thubie, when I bought C2 the '*' wasn't part of the information on the main page. There was a very strong push that HTMl5 games will run at native performance. This isn't true and i didn't expect to really run near native performance. Just good enough. I would like to see a poll on this also.

purplelava, wow. I totally understand where you coming from, [snip due to post being removed] I do agree with this sentiment however

"C2 effectivly makes 'casual' games, yet is only effective making desktop games. Where as desktop games offer robust games which mobile is a harder"

Personally I don't believe the term casual and hardcore.

I will also chime in. I'm still good on a kickstarter program to support Scirra or another to create exporter or an effective native running of games.

kondisius, I still agree.

Ok going on to my own thing. i decided to take up Ashley's un worded challenge that we need to be better game developers. ie it's logic, sprites, poor performance options. So i wrote this while working on meeting Ash's challenge and came up with some serious surprises.

------------------------------

After repeatedly hearing from Ashley that our logic and games were at fault. I decided to take up the challenge that a minimal no event logic game will have poor performance on my Tegra 2 android device.

I started by searching for an android demo program to determine capable FPS on my tablet. I found the app FPS2D. The simple result was that the FPS was 60fps with a deviant of up to 8fps. FPS2D had an empty black background with what looked to be apx 8x8 ball. This would be the standards of my C2 test for UIWebView.

play.google.com/store/apps/details

So my demo was going to be a black background with an 8x8 bouncing green ball. The ball has the bullet behaviour and will be colliding with solid's that are just on the outside of the layout. This technically adds a little more overhead for collision. Here are my tests and I want to point out one of the results was outstanding. Also test results resizing was not clean due to browser. So some tests were not "fitting" screen right". I also err on the lower side of the deviant results(so if fps was 12-15, 12 would be the reported value)

*due to the header bar and resolution often the the view-port would be rendered off screen. This could be the the cause of many slowdowns.

*Pixel rounding on

*clear background with a single layer, black colour

*as a note interger scale would product a very small view of the game which is probably why speeds were goo(follow up commentary on this at the end)

*test capx dl.dropbox.com/u/14087254/ballbouncetest.capx this was often modified to suit the test resolutions. so it's not a straight go to use for multi res. But I'm sharing to show the simplicity of it. So that there is no question on our design logic.

*since most developers want to pack there game. using browsers is not ideal solution. however they were tested to have an idea how there canvas2d runs.

*2 Apple devices were added.

Here we begin--------------------------------

*fps format(no scale, crop, scale, letterbox, letterbox integer)

FireFox(webgl)

FF with WebGL by far had the worst results right across the board. Don't waste your time right now.

480p (12,5,5,5,12)

720p (5,5,5,5,15)

1080p (2,5,5,5,8)

FireFox(canvas 2d)

480p (65,22,20,22,45)

integer: There are dips as low as 30 fps, but this steadies out

720p (28,24,25,27,64) these were surprising results

1080p (12,25-50,23,27,64)

crop: was all over the place and never steady enough to report.

integer: starts slow but quickly reaches 60+

Chromebeta(webgl)

Better than FF WebGl, but overall not a better browser to use.

480p (33,27,27,30,36)

720p (29,28,28,29,38)

1080p (25,28,28,28,32)

Chrome(canvas2d)

Chrome overall had steady results

480p (33,25,25,23,35)

720p (25,25?,25,25,40)

1080p (15,25,25,25,30)

Stock Browser-------

I feel these are the key browsers as any embedded app will be

based on these

Android Stock jellybean(canvas2d)

480p (55,35,40,46,59) acceptable across the board. with rare dips

720p (35,35?,40,43,60)

integer: That came from no where

1080p (24,41,41,44,57)

integer: rendering is not smooth. it was flickering and steady

iPad2 Safari(IOS 6x, canvas2d)

as expected this performed solid right across the board. However this is running A5 Chip which is better than the Tegra2 and more comparable to Tegra 3(which is the current development chip). this offers a lot of good promise for Tegra 3 devices which I don't have at this time.

480p (60,60,60,60,60)

720p (60,60,60,60,60)

1080p (54,60,60,60,60) This is the first time it's dropping below a solid 60

iPod Touch 4g (IOS 5.1, Canvas2d)

This by far has the most strangest results. I also started testing at 720p when I thought about adding it to the test list for comparisons. Due to the strange results this by far has the most commentary.

720p (45,50,84,84,90) the results are steady and usable

1080p (39,85,80,80,105)

off: the ball was doing a lot of jumping. very far from smooth

crop: can't see much of the viewport at all, but the ball was a lot smoother

scale: 85fps with but with common dips to 75

letterbox integer: WTF????????? this actually dips as low as 95fps. however the animation was never as smooth as the ipad2. I think the iPod Touch was just blazing out the canvas renders, but logic took longer creating this less smooth effect.

Observation

After spending hours doing these tests I feel this explains a lot of the communication problems between Ashley and the vocal native part community. UIWebView does seem capable, but only under certain conditions. These conditions however strict and makes it a lot more work.

Scaling options

OFF: The results of this are across the board. I suspect the dips in performance has more to do with rendering the canvas offscreen. A canvas size that does not exceed the the window will probably have good performance.

CROP: not worth using

SCALE: Is not worth using. yet it's the primary suggested path to mobile and easiest to implement cross platform. But this get's the worst set of performance :(

Letterbox: Not worth using

Letterbox integer: This is by far the best average and reliable performance across all resolutions.

Not always the best, but never the worst. The problem is that none of my tests ever had this scale fit the screen. often it produced significantly smaller screen sizes. ideally it would be best to create games based on this scale and find a way to get games to fit.(addendum below)

WebGL

WebGL universally had poor performance. This is where Ashley is 100% correct. WebGL would not solve the speed issues for simple rendering. Advance rendering may end up with different results.

Letterbox Integer testing follow up

I spent some extra time just playing with this scale option on my tegra 2, iPod T4g, iPad2 at 720p. resolution had impact, but not as much as expected.

Android: 80 bouncing balls produces 25-35 fps

iPad2: 80 bouncing balls produces 50+ fps

iPod: 80 bouncing balls produces 50+ fps

Android+CocoonJS: 80 bouncing balls produces 50fps

This produced overall very promising results and for me acceptable for my more minimal games. 80 bouncing balls is far jump from just 1 ball from all the tests previously done. Also the results are fantastic in comparison.

However with all that goodness there seems to be a big BUT. After the promising results I decided to test out my Ouya game to the new options.

Draoust with letterbox integer

I required to do some tinkering with what I had in the game. I was able to manage to go from 20fps to 32fps in the stock browser. Which is about a 30% improvement in performance.

It looks like the end performance results to all of these testing is that there is some kind of critical problem with scaling with Android UIWebView. Performance is best on a 1:1 scaling ratio. Also make sure that the canvas does not extend past the available screen size.

Draoust with CocoonJS

Main menu runs at a solid 60fps. However there isn't much happening

Gameplay runs at a steady 50 fps with common dips as low as 45.

These results are super acceptable for my Ouya game. it's just to bad CocoonJS crashes on the Ouya. But hey come March maybe Ludie will have one to test and fix to run :)

About 80 bouncing balls

While 80 bouncing balls is a fine for common performance of I think simpler games with out lot's of effects. It by no means will compare to a native app. However it's fine for me.

When designing your game. Get your best FPS with just a simple bouncing ball. Then work up form there. Test constantly on your mobile device. If there is a sudden drop then check the recent changes you made.

I still support native exporter or an official Scirra C2 Wrapper that's community driven extensions, but for now I think I can settle where C2 is. I look forward to getting my Ouya and testing Draoust on the Tegra 3 that has similar to the A5. And maybe Ashley can check on the scaling and see if there is anything that could be done to get "SCALE" to work better. On that scaling note. I'm not sure how C2 handles scaling, but I recall reading a post last month on straktrace. The indivudual found that using CSS3 transforms on a canvas2d produced far better performance results when scaling. This might be some angle to look at :)

Grats to Apple for creating an incredible performance rendering even on the A4 chip :)

I so far cannot say which is the best model. However I can say what I did and will be trying.

my first model was to use multi pages, but I found I didn't like this at all. It seems redudant to keep on going through the load process just to see the credits. There was no speed issue, but just didn't seem so great. Works however and is the easiest to use.

my second model was to make a width or height * numberscreens. then just move the camera to the position. Works like a charm when using a single resolution. However it falls apart on multi resolution screen.s

my third try out is the multi layer. My concern though has to do with clicking on non-visible objects that C2 allows.

ut you can export Construct 2 games to native apps right? No, not really. It's just the same slow HTML5, only now it's wrapped up to look like an executable, or an iOS app, or an Android app. There is really not much performance gain to be had, since it's still just pushing everything through a browser window. The problem with mobile devices is that they just can't handle running the OS plus running a browser, PLUS running a large game inside that browser.

I have first hand experience that disagrees with this. All my games run buttery smoothly on iOS with CocoonJS. It's hardware acceleration is anything but unnoticeable.

It's unfortunate, but I will have to lean towards this. I found IOS does way better on inferior hardware than on Android.

My Android has a dual core chip with more ram, cpu power than my iPod touch 4g. however my iPod get's 120% better performance than any of the android devices.(http://www.differencebetween.com/difference-between-apple-a4-and-vs-nvidia-tegra-2/)

What's worse is that this doesn't make the situation better. In fact the single core better performance makes it all the worse. If I create a game using IOS as the hardware standard then I've just shot myself in the foot to produce it for Android. This makes development worse and unreliable. unless of course I sacrifice the cross platform. Which then devalues C2 use as a cross platform game maker.

I back up the idea of a kickstarter to fund either an official exporter or a thirdparty. I'm also willing to accept some one who can make an open community bridge wrapper to full OpenGL by way of WebGL calls and being able to program our own extensions rather than waiting for only inhouse development of Ludie. With the condition of an easy use.

i wish Scirra's forums were better :(. I only reply to not correct but to enlighten about C2 and other revelations. So these are not corrections :)

Construct creates HTML 5 games, the wrappers and exporters export HTML 5, not true native apps. If you want to create native apps for a platform then most likely you will need to use the SDK or buy the Development tools that are built for that platform. Get an objective C development tool for iOS (and learn objective C). Get Visual Studio for Windows 8 and Windows Phone (And learn C#), etc....

<font color=red>reply: Good point, however C2 project objects are platform and export agnostic. Early design of C2 had in mind to export to different native platforms. Inherently C2 still is built around this at it's core. It's just the focus has changed and become more focused and limited in scope.

http://www.scirra.com/forum/what-is-c2-structure_topic62806.html

https://www.scirra.com/blog/53/construct-2s-architecture

For now it's either

A. Go native coding for the platform

B. Accept the current state(which i'm doing, with a little grumble)

C. Go to the competition who in fact is supporting full native cross platform.

Choose the right tool for you and budget. Maybe C2 isn't that tool. :( thought I love how it works :)

</font>

HTML 5 is not a native or even a compiled low level language. HTML is not going to perform at the same level as driver level code on any platform. HTML 5 and Javascript are interpreted, procedural languages. Ranting about that fact won't change a thing. Construct is created by a two man team. The tool has specific goals and targets like writing HTML 5 apps. If HTML 5 doesn't meet your requirements, there is nothing Construct 2 can do about that. I wish McDonald's served the worlds best Lasagna which is also Zero callories and gluten free... but they don't. So that's not what I try to order when I go there...

<font color=red>reply: The sad part is the SNES can do better than C2 + CocoonJS :( Also the important part of the entire discussion isn't logic performance which is running at acceptable levels. it's the fact that performance is running closer to software rendering rather than GPU accelerated draw routines. What's worse is that CSS3 transforms(which are full GPU) have better performance than C2 due to it's use of Canvas2D.

There isn't a request for the impossible. Just a request for the old model of direction Scirra was going to take in creating the Exporter Development Kit to allow others.

I'm a firm believer that Scirra should do a kickstarter aimed at 50k to hire a developer to create native exporters. </font>

Part of game design is looking at your target platform, evaluating your game design, and using the right tools to create what you want. There truly is no one size fits all solution.

<font color=red>reply: Very true, which brings Kondisus original point

https://www.scirra.com/blog/86/gamemaker-has-no-competition-we-beg-to-differ-html5s-scalability

Scirra makes it very clear that there product is more worth it in the long run. However, it's reliance to wait on others is the biggest weakness. While YoYo Games seems to move at a snails pace they are taking responsibility to do it all. Not only that there extension system does allow developers to work in other languages for target platforms. As HTML5 has no access to native calls unless given a wrapper option.

I also want to point out that the immanent performance of Android, WebGL, IOS and all of that. Has been going since 2010. It's been 3 years waiting for WebGL to hit Android and IOS. In the mean time Apple and Google show no signs of implementing it at the embeded browser level.

</font>

If you are going to use any tool to create HTML 5 games, then you will have to get used to the limitations. Third party wrappers are not easy to create, that is why there are dedicated companies just for making them. That is what they are good at. They aren't making game design tools, they are making wrappers. Ashely and Co. aren't making wrappers, they are making game design tools. Since the wrapper developers are benefited most by having their wrappers and exporters used in as many scenarios and in across as many sets of tools as possible, they work to make their wrappers work with the various tools out there. But it takes them time, even though they know their wrappers and tools better than anyone.

<font color=red>reply: very true. so this is related to a prior responce

this is why I think just a pure game wrapper(gfx, audio, control, storage) that Scirra could do, but allow the community to handle the rest as needed. I plan to tinker with the opengl es wrapper once my current game is done.

</font>

Why not spend time whining about why the browser vendors or marketplace vendors don't make native wrappers for HTML 5 apps since they want your html 5 apps on their market place. Or why the browser developers don't make the browsers all support the same accerlation features to allow for performance across all of them without the need for all these third party wrappers...

<font color=red>reply: Well you can call it whining, but after 15 years married it's more important to express concerns in a discussion. Whining is usually terse and Konidius has not been terse what so ever. He has been rather verbose, exploring and discussing the different factors that everyone has brought up :) as you are :)

The discussion is really about Scirra choice to reduce it's options. Understandably it's a staffing issue. But the overly focus that HTML mobile is acceptable, will be acceptable imminently or leaving out crucial details. HTML mobile really can't access vital long term requirements(ie no native IAP by js). Also yes it's about Google and Apple inexplicable reluctance to open the WebGL doors and the same for groups like Ludie not already having done so. </font>

Traditional game development meant creating versions of your game for each platform and working with multiple tools to target each one correctly. That story hasn't fully changed. While tools like Construct 2 make things easier to develop the game itself, unless Ashley and crew want to spend their full time making wrappers for all these platforms and ignore the core function of their tools which is game creation in HTML 5, then the best bet is to look at what wrappers that are out there and use them.

<font color=red>reply: This solution could be done by either creating the EDK or releasing the export_html.dll source code for third party development. I'm sure an agreeable license of use of source could be arranged. But i'm not asking for it specifically because I would prefer to avoid coding these days as much as possible. At most snippets here and there.

The hardest part is JS to other language. It could be done with some difficulty as JS is such a crappy language :( no that's not the real reason. it's due to it's flexibility which takes more effort to create a converter.

</font>

Notice that even the teams that are fully dedicated to writing these wrappers and accelerators take months or even years to get them into a state that works well for their platforms of choice, and they have much larger teams that the one working on Construct.

These are just the facts... They may be sad, but that doesn't change them.<font color=red>reply: Yep and that's ultimately why it's sad and painful. Phonegap is waiting on Google/Apple, CocoonJS has other priorities and Scirra is just letting everyone else handle mobile. </font>

In the end, your frustration is valid, but the way development in general and game development in specific works is that you use the tools that make your life easier until they've done all they can for you, then you get to work finding a solution for the challenges you face until you either get past those challenges, someone else comes up with a solution for you, or you give up.

yep, you are very right. So for now my current Ouya project is in C2. Minimal graphics I can get away with. If the game pans out a few hundred dollars. I will likely use a different toolset until HTML5 mobile get it's act together. When it does I will be jumping right back with gleeful abondon. but my game is well invested in C2 now so I will just get it working as best I can.... it would be nice if CocoonJS could at least support controllers and not crash on the Ouya :(

Being one of the those forum goers who is trying to get an Ouya game to market here is my weigh in.

Don't go for 1080p. yes the Ouya can, but many developers on the Ouya dev forums are focused on 720p(I make no claims for all or most). It's not a PS3/360 and doesn't have the power. Some teams are better than others in regard to squeezing and managing excellent tricks to get smooth 1080p

With C2 keep your games simpler; and not because C2 can't do complicated games. This doesn't mean you can't have very fun and addictive games. Take the original Mega Man series, SNES games, any 2d fighter. All of these will run fine. Also be sure to figure that your game will run at 30fps. you can get more, but with phonegap just set yourself at an estimated 30fps. however rfisher has reported I think around 50fps for some tests.

CocoonJS does nor work on the Ouya. Check with Hemel1 and rfisher. CocoonJS just crashes. Currently the options for export are PhoneGap. which has have atrocious performance. however you should be able to get by on the Ouya as it's a Tegra 3, just keep in simple and keep mobile design paramount. When CocoonJS works there will be a much larger breathing room.

This Ouya console will not be massive. Boxer8 is only starting a new brand and environment about open developers for console gaming.However the Ouya does represent a minor gold rush an opportunity for some new up and comers.

it's been made very clear that C2 will never have any other export model other than HTML5+. Because C2 is a pure HTML5 engine we have no access to any of the ODK. no IAP, Controller..... the best we can do is wait for CocoonJS to integrate these features. While it's on there list it is in no way seems on the list to be ready for release.

In the mean time rfisher said he was working on a controller feature for phonegap and hopefully if he get's that done he can implement the Ouya IAP.

If I was interested to continue programming games I would probably go with an API like Corona due to it's interest in supporting Android and IOS effectivly. I'm not and am happy with C2 game tool kit for making games and I'm fortunate that my games are simple in design.

I'm always interest in talking Ouya for anyone who wants to :)