Disappointed over bad communications!!!

BasicTribe

Painful read man. I feel for you.

My question is, why does mobile performance suck so much??

Is it entirely the fault of the 3rd party wrappers?

I bought a personal license because I love the editor.

I made a very simple game, no physics, one layout, just using bullet behaviour, performance with Crosswalk 10 left a lot to be desired, Crosswalk 7 was at least playable. But I was shocked.

Jayjay

Crosswalk on mobiles can't play crappybird test in 60fps, 100% smooth, without 0 jittering. And it is just 1 bird + 2 pipes with bullet behavior.

BasicTribe

unfortunetly Scirra's approach is not professional. But hey, according to Ashley Google is very rich and they have thousands of workers, so sooner or later they will come and help us. We just have to wait a few more months / years.

I think there are some very good posts here and I share some of the frustration. I bought c2 to make mobile games after learning to use Corona SDK (a bit), but the lack of editor and writing code were killing me...

So... other mobile game dev tools encourage the multiple drawing of sprites at 1x, 2x, 4x etc resolution so there is no need to GPU scale the images to fit screen resolution. Each tick the objective is to draw, say, 960x640 pixels with no scaling work, just drawing to canvas pixel to pixel. Add in a couple of layers of objects with transparency, blend, lots of objects etc and each layer can add a draw data rate of upwards of 37mb/s of data.... A full HD display might demand 124 mb/s of data per layer for each pixel to be drawn...

So, coming from Corona it was tempting to get swept away by the promise of new tech - easily scaled images, no need to create and load a batch of bespoke images for differences resolutions, back to front renderer will efficiently draw everything... And so on.

The truth, for mobile and desktop, is that the engine seems to easily permit the dev to create a GPU bottleneck. Create a game full of scaled objects that each take up a large screen area and overlap each other - and the needless drawing of each screen pixel many times over is uncontrollable and can result in gb/s of wasted data flow as pixels are redrawn over and over again, back to front, until the final image is created. 60 times per second.

Because of the way browsers draw 2d I don't see a solution, only a continuing need to minimise overlapping objects that fill layers with transparencies that have to be drawn. Which is counter intuitive because the editor encourages you to use your imagination and create a super parallax world with scaled objects. That's not the editors fault, it's the way the browsers draw each frame.

Instead of a back to front renderer we need a front to back renderer, with camera culling and an algorithm to stop drawing the scene when/if all pixels are drawn. Something like a 3d engine that won't draw the sky in full hd detail every frame because you're actually in a room and the sky is not visible right now... Yeah, right...

It also seems that many GPUs are full of 3d loving but 2d has been relatively forgotten about. Where's the 2d acceleration option?

Long diatribe over. I'm going back to making sure I don't have to many objects overlapping and checking that hi res detail on upscale is off...

And I forgot to add that browsers don't care if a frame is dropped, and neither does the c2 engine. I think if there was an option to set an engine clock that worked then that would be a start.

I mean, how can the engine cope with a 144 hz monitor when it frame drops at 60 hz? The answer is it giddy-ups - we need a giddy-up method so each frame is considered important, because we're making games and not online forms.

Edit - I know, the above is actually Google/Mozilla/MSN controlled and our games cannot dictate their own render clock...

BasicTribe - I just don't know what to do! I have asked for a .capx and performance measurements, so I can do testing, profiling and comparisons on a range of mobile devices in our office. You wrote a very long post but did not include anything I can test on mobile: only compiled versions of a desktop game (which didn't seem to be interactive, but otherwise ran fine), and screenshots and a video, which aren't helpful for me (I need to be able to run profiles and test on mobile devices). So I really wanted to try and help by examining your project but you don't seem to want to cooperate. I regularly test a wide range of devices and I have never seen such severe performance issues as you describe. This is what I was talking about: people complain bitterly and make it impossible for me to help. What am I supposed to do about this?

Instead of a back to front renderer we need a front to back renderer

I've investigated this, but it's very difficult. Any image which contains a single pixel which does not have an alpha of either 0% or 100% cannot be drawn front-to-back, since its correct rendering depends on being rendered on top of the things underneath it. If a project contains mostly images which have alpha, then a front-to-back renderer will still be forced to render back-to-front. Even a single image with alpha will interrupt the front-to-back flow, forcing it to render back-to-front everything which that image depends on. This is very complicated!

