Ashley's Forum Posts

  • You do not have permission to view this post

  • As far as I've read, it has neither a browser nor a web view control, so it's not possible to publish HTML5 content to it right now.

    • Post link icon

    For obvious reasons, we don't want to discuss our approach. Closing this thread.

  • Moved to website issues.

  • Blacksmith - the formula for the current playback time is just (currentTime - startTime) * playbackRate. This of course assumes the same playback rate over that duration. The true formula would involve some kind of integration of the playback rate over time, but in practice that would probably still not work: integrating the playback rate over time in JS relies on JS timers, which are not synchronised with the audio playback clock, so they would end up drifting apart anyway. You could still try this in your events. Really what we need is some kind of playback time built in to the Web Audio API, which would need a spec change. I'll bring it up with spec authors and see what they say.

  • Crosswalk is only for Android. iOS only supports the Safari browser engine.

  • You have not attached your project, only one file from a folder project that cannot be opened. Please attach a .capx (a complete single-file project) as per the requirements. Also please check you've got both the .ogg and .m4a versions of all your sound files and provide all the information required by the bug form such as the OS version and C2 version.

  • I don't know why you said it didn't happen in Chrome and referenced Cordova specifically - it reproduced on desktop Chrome for me where it's a lot easier to test.

    There were a few problems here, and I've made the following fixes for the next beta which should help:

    • [FIX] Audio: PlaybackTime expression now correctly takes in to account the playback rate (e.g. increasing slower if the playback rate is less than 1)
    • [FIX] Audio: playback rate would reset to 1 (normal speed) after pause/resume or switching tab and coming back
    • [FIX] Audio: could resume from the wrong location if paused when the playback rate is not 1

    There is one catch though: it does not take in to account a changing playback rate, only a fixed playback rate. Since your demo keeps slowly changing the playback rate every tick it still won't work exactly. I'm not sure how to fix this; the Web Audio API does not provide a playback time, so we measure it ourselves from the start time, but if the playback rate has changed since the start time it's hard to work out where exactly it really is. We could try to compensate, but I don't think the JS timer will necessarily be synchronised with the audio playback clock. So I'm not sure we can fix this case I'm afraid.

  • Closing as not a bug. From the manual with emphasis added:

    [quote:32mtn3ft]Regenerate obstacle map

    Determine whether each cell in the obstacles grid is an obstacle again. This is a very CPU intensive action and should not be used regularly. If only part of the obstacle map has changed, prefer to use one of the Regenerate region actions. Any changes made by using Add obstacle, Clear obstacles, Add path cost and Clear cost will take effect the next tick after this action. Note this means if you attempt to find a path immediately after this action, the obstacle map won't have been updated yet; add a 'Wait' action with a short delay to make sure the updated map is used in that case.

    Your project regenerates the obstacle map and finds a path in the same event without waiting for the update.

    The Pathfinding behavior has worked like this as long as I can remember and we haven't changed the behavior at all for some time now, I doubt it used to work.

  • Closing as won't fix. The Tilemap plugin has integration with the editor which is hard-coded in via the plugin ID, so a third party "Tilemap Plus" plugin is not possible. (We advise against that anyway.) C3 has a better plugin architecture that should be more flexible, but for the reasons outlined in that post, we're not really wanting to make it easy for third-party developers to cause unwitting support and maintenance headaches for both us and our users.

  • Yes, it was related to this bug, which should be fixed in the next beta. It's actually a bug in Safari 8 and is already fixed in Safari 9, but the next beta adds a workaround to the Safari 8 bug anyway which fixes it.

    Begeegee - it won't blow the device speakers, at worst it will just reach peak digital level (0 dBFS) but this should not blow the speakers or playing the average commercial pop track would blow the speakers too

  • I think it's a bug in Safari 8, and it appears fixed already in Safari 9, but I've worked around the Safari 8 bug in the next build anyway.

  • You do not have permission to view this post

  • I'm amazed any software runs on a system that old. I don't think we can support such an old system I'm afraid.

  • I think this is a bug in Edge, but I've worked around it in the next beta, so it should be fixed.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads