The sad truth of Construct 2

Discussion and feedback on Construct 2

Post » Mon Feb 11, 2013 1:33 am

Hey, someone should start a Kickstarter thread with a poll. This definitely sounds like something that can help C2 in the long run.
B
10
S
4
G
3
Posts: 46
Reputation: 3,036

Post » Mon Feb 11, 2013 1:36 am

I'm glad Scirra saved us time a lot to use HTML5 games for moviles with CocoonJS using screencanvas which it improved performance A LOT, sometimes my games were 40 fps without screencanvas, otherwise all games run in 60 fps, as native performance, it was awesome and satisfied me! :D
B
96
S
25
G
20
Posts: 3,055
Reputation: 22,646

Post » Mon Feb 11, 2013 2:25 am

No one is arguing that HTML5 is or will ever be exactly as fast as native, just like no one would argue that Java is as fast as native machine language code on a PC...

However, advancement in the interpreter, the hardware and the developers for Java has allowed for the platform to perform so well that the consumer can't tell the difference between native compiled binary code and interpreted code. 60 fps in one is the same as 60 fps in the other. You claim HTML5 is a failure. Lots of people claimed Java was a failure as well. (there are plenty today who still hold to that...it's their opinion and they are entitled to it.) I disagree. I see it not only as the next Java, but as a superior platform to Java in almost every respect. And as hardware advances, vendors adopt and adhere to the standard better, and as the standard itself evolves, I believe it will be one of the best platforms to develop on as we move forward for the next decade or more.

Is HTML5 there yet on your mobile platform of choice? Apparently not. That's a shame. I can understand your frustration and desire to be at the tip top in that market.

But that isn't the only market served by the C2 IDE. I did not purchase my licence to develop mobile apps. I like the ability to export in a way that would let me move some of what I write to mobile, but that's not my primary use of C2. I live in a Nevada casino town, and I'd be happy to lay odds that I'm not in the minority there.

This leads us into a conundrum: You want the IDE to operate in the best way for you. I want the IDE to operate in the best way for me.

If Scirra decides to stop working on enhancing their game development tool that currently can be used across multiple platforms in it's current state and instead focus on making their IDE optimized for a one specific native language that means that only a percentage of people are getting benefit for the man hours they are putting into their product.

The fact of the matter is that C2 has a "*" next to the mobile export on the website. It's not a native compiler. I bought the product with that in mind. I want them to develop the IDE to make it even better for making games. That's what I bought. It exports to HTML5, the platform that it's advertised to export to. That's what I bought.

That is also what YOU bought. I'm sorry that you bought the product thinking it could do something that it's not billed as directly doing. Does it meet your performance goals right now? According to you, it doesn't. Does it export and run, through CocoonJs, on the platform you wish for it to run, regardless of the performance? Yes. It does.

You have gotten what you paid for. Scirra could have every right to not even try to make ANY enhancements from there, but they choose to devote a proportionality equal amount of time on your desired platform while trying to work on EVERYONE ELSE'S desired platforms as well, fix bugs, and add new game making non-platform specific features to the IDE.

Personally, I think they would best be suited on just working on IDE features to make the games in HTML5 the best they possibly can and leave any other exporting to 3rd parties. That would be spending their time to the benefit to the most people who have purchased their product, but that's my personal opinion and it is the path that would suit me the best, so I'll admit to being biased.

Actually, I'd love to see a survey of license holders as to their primary development platform. If the majority use C2 to develop for iOS, then by all means, put the time into making the iOS export as powerful as possible. If the over whelming majority do so, then I'm all for dropping all other work on the IDE (except bug fixes) to make the HTML5 export work as flawless as possible with iOS.

I do not support, however, 1st party native export. I didn't buy an iOS development tool. I bought a HTML5 development tool.
B
26
S
8
G
3
Posts: 210
Reputation: 5,973

Post » Mon Feb 11, 2013 4:08 am

Personally the time saving advantages that C2 offers far outweigh the problems of HTML 5. I would just work around the problems.
B
69
S
11
G
6
Posts: 324
Reputation: 8,321

Post » Mon Feb 11, 2013 5:28 am

@purplelava

Check your PMs.Arima2013-02-11 05:51:06
Moderator
B
88
S
32
G
33
Posts: 3,005
Reputation: 27,432

Post » Mon Feb 11, 2013 5:39 am

Wow 8 pages of the same thing.
Ok well perhaps not exactly the same thing, its going down hill apparently.

How about if you don't like whats going on, just move on and make your own engine.
C2 is pretty much just one guy doing the programing.
Image Image
B
161
S
48
G
91
Posts: 7,359
Reputation: 67,273

Post » Mon Feb 11, 2013 5:57 am

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.
https://play.google.com/store/apps/details?id=com.edburnette.fps2d&feature=nav_result#?t=W251bGwsMSwxLDMsImNvbS5lZGJ1cm5ldHRlLmZwczJkIl0.



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 https://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 :)

jayderyu2013-02-11 06:15:24
B
87
S
18
G
9
Posts: 2,455
Reputation: 14,834

Post » Mon Feb 11, 2013 7:10 am

WOW, thanks for all the testing, that hopefully will show some of the nay sayers where the limitations actually are. Construct is not the issue here, it is the browser and platforms being so disimilar and even those that support similar features not implementing them the same way.... Now I just need to see IE10 on Windows 8 and Windows Phone 8 so I can see how my targeted platforms perform...BluePhaze2013-02-11 07:12:08
B
49
S
11
G
10
Posts: 1,833
Reputation: 14,428

Post » Mon Feb 11, 2013 9:11 am

This tests are interesting
B
11
S
2
G
2
Posts: 53
Reputation: 2,244

Post » Mon Feb 11, 2013 9:47 am

@theubie

I'm personally not complaining about my purchase, I'm an early adopter and I would buy it again. My point is that it's simply a shame having such a powerful tool tied to a (and you are right this is purely my personal opinion) failed technology and I'm not the only one to think this way.
B
29
S
9
G
6
Posts: 525
Reputation: 8,294

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 16 guests