Ashley's Forum Posts

  • There's no browser feature that allows this yet. I think it's a work in progress though.

  • Still nobody has reported if r222 is any different, which is important to know! Testing usually requires trying several times over a period of time, so going to a local store is not really a viable approach, and I'd prefer to avoid purchasing a whole device just to investigate one bug.

  • One other idea to try when there is a .capx again: if this is to do with switching to the home screen/another app and then coming back, it might be worth trying enabling "play in background" in the Audio object properties. Normally switching away and coming back will suspend and resume the audio context, but if you enable that option it just leaves it running. This might help identify if the problem stems from suspending the audio context.

  • I tested an iPad Air 2. Does anyone else have one to test and does it definitely not reproduce on that? iOS devices tend to be pretty consistent so deviations like this tend to be unusual.

  • I don't think any modern devices have hardware limits, they just mix all the channels on the CPU in to a single output stream. If it's not hundreds you'll probably be fine.

  • Ignaci - have you tested r222 and is it any different? I made some changes for that.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The only thing in the engine that are DOM elements are the form controls. Everything else is pure JS rendering to a canvas. So there are no div, img or any other kind of elements at all for those things.

  • I think modern systems are limited only by how fast the CPU can process all the audio you're throwing at it. Then if you throw in a lot of high-volume sounds, the output will start clipping and it will sound horrible, so it's not really a good idea anyway.

  • There are free options: the Intel XDK costs nothing. The Cordova CLI is free too, but is a more complicated setup.

    Yes of course Native Exportation would be better.

    Not necessarily: if development is 5x slower than it is now as we have to maintain 5 platforms separately, and due to the quirks of each platform each individual feature is only supported over a random selection of platforms making porting constantly a huge headache, and some features are entirely missing or incompatible with their browser equivalents, and some platforms face awkward bugs that others don't, then the end result is not necessarily even better than what we have now. None of this is hypothetical, other products on the market with this approach face these problems. If you add up all those other problems, is it really better? Then throw in the colossal engineering effort it takes to even get started on this...

    It also won't necessarily remove the difficulty of configuring certificates, setting up provisioning profiles etc. All of that you still have to go through for native apps too, and that can be a big part of the pain of setting up mobile publishing.

  • I don't know why you would accuse me of not caring: I've investigated the issue, and not been able to reproduce it. This means two things: firstly I can't fix it yet, since step #1 of fixing an issue is to be able to reproduce it, and secondly it's probably a sporadic or occasional issue, since it appears it is not so severe that it affects all devices including mine. It could be a problem with another app, or it could be a problem with iOS itself (iOS has had loads of bugs over the years). If the problem stems from another app or iOS, it's not our bug and it's not our responsibility to fix it; the best we can do is find a reliable way to reproduce it, and forward the bug report on to someone else. However we can't do that without a way to reproduce the problem. So I will continue looking in to this, but I can't guarantee you it's something we can fix, it could be well out of our hands.

  • Reopened, link works. If you read our bug report guidelines, they cover why the link is changed and how to get around it.

  • If you see the comments in that report, it appears it's also possible to use the devtools port forwarding feature to enable this. That might help speed up testing. I think it would be easier with a browser flag though, which I'm suggesting to them.

  • Yes, I selected them from the project bar like you said. Perhaps you have to select them in a certain order? I'm afraid if you can't provide the necessary steps to reproduce the issue I will close this as can't reproduce.

  • Original .capx link is no longer working, so we can't investigate this any further. This is missing review for the r222 release cycle. Please provide a .capx link that works or the issue will be closed.

  • I cannot reproduce any problem with the viewport on an iPad Air 2 with iOS 9.2.1, nor a Nexus 9 with Android 6. I did however find one issue on the iPad, which was a similar thing to what you described: it seemed to zoom in on the top-left area after putting the device to sleep and waking it again. I found a horrible hack to work around this, and would report this issue to Apple, but bugs.webkit.org isn't responding right now

    We don't have an iPad Pro in the office to test with right now. I don't know if the issue I found was related, or if this is an issue limited to just the iPad Pro device (which would be weird). Anyway wait until the next beta comes out and let me know if it's any better.