3D games do use front-to-back rendering which is one reason they can run so well in comparison to 2D games. A well-designed 3D game can actually use a lot less fillrate than a 2D game. The fact 2D games very commonly use alpha blending in images is quite a difficulty.

Ashley, I'm going to risk exposing my limited knowledge here... Is there scope for setting alpha masks for transparent objects somehow? A big change, I know, but if you can define what not to draw then the alpha problem might be manageable.

Nobody has answered my question and I'm genuinely curious.

Why is mobile performance of C2 games so bad? Is it the fault of the HTML5 wrappers?

Nobody has answered my question and I'm genuinely curious.

Why is mobile performance of C2 games so bad? Is it the fault of the HTML5 wrappers?

The simplest answer is:

Mobiles are far less powerfull than desktops and to get good performance on mobile a game/app needs way more optimisation.

It will take a lot of bad programming and bad use of system recourses before a desktop gets into trouble.

Mobiles on the other hand, having less power and recourses, are far more likely to get into trouble when processor-time/graphic-abilities are mis-used.

The biggest challenge of programming is working within limitations and making it appear there are none..

Nobody has answered my question and I'm genuinely curious.

Why is mobile performance of C2 games so bad? Is it the fault of the HTML5 wrappers?

Partially, users are partially faulty but wrappers in their current state are not that great, it was also hinted that it could be because C2 games runs only on one core, but that is something I am not sure about, more profiling tests and comparisons between wrappers and browsers would be nice to have to awnser that question exactly.

LittleStain

"The biggest challenge of programming is working within limitations and making it appear there are none.."

Very true, however, said limitations seems pretty blurry at the moment, which does not help as two systems can react differently while having the same type of hardware, and sometimes a better hardware will not support correctly something, hard to define the limits and so, to work with them.

LittleStain

Thanks for the reply, but all that is mostly obvious, at least to me. But some here are talking about a very basic crappy bird clone that can't run smoothly.

But like I said above I made a very simple game, no physics, one layout, just using bullet behaviour, performance with Crosswalk 10 is awful (little better with 7).

It only has 32 events and I can't optimise it any more. This is tested on a Note3 and S4.

Very true, however, said limitations seems pretty blurry at the moment, which does not help as two systems can react differently while having the same type of hardware, and sometimes a better hardware will not support correctly something, hard to define the limits and so, to work with them.

I agree, the limitations could and should be a lot clearer and more predictable.

"Build once, publish anywhere" is too bold of a statement at this time.

for me a a single sprite with bullet behavior is jerking on PC and S4 using CHROME!

if chrome has some / lot bugs as mentioned, i wonder WHY the perfered exporting way is to use Intel XDK and Crosswalk, which is also based on Chrome!?

capx:

http://www.floerl.cc/jerk_bullet_on_Chrome.capx

[quote:tqhjnv27] wonder WHY the perfered exporting way is to use Intel XDK and Crosswalk, which is also based on Chrome!?

Chrome being bad is.. new. It's something that happened over the last 2 months. Before there were sporadic problems, but they really came down hard.

Also there's still no better alternative.

I think it all went wrong with chrome 37 in Aug 2014 and it hasn't fully recovered yet. Begs a lot of questions about how Google's hundreds of engineers actually test what they've done, but here we are.

I love C2, and really feel scirra have created an awesome product.

But sadly as it stands it seems that C2 is a prototype/learning tool - at this stage there are no export options that produce satisfactory results for serious game development - or at least that how many of us feel.

Chrome is now a bug - don't use it!

To address the constant barrage of performance complaints I really feel that scirra needs to build a real world game with their own product.

This will provide at leaste three benefits:

A showcase game that demononstrates the power of C2. An example/model of how to use this tool effectively/correctly. An opportunity for scirra to see what issues are faced in a project with more than one layout and a few events.

If anyone can make a game that works with satisfactory results with current exporters, scirra can!

If scirra can pull it off - then it will be proof that the product is fine, the exporters are acceptable, and all the complainers just have to buckle down and learn to use C2 properly. However I suspect that the end result would be as frustrating for scirra as they are for the developers of the shiny examples on the scirra home page.