sqiddster's Forum Posts

  • Noga Are you on a laptop with a GPU? If so, and you haven't run into the issue before, it's likely that the GPU isn't being utilized at all here, and it's falling back to integrated graphics. If that's the case, you need to go to the NVIDIA Control Panel and enable GPU acelleration for the browser.

    Also, that's a very big difference for what should be no difference (monitor size). That's a classic example of the problem in the 'low quality fullscreen scaling isn't resolution independent' topic.

  • TiAm I don't see why NW would have any better performance? In my experience performance is pretty much identical. It's interesting you say that though, can you try the demo again and confirm?

  • TiAm this is exported with the latest beta.

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

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

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

  • 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

  • Bump again. I emailed Ashley about this but it's quite possible he missed the email.

    This is a super critical issue for me, and anyone struggling with fillrate issues.

    Really good to hear this plugin is (generally) working OK for the major features.

  • *technically*, Chrome/NW is fast enough to run a relatively intensive game on a large number of machines.

    In reality, you may find yourself running into a lot of small (or not-so-small) issues that are *completely outside your control* to fix. Maybe these issues will all be gone in 1-2 years, maybe not.

    The key issue is that there's literally nothing you can do about these issues when they come up, apart from filing a bug report to Chrome/NW and hoping they get to it.

    You have to weigh the awesomeness of the editor against the risk of reliance on third parties who don't place games as their first priority. If you're relying on hitting a firm release date or getting income in time, proceed with caution.

    I've had to push back my release date significantly because my game is literally unplayable below 60fps due to shocking input lag and jank. And I don't even know if Chrome knows about the issue yet, because I have to wait on Ashley to put together a js repro for them as they won't touch generated C2 code.

  • I had a load of similar bugs with the save system, so I ended up implementing my own. It was purely for checkpointing so there was a lot of stuff that didn't need to be saved.

  • It's probably simply not enough of a priority over the hundreds of other things they are trying to implement with just one programmer.

  • ha

    ha

    ha

  • Here's a possible way to do it (these aren't actual events, but show my logic)

    On reached point: destroy point

    Every tick: path to *least recently created* point.

    All you need to do then, is track the least recently created point. That's fairly simple to do by giving all the points an instance variable called 'age' or something. Then, whenever a new point is spawned, increase the 'age' of *all* the points.

    Does that make sense?