Concerning tests

0 favourites
  • Before I go ahead and crack down and make the purchase I threw together an objective app to test C2 performance on IOS. I got an average of 4 FPS, with 13 objects. And that's simply a background, no input, audio, physics, player objects. Furthermore the scale to fullscreen isn't working (I built it for iphone 5 resolution and it should scale down to the other iphones/ipods). With results like these I don't see how I can use this awesome software to accomplish my results. I'd put up the source and ask someone to export it to phonegap or appmobi or cocoonJS but I feel like that will violate some term or something (Can I do that?)

    So here's the test: Test

    What are your mean average frames?

    Can my concerns be addresses and (hopefully) put to rest?

  • I got an average of only 24 fps on a powerful desktop machine

  • Your first average is entirely pointless and it messes up your test, I got a steady 60 FPS for the entire thing � except of course on start up because every game has a low FPS at the start.

  • You may also want to try cocoonJS or phonegap or any of the available wrappers to make native app rather than web apps, the support of HTML5 web app is not very good on mobiles.

    60fps in my FF on a powerful desktop machine.

  • Your fps problem is probably because of overdraw. You have a ton of it going on in the test. Overdraw is when a pixel is drawn more than once - for example how the black squares are on top of the background. Due to how graphics cards work, first it draws the background, then it draws the black square on top of it, therefore drawing those pixels twice - and in your tests, then the one on top of that, and the one on top of that, which results in most of the screen being redrawn quite a few times.

    Mobile hardware is far weaker than desktop, especially when it comes to pixel fill rates (the number of pixels a graphics card can draw in a 60th of a second). I read somewhere that on average devices can currently only draw 3x the number of pixels on the screen in that amount of time. If you take that into consideration, I'm quite confident you can increase the framerate dramatically - it did wonders for the game I'm working on.

    For reference, I get 23 fps on an ipad 3 in landscape mode, and it goes up to 33 in portrait - because it's drawing less pixels. An iPhone 4S goes from 41 to 60.

    Also, what device and os version are you using? iOS 4 had utterly terrible HTML 5 performance. iOS 5 increased HTML 5 performance by something like 2000% and then ios6 improved it about another third.

  • I'm getting screen tearing with a low of 28FPS with an average of 38 and a high of 49 on a machine that can destroy Crysis and running the latest version of Chrome, it's not C2, it's your event construction.

    Recent web-apps I've made run at a solid 50+ FPS with physics objects, 10s of sprites on screen, platformer object and multi-touch controls in an un-optimised full screen mode; on an iPad 3.

    As Arima said, overdraw looks to be the big issue.

    EDIT// Repeated reloads dramatically boosts performance.

  • It runs a perfect 60 FPS on Chrome here and 23-24FPS landscape on an iPad 3 as Arima also found. It looks like it uses very large textures which is likely to cause poor performance on mobile. For example the red border and the stars in the background are both full screen size textures, which like Arima points out will cause full-screen overdraw twice when you could simply have had four small red objects around the edge and lots of individual small star objects placed across the layout. That would probably reduce your overdraw by 40% already for an easy optimisation.

    I think it's unlikely this type of thing would even run well in a native engine. It's all hardware accelerated and drawing on the GPU so it probably wouldn't actually render faster in a native engine. Mobile devices just have *much* weaker hardware than desktops and you have to be careful not to throw too much at them.

  • Mac: Safari 60 fps, Chrome 50-60

  • 56fps in Chrome. Dell i5 laptop.

    Very interesting info regarding overdraw. I was only thinking in terms of object counts and sizes before. Thanks Guys.

  • Thanks everyone for their replies, I am testing on a 4th gen ipod touch, IOS 6 and a very powerful pc. I took into account all your response and information an reworked it. Now the only thing occupying the screen is the black gradient bg. The sacrifice for this of course, is many, many, more objects. With the new project, I saw almost worse performance, as the system is trying to spawn new objects and move them all so much. Look at many other apps and they can accomplish this style of background fluidly. I am still unclear as why it will not scale properly. I do not see this being a viable development platform for any game of this style <img src="smileys/smiley11.gif" border="0" align="middle">

    Here is the new project:here

  • Can you post a capx? I'm getting 60fps on both my iPhone 4S and ipad 3.

    It appears you still have a lot of overdraw going on - completely transparent pixels around the planets and such still take gpu time to draw. Also, is your border a full screen image as well? That would be 2x the pixels again. There appears to be tons of objects offscreen right that are unnessecary.

    Can you post a .capx? That would make it easier to see what you're doing.

    Also, of note there was a significant jump from the iPhone 4 to the iPhone 4S, which CPU is 2x faster and gpu is 7x faster.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • <img src="" border="0" />

    Just post .capx we will see what is the problem, i've made a game which uses continous scroll background without bug and i get 22-31 fps on my iPod touch 4

  • On my ancient Sharp ADS-01 using Android 2.2 and the stock mobile browser I'm still getting 10-14 fps on that second project.

  • Does a coloured background layer count as a "draw" compared with a full texture, in respect to overdraw?

    For example, we have a static background image for a small layout (480x800) which is composed of half a screen of pictures at the bottom and then largely 1 blue colour at the top (i.e. sky) with a few additional images in the sky.

    The options as I see it are:

    1)Using a blue background layer and overlaying half a screen of pictures at the bottom. Would this count as the first draw or a second draw in addition to the blue?

    2)Using a tiled blue on a transparent background with some overdraw where the jagged pictures overlap.

    3)Using one full background image on a transparent background, being only 1 draw but with the need to load a larger texture into RAM.

    Number 1 seems the best good option, but not if it causes half a screen of unnecessary overdraw.


  • That will result in overdraw where they overlap, yes. Option 3 is the most efficient for the rendering process. You could also use option 2 and try to reduce the amount they overlap as much as possible. Also remember to set 'clear background' in the project's properties to no, as that takes up draw time too.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)