Ashley's Forum Posts

  • You need to build with Crosswalk support for sound to work on Android 4.x. It's applied automatically on PhoneGap Build and the latest Intel XDK with the new project format, but otherwise I think you need to manually enable it. Closing as I'm assuming you've just built without Crosswalk.

  • totoyan - this post is 7 years old and about something else and is in the Construct Classic forum, you should probably have started a new thread in the Construct 2 section.

    Construct 2 definitely does not generate that. It looks like you have a virus on your system which is infecting files. You should run a virus scan and clean up your system.

  • I mean using binary data without using a string as an intermediate format. The conversion to and from the string is slow and can waste memory. Ideally it would get binary data and be able to write it directly.

  • I don't think this is a minor feature. Data URIs/base64 encoding are a slow and bloated way of dealing with binary data and I don't think we should continue to build on them or encourage their use. It would be better to invent a new efficient general-purpose way to deal with binary data in C2, and then use that to support taking screenshots as a true binary image, and then write true binary to a file. That is a pretty significant feature though.

  • This should be fixed in the latest release. Please only test the latest version like the bug report guidelines state. Closing.

  • You do not have permission to view this post

  • Misconfigured servers with the wrong MIME types is a common problem and often causes projects to fail to load. We have a special manual entry to cover this: see MIME types.

  • Some things are deliberately not documented. The fast trigger flag was designed specifically for the Function object, and has a bunch of fairly obscure caveats and usage requirements that are fine for the Function object but make it unsuitable for other usage. So yeah, the engine has a bunch of undocumented capabilities but generally if they're not documented it's because there's not much reason for any third party developers to use them, or we don't want to have to support them if people ran in to the various caveats.

  • I think you missed the "show collision polys" option in the View tab

  • Closing as not a bug.

  • Closing, .capx is required. When writing WKWebView support I did a bunch of testing with Space Blaster which changes layout as you describe, and never saw any issues, so can't reproduce. As the bug report guidelines say, reports like this are generally useless!

  • I can't reproduce this at all. I have now built iOS apps with the Intel XDK in the following combinations:

    Reported .capx - new XDK project format - WKWebView - unminified

    Reported .capx - new XDK project format - WKWebView - minified

    sbperftest - new XDK project format - WKWebView - unminified

    sbperftest - new XDK project format - old webview - unminified

    sbperftest - old XDK project format - old webview - unminified

    All five tests were exported with r227 and ran fine built by the Intel XDK running on an iPad Air 2 (iOS 9.3.1).

    I'm guessing it might be one of these issues:

    • are you testing on an older version of iOS? Maybe iOS 8?
    • are you re-exporting over the same XDK project? I heard there are known bugs with that - I used a fresh project each time
    • are you sure your build settings are all correct? I was testing with a newly configured certificate (it said something about being able to import an older certificate, but I couldn't build with that)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • This is more tricky than it seems, I think. The now-official way to use WKWebView in Cordova is with their new official WKWebView plugin, which is what we use, and requires some workarounds so we include some other plugins such as cordova-httpd. I don't know how Cocoon's WKWebView support works - it seems it uses a different system of their own design. Still it would make sense for them to unify their solution with the way the rest of the Cordova ecosystem works, so I anticipate this will change at some point. The suggested workaround will break it again if they do that. It also makes the runtime think it's in a UIWebView when it's really in a WKWebView, which could have other side-effects.

    The HTTP server is only used for video support, since we have to work around WKWebView limitations there. I don't know if Cocoon's own WKWebView support covers video playback? That was a tough problem for us when working with WKWebView. So to hack around this, for the next build I've allowed the runtime to be able to start up without the HTTP server, and the only side effect is video playback probably won't work. I still think the HTTP server plugin should be supported by Cocoon though - otherwise I don't see how video support can work.

  • The easiest thing to do is export your project as Cordova and use the same plugins listed in the config.xml for PhoneGap Build. That's the only definitive way to know the full combination of plugins a project needs.

  • The config.xml file C2 exports is designed for PhoneGap Build. The Cordova CLI is not an officially supported option - you can use it, but you need to configure it yourself, C2 does not provide anything for that.