Ashley's Forum Posts

  • Closing as should be worked around in r223. The underlying bug in iOS that caused this has been reported to Apple and appears to be being worked on, so hopefully a future iOS update will fix existing content as well.

    • Post link icon

    Good news! The latest official Greenworks release works with NW.js 0.13.0-beta7 (which is now available at scirra.com/nwjs). However for some reason they didn't include the 32-bit builds of Greenworks! The 64-bit build works. The last hurdle now is just to get ahold of those 32-bit versions, then we can ship Greenworks in C2 itself.

  • john Cutter - it's probably not important.

    Well, today we got this: hopefully we can get to the bottom of it soon!

  • Some networks block peer-to-peer connections due to NAT. See this guide for more detail: https://www.scirra.com/tutorials/892/multiplayer-tutorial-1-concepts

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Yep, as glerikud said. If the layers are using default settings, they actually have close to zero performance overhead, so that would be strange...

  • What about C2/C3 own exporters?

    This has been done to death already. But in terms of reliability, look at the situation I described in the blog post: our own exporters could actually prove to have *worse* bugs. Currently, the major browser vendors have already implemented workarounds for a wide range of such issues like graphics driver bugs.

    I don't care if it's Node-Webkit that is broken, I paid Scirra for a tool that they say will work...

    Consider the exact equivalent in native: graphics driver bugs cause your game to crash on startup on *all* Intel HD 4000 series cards. (All graphics vendors have issues, don't think just AMD or Intel are affected.) After having to buy a new PC and build it with the given graphics card so we can test it, we waste days guessing what the problem might be and come up with nothing. Somebody says "I don't care if it's the graphics driver that is broken, I paid Scirra for a tool they say will work". Despite the frustration being understandable, it is a completely hopeless situation and there is nothing we can do, and it's still not our fault. As I described this is by no means theoretical, and already happened with the Construct 2 editor.

    So this happens regardless of the technology choices we make, and switching to other technologies doesn't necessarily improve anything. It's easy to imagine us making some change and everything being perfect, but it could actually be worse!

    In the end, even if you build a flawlessly working bike, a pothole can wreck you.

    I think this is the best analogy. A bike is not useful without a surface to ride it on. But not all road surfaces are perfect, and some can damage the bike. This does not mean the bike is flawed, but you still might be understandably upset.

    Why not look into Vulkan for C3?

    Vulkan is only supported with certain drivers on certain systems with the latest hardware. It's promising, but I doubt it will be on a majority of systems like OpenGL is for a long time to come. If waiting for technical improvements is unacceptable, then Vulkan doesn't fix that. There's also a huge pile of other issues, graphics certainly isn't the only significant component involved. As I say this has been done to death.

    I must add people here are raising issues I am not aware of there being open bug reports for. Current browsers can all hit within 0.1ms of v-sync according to my measurements. I haven't seen any recent activity in the Bugs forum regarding NW.js issues on Mac/Linux. If you have trouble please file reports following all the guidelines - sometimes we can work around them or forward on a technical report to a third party, like we just did with the iOS bug.

  • This is a very weird ancient compatibility issue with Windows that goes back to DOS 1.0! Here's a blog explaining where it originally stems from: https://blogs.msdn.microsoft.com/oldnewthing/20031022-00/?p=42073 (it was done before DOS even had subfolders!)

    I didn't realise it affected filename extensions as well. If you try to create a file called "lpt1" on your desktop for example, Windows shows an error. But even "lpt1.txt", "lpt1.xml" etc show errors, for the reasons explained in that article.

    I think I can protect C2 from running in to this by adding those names as reserved names which are not allowed to be used. It could be a problem if people are using projects which already use these names, but I'll put it in a beta release and see how it goes. It should prevent this problem ever happening again.

  • It's frustrating to be blamed for bugs in other people's software, and that specific iOS audio issue you referenced is the latest and strongest example of this. I am almost certain the bug is in either Safari or the iOS operating system. In this case, it doesn't matter what tool you use: anything at all that runs in Safari will be affected by the same bug. So I guess you can choose a different tool if you like, but you could easily run in to the same bug again, because the problem is in Safari or iOS, not Construct 2.

    I didn't even fix the bug, so I can't even take credit for that. It's impossible for us to fix problems in Apple's own software. All I did was found a crazy hack that seemed to work around the bug. So the bug is still there and Apple still need to fix it. Personally I regard this kind of hacking-around-bugs as beyond the call of duty - I'm sure there are companies out there who'd just say "we've reported it to Apple, hopefully iOS 10 fixes it" - but we go beyond that and try to work around (emphasis on work around - not fix) defects in other software we rely on where it's feasible to do so. Note it is not always feasible to do so. The fact this particular iOS bug is worked around pretty much amounts to luck.

    Usually someone then blames us for relying on certain tools or libraries which have bugs, but all software has bugs. It's naive to think that if we switch to some other library or framework, everything will suddenly work perfectly. Common suggestions are things like: why not use Haxe? It could have bugs, and we could equally be screwed by its bugs. Why not use {insert library here}? If it's not developed by companies as large as Apple, Google, and Microsoft, it's probably even less reliable. Why not write native code? Operating systems have bugs, and graphics drivers have severe bugs - we have direct experience of that, and they are often far worse than the kind of issue we just dealt with on iOS. They tend to be of the class "all devices with this GPU crash on startup", and there is no diagnostic information whatsoever. In the past we've literally resorted to desperately guessing solutions over a period of days, then ultimately given up. That actually happened with the Construct 2 editor in the early days (it uses OpenGL to render the layout view). Eventually months later we got a tip out of the blue, and we finally managed to work around it. Hardly a reliable approach, but there's little else we can do when it's not our code that's broken.

    I know this is super frustrating and when your games aren't working, you naturally look to us for support. However the nature of software development is everything - all platforms, frameworks, libraries - depend on a huge amount of third party code, and that code is as imperfect as everything else. It's implausible to expect any software company at all to magically fix everyone else's code. It affects everyone, regardless of their technology choices.

    FWIW Scirra has been larger than just me for a while now. Check the team page. We should be growing again soon as well.

  • Welp, I'm at a loss to explain this. Looks like we're going to have to order in an iPad Pro.

  • It sounds like the original reported problem of distorted audio is fixed. However this thread is now 7 pages long and is starting to lose focus on the specific issue. I suspect any other issues after r223 are unrelated (or possibly a side-effect of the workaround). As per our policy we ask for one thread per bug report, since it is impossible to deal with issues mentioned in passing without the full bug report guidelines. So I'm going to close this issue as resolved now. Please file new reports if you still have trouble, following all the bug report guidelines thoroughly for every individual issue.

  • Sorry about this, the first upload was a dud, but it should be fixed now if you re-download.

  • Is this any different in r223?

  • So I looked in to this further, and it did reproduce on an iPhone 4S, in Safari (despite the original report saying it did not happen there). So I can confirm it doesn't happen on an iPad Air 2, but does on an iPhone. That's not typical so is a bit of a surprise.

    I am almost certain this is a bug in iOS itself, as I suspected. It appears it incorrectly restores the wrong sample rate on the second load. I wrote a report and filed it with Apple here: https://bugs.webkit.org/show_bug.cgi?id=154538 They typically are very slow to fix and ship bug fixes, it's taken about a year in the past. You can go ahead and tell everyone Construct 2 sucks or whatever, but it is Apple breaking your games, not us. The exact same code works in at least three other browser engines - Chrome, Firefox and Edge - so I am pretty sure there is nothing wrong with our code. So please direct your complaints to the WebKit bug report!

    The good news is I found what looks like a workaround: we don't need to destroy and recreate the whole audio graph, it appears to fix it just by creating a fake audio context on startup, immediately closing it, then creating a second one and using that for the rest of the app. These kinds of workarounds can be fraught, it's really best that Apple fix it since I don't know how reliable this workaround is. But we'll ship it in the next beta release and see how that goes.

  • Closing, please follow the bug report guidelines and provide a .capx.

  • I think we had to paste the pathfinding code in to those files as one of the great many hacks necessary to work around missing features in non-browser engines. However we've dropped official support for both those platforms, so unless you want to bend over backwards to get your plugin working in deprecated platforms, don't worry about it.