Disappointed over bad communications!!!

Discussion and feedback on Construct 2

Post » Wed Apr 15, 2015 9:16 am

@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.
B
7
S
1
Posts: 41
Reputation: 572

Post » Wed Apr 15, 2015 9:58 am

@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.
B
18
S
7
G
1
Posts: 783
Reputation: 4,237

Post » Wed Apr 15, 2015 10:23 am

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...
Last edited by Colludium on Wed Apr 15, 2015 10:33 am, edited 1 time in total.
A big fan of JavaScript.
B
74
S
20
G
69
Posts: 2,205
Reputation: 43,832

Post » Wed Apr 15, 2015 10:30 am

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...
A big fan of JavaScript.
B
74
S
20
G
69
Posts: 2,205
Reputation: 43,832

Post » Wed Apr 15, 2015 10:44 am

@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?

Colludium wrote: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.
Scirra Founder
B
395
S
231
G
88
Posts: 24,367
Reputation: 193,684

Post » Wed Apr 15, 2015 10:51 am

@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.
A big fan of JavaScript.
B
74
S
20
G
69
Posts: 2,205
Reputation: 43,832

Post » Wed Apr 15, 2015 11:44 am

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?
B
7
S
1
Posts: 41
Reputation: 572

Post » Wed Apr 15, 2015 11:57 am

mercedescolomar wrote: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..
I told my dentist I had trouble with my teeth and asked her to fix it without looking in my mouth..
B
54
S
16
G
8
Posts: 6,160
Reputation: 19,775

Post » Wed Apr 15, 2015 12:02 pm

mercedescolomar wrote: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.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Post » Wed Apr 15, 2015 12:22 pm

@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.
B
7
S
1
Posts: 41
Reputation: 572

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: Jayjay and 10 guests