sqiddster's Forum Posts

  • szymek that Timeline feature looks interesting. Anyone who knows more than me know if that would be useful in diagnosing the current janking problems?

  • Intel HD graphics is the most common graphics card, so it really needs to be supported, even if NVIDIA wasn't being stupid and falling back when there's a much better GPU.

  • I've definitely been experiencing these stutters and latency since well before Chrome 38. Aurel Aphrodite can you confirm?

  • Just saw this post in another topic.

    At this point in time there are 3 main reasons games don't get to run buttery smooth (as far as I'm aware):

    1) GPU blacklisting: although this is becoming less serious over time as old devices die out, it's still not too hard to find old Windows systems or old Android phones where the GPU is buggy and prone to crashing, so the browser falls back to software rendering.

    2) Synchronous Javascript compilation. While most JS engines compile code concurrently, apparently they still have some key points which still run synchronously, so block the game while it does whatever it needs to do. I think this only affects mobile, since most desktops are simply fast enough to do that work in <16ms and not drop a frame. Javascript engine improvements should resolve this, we have open bugs with browser vendors for this type of issue.

    3) V-sync quality. This is a passing issue in Chrome (the Chromium team is aware of it and are working to fix it) and Firefox (which to me looks already fixed in Nightly), and is made worse by the fact the latest node-webkit is based on Chromium 38 which has the bug. This will be fixed in due course as subsequent Chromium and node-webkit updates come through.

    This issue definitely doesn't fit in any one of these categories. I don't think this is related to the v-sync issue at all, since these issues definitely happened in Chrome 38 and before that as well.

  • No, it's nothing to do with the logic side of things, because it's purely based on window size.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I find that the problems with streaming/recording are just an extension of the problems at large, e.g. fillrate limitations. Basically, when recording, the game is more likely to dip below 60fps, even on a very good machine. Even my high-end gaming laptop can barely run the game at 60fps and record at the same time (and that's *after* going through the shenanigans with the NVIDIA Control Panel to get the game to even use the GPU!)

    These stutters/input lag have always happened afaik. I think it's a separate issue from the janking that's happening in later Chrome versions. Honestly, I don't even notice the janking amidst these other issues!

    My question is: where do we go from here? I can't in good conscience release a game in this state. It's clear that minimal repros don't show the problems as effectively as 'real games'.

    Maybe what we need to do is take some time to figure out exactly what it is in full games that makes the performance so bad. WebGL shaders was my #1 suspect, but disabling all the shaders in the game actually didn't have too much of an effect.

    In 3 years using Construct 2, it seems like it's been constant battling with browser and wrapper developers. HTML5 is great, but we're entirely at the mercy of faceless megacorporations, usually with games not even being a priority for them. This makes professional development hugely frustrating. I can't commit to a release window because I have no idea when these bugs will be fixed. I can't commit to release on certain platforms (linux) due to some sort of driver issues.

    The game is supposed to release in a few months but I'm afraid that eventually I'm going to have to delay it. Ignoring the fact that performance sucks for a lot of players, looking bad on youtube/livestreams is the worst thing a game can do, marketing-wise.

  • Yes, all these issues definitely have one major thing in common: window size (or, more accurately, GPU fillrate).

  • Yeah, Firefox is totally fine.

    What Aurel said is basically the situation as I'm seeing it too. 60fps+, everything works great. But, as soon as we start to dip below that, things start going haywire. Things like livestreams, recording etc (especially with no GPU support) can cause lots of games to dip fps, and C2 games suffer horribly. Look up any YT video of Airscape and it's just terrible. I can barely even bear to watch recordings of Airscape anymore!

  • Just had two friends test it on their machines (PC and mac), both reported ~100ms input lag.

    As I said before, it's very annoying that it seems there's no way to actually measure input lag. Is this true? or is there some way to do it?

    And yes, as Aurel rightly points out, the game looks like absolute trash visually at anything lower than 60fps. I think the official statement here is that this issue was fixed in Canary but there are clearly still severe issues. I'm still getting HUGE dt variance in Airscape in Canary. I'll try to get a minimal repro together of that in C2, since the Airscape issues are waaay worse than the issues in the demo, and I have no idea why. This seems to be a recurring issue, as Aphrodite and Aurel could also point out - real games for some reason struggle a lot more with amplified versions of the problems created by this issue.

  • In a nutshell, here's the issue:

    • In Chrome, low FPS sometimes gives very noticeable input lag.
    • This input lag only occurs when the GPU is the bottleneck. CPU lag has no effect. Specifically, it seems to be tied to fillrate.
    • To try the issue for yourself, click here in Chrome or download the attached capx.
    • The issue remains in Chrome Canary. In testing with Airscape, Canary actually gives far worse input lag.
    • In firefox, there's no input lag. In IE, there maaaay be a tiny little bit, but that could be my imagination.

    These factors lead me to assume that the input lag issue might be related to these issues.

    It appears that the input lag is partially dependent on other factors not explored in my demo, as in Airscape the lag is far greater at equal FPS. I can't really confirm this easily though.

    In the capx, the red line indicated reported FPS, and the green line is 1/dt. These values should be basically identical (allowing for a slight bit of variance).

    One thing to note is that there's (AFAIK) no way to objectively and accurately measure input lag. Anyone know of a way?

    Any thoughts about this whole issue? Any way we could get a repro to the Chrome people, and tell them that they are performing far worse than IE and firefox in this regard?

    Cheers!

  • Weird, I've never seen anything like that before. Are your graphics drivers up to date? What GPU do you have?

  • I believe offsite hosted games show a roll of Scirra related ads beforehand which helps pay for hosting of the game on the arcade. I'm assuming allowing for this is in the TOC of uploading to the Arcade, but yeah, maybe Scirra will want to have a look at changing it for the upcoming Arcade update since it's definitely weird to see your game hosted on tons of shady sites.

  • Cranberry linked me to your share plugin, which I hadn't seen. Would that work? I'm assuming because you linked me to cranberry it won't work, but I don't see any reason it wouldn't, at least from your description.

  • Hey Cranberry, quick question for you - Would the shareapp plugin allow me to do what is mentioned in this topic?

    Is there documentation or something that I'm missing?

    Cheers!