I need your help to figure out Airscape's performance issues

0 favourites
From the Asset Store
Game with complete Source-Code (Construct 3 / .c3p) + HTML5 Exported.
  • Hi everyone!

    I'm a little bit at the end of my rope when it comes to performance problems in my game Airscape.

    Here's where I'm at currently:

    • On any machine without a decent dedicated GPU, when the game isn't at a tiny resolution, the game runs like trash (This is unclear, but I'll get to it in a moment.)
    • The performance problems are definitely caused by a GPU fillrate bottleneck. If the window size is small enough, it runs perfectly, even on integrated graphics setups.
    • The FPS doesn't actually drop too low (at least in Chrome.) On my integrated graphics tests, the game drops to about 30fps at 1080p resolution. This FPS should be perfectly playable.
    • In Chrome (and subsequently NW.js, my export platform for Steam etc), the game is unplayable at any FPS below 60 when fillrate bottlenecked. This is due to severe jank and input latency.
    • Ah, I mentioned jank! Well, I don't actually think this is directly related to this famous issue, as this seems to be strictly fillrate related, includes input latency, and only effects sub 60fps framerates.
    • I've found that Internet Explorer (?!?!?!?!) handles this issue better than Chrome. This is pretty shocking.
    • Even more shockingly, in my limited testing, disabling webGL only had a relatively small performance impact. I have no idea if this is even related. I might do more testing with this but it's a bit finnicky as there's no way to enable/disable webGL at runtime.

    Anyway, nobody wants to hear me whine about the issues I'm having! I'm looking for solutions, and that's where I need your help!

    So, first of all, I've submitted a Chromium bug report. It would be fantastic if you could take a few seconds and star this issue so that Chrome will at least have a look at it. I've talked with Ashley about this being a C2 issue but he's assured me that C2 doesn't handle stuff like vsync and input latency.

    If you'd like to be a bit more helpful, I'd encourage you to try the stripped-down demo for yourself (especially if you have a weaker machine) and post your thoughts and results here and/or on the Chrome issue. Be sure to mess around with the resolution in esc>options>settings>video.

    Also, it's totally possible that I've made some sort of mistake, or that there's something I can do to negate this issue. (I should clarify that I'm not asking how to reduce fillrate by reducing shader use etc, but to get a better performance with a given fillrate.) Anyway, if that's the case, or if you have anything at all you think might be valuable in my case, please do let me know.

    Thanks for your time, I really appreciate it.

    Daniel

  • All I could suggest is starting with the minimal amount of textures you need, and measure from there.

    30 seconds to load the demo.

  • I have no idea what's going on, but..

    [quote:2njy0709]Even more shockingly, in my limited testing, disabling webGL only had a relatively small performance impact.

    WebGL in itself isn't faster - it's only faster if it's hardware accelerated. If you are rendering WebGL in software it will be awfully slow. So maybe your issue arises from WebGL-contexts that fell back to software rendering for whatever reasons?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • newt it takes ages to load the demo because I left a lot of the game assets in (as it's a total pain to delete every object from the project that's unused in this specific level).

    AFAIK fillrate has nothing to do with loading, or image memory, anyway.

    Eisenhans non WebGL is still a fair bit slower, just not as much slower as I expected it to be. I very much doubt that it's fallen back to software rendering, but just to check, is there a way to tell?

  • Bit of a mixed bag, when the demo loaded I hung around 40-45 FPS for about 30 seconds, before hitting a steady 59, never hitting 60.

    When I hit fullscreen, the game instantly hit and stayed at 60, dropping to 57 infrequently.

    The real change came when I went into video settings and changed the resolution from 1366x768 to auto, which I assume uses the native resolution (in my case 1920x1080).

    After this the game tanked - dropped straight to 30 FPS, then up to 49, 56, 50, before settling at 46. The strange thing is that 46 FPS at the auto resolution is far worse than 46 FPS at 1336x768.

    Specs - AMD A8 6600K APU w/ RADEON HD8570D. APUs aren't super common, but it shouldn't be having trouble with a 2D game.

    EDIT//

    Fullscreen adds a solid 6 FPS to my auto FPS, jumping to 54 - it's pretty steady too, and definitely playable.

  • Elliott well, that's the first time I've heard of fullscreen *adding* to the fps. Usually fullscreen makes it a lot worse for me. Ugh, there's *another* rabbit hole ._.

    46fps at auto resolution is way worse than 46fps at 1366x768 - that's what's super weird and frustrating, and must be an issue on Chrome's end. Did you test on any other browsers by any chance?

  • on my pc:

    Intel Core i7-3770k 3.500GHz, 32GB RAM, Geforce GTX 780 it behaves all the same on every possible resolution setup with fullscreen on / off.

    Game stays at 59-60 fps when not moving or moving very slowly (pressing arrow keys from time to time) - here it's fine, nice, smooth and all

    but if I start moving around (hold arrow keys) game drops down a bit and stays between 56-58 fps and it's not nice to play anymore. Basically it looks like watching a movie from very old and scratched dvd disc. Keeps pausing for a friction of a second every 2 seconds. I did not noticed any input lag or other issues, only these regular janks when fps drops below 59.

    Could you provide similar test game but exported with NW.js ? just to compare if it's the same behavior.

    EDIT: Tested in chrome 40.0.2214.115m (64-bit) on Windows 8.1 64

  • I should mention that the auto resolution levelled out after about 15 seconds, and after the initial swap, takes far less time to stop "acting out" (though every time I swap to auto, it does drop to 30 for a moment before going back up).

    Currently tested on Chrome - Version 40.0.2214.115 m.

    I don't actually have any other browsers on my PC, I'll go grab FF though.

  • sqiddster,

    My Laptop system: Toshiba Qosmio F60 Intel i7 M620 2.6GHz 4GB Ram, 64Bit OS. I know its a bit old.

    Just trying to give a less then top range pc result so you can see how it runs on lower machines..hope it helps.

    Firefox V 35.01 FPS: average 19fps at 1920x1080....1366x768 was about 25fps.

    Oh...totally different on CHROME Version 40.0.2214.115. With Fullscreen 1366x768 get av. 45-50fps.

    Hard to say as it doesn't Stay that way..HOWEVER, i concur..as soon as i am NOT fullscreen FPS drops

    a fair bit to the mid 30s.

    I viewed it on my 1920x1080 monitor attached to laptop, not on laptop screen. Also the window size setting i used

    were from the game size changed in options. so..Chrome seems OK but Firefox runs like a dog (whats new) and quiet

    surprised it ran this well on such an OLD system.

    Rob

    edit: Put game settings graphics to fastest,1366x768, and FS and ran in Chrome average 52-55fps..hmm..pretty good.

    Obviously Chrome and your code is optimized well, i would think.

    Is this meant for a Ipad/Tablet/Phone as well or PC only?

  • http://en.wikipedia.org/wiki/Fillrate

    Ashley

    The part about overdrawing is interesting.

    Ever think about some sort of occlusion render optimisation?

  • Just updated Firefox to V36 and using same Chrome Settings as above i now get 44-47FPS .

    interestingly i turned off the auto adjust graphic settings from auto and left it on fastest

    and on average game was more then playable. Don't know...whatever you do to make your

    games run so well I'd like to know that lol

    But i can't really fault it...slight lag sometimes but its nothing like some of the things i see

    on here. Not been a member long, officially, but have hung around a fair while and i

    think that Chrome/Firefox WILL get better...just wish it would hurry up and especially on

    the Tablets Browsers. The above was with Firefox again, if that wasn't obvious. Cheers.

    Rob

  • schmutly

    Thanks for testing! As for 'running so well' - well, I don't consider the game to be running well at all unless it's jank/latency free at a decent resolution on an integrated graphics machine like mine, which it definitely isn't!

    newt Even if that wasn't really expensive to do, it might not actually be that helpful. For example, in my game, there's almost nothing that's completely occluded - it's all partial occlusion. Even if it could handle partial occlusion, it wouldn't help at all with transparent layers.

    For everyone: FPS measurements are definitely helpful, but more helpful is letting me know what sort of jank and input latency you're experiencing, and passing that on to Chrome as a comment in the bug report.

    Keep in mind that as far as Chrome is concerned, the other jank issue has been fixed. So it's important they still know that jank is an issue under these specific circumstances.

  • Squidster - I like the demo! So, I tinkered around with the developer tools in Chrome, IE and Firefox and, due to my ignorance I couldn't find anything that stood out as a cause for the janking... at first. As you posted already there are lots of frame drops and janks aplenty in full screen. I'm running i7 16 gb with 2gb vram (intel hd4600) - heck, it's a gaming laptop and should eat this sort of game!

    I did spot something of interest when I was using the developer console - I re-sized the game window to see at what size caused the janking to start (I also found small windows were rendered very well, no missed frames etc). I noted that the game was scaled from 1280x720 and, as soon as the game window width exceeded 1280, even by a couple of pixels, the frame drops and janks started (the dt diff went from 3 to 18). With a window width less than or equal to 1280 then everything was good. So, this jank problem is, in part at least caused by some sort of up-scaling problem with c2.... A thought - are all of your images designed to give high quality at full HD or are they just up-scaled from the 1280x resolution?

  • Colludium

    hmmmmmmmmmmmmmm, veeeery interesting.

    That seems like it could be related to this issue, which I've been trying to get Ashley to look into for weeks.

    As for image resolution - it's sort of all over the place actually, since I'm very flexible with zoom in this game. I don't design the assets to look good at a particular resolution, I just make sure they are big enough to look decent. I'm curious why you think that would have any impact on the issue?

  • My observations are similar to other posters: smaller window is better, even at fixed resolutions. In chrome, on a 3570k w/ a HD4000 iGPU running win 7 x64, the highest rez I can use without dipping below 60fps is 1024x576. 1280x720 is inconsistant, any higher is very, very bad.

    Curiously, IE can only maintain 60fps up to 960x540. However, as you observed, motion quality is much more consistant, and it remains 'playable' all the way up to the maximum rez, even though the fps drops to around 30.

    What version of C2 are you exporting with? Ashley has made some recent improvements to the C2 engine, including a better algo for timescaling (more accurate dt) as of r196.2. Might help...

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