Ashley's Forum Posts

  • Crosswalk bundles the entire Chromium browser engine for Android 4.x compatibility, which adds about 17mb. If you target Android 5.0+ only, you can do without it, which reduces the size of the APK.

  • I've never heard of this problem before. All I can suggest is open regedit and delete the entire key HKEY_CURRENT_USER\SOFTWARE\Scirra\Construct2. That will reset all settings. If that doesn't help, I'm not sure what it could be...

  • I think it's a bug in iOS 9.2. Some other threads discussing it:

    http://www.html5gamedevs.com/topic/19156-ios-92-sound-broken/

    https://www.scirra.com/forum/ios-sound-problems-since-ios-9-2_t165414

    The html5gamedevs thread has a possible workaround. I'll investigate that for the next beta.

  • Closing as can't reproduce and no .capx provided, please review the bug report guidelines.

  • Can't reproduce in r219. Does it still occur for you there?

  • The keyboard shortcuts section in the manual is pretty comprehensive.

  • Can these not be provided to the plugin at runtime? There is an existing method set up to do this kind of thing, which is the SDK-defined plugin properties where users can paste in things like an app ID, as long as you can pass them at runtime. This is what the official Facebook plugin does. At the moment there's no mechanism to do what you suggest.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Debuggers often have a high performance overhead, with any technology, so this is pretty much to be expected. Closing as won't fix. You should also attach a .capx with every bug report as per the requirements.

  • TheRealDannyyy - does it work after export? In the past we've had a couple of weird preview-only quirks due to the preview server...

  • Low resolution fullscreen mode basically does the same thing as switching resolution. The only difference is the last stretch to the display size is done by the GPU (which is typically very efficient at that) instead of the chip in the display hardware. It also means you can control the sampling between point and linear, which means you can keep pixel games looking crisp where monitors typically only use linear sampling for the last stretch. So I really don't think it's a big deal if you can't change the hardware resolution. Even if you still really wanted to, you could probably find a way to write a plugin to do that in NW.js. (I don't think I've ever seen a mobile device change resolution!)

  • Fillrate is a good example of a common poor-performance case that will be no faster at all with native exporters. If there are any bugs or missing features, fixing them or adding them in (possibly via Cordova or NW.js) is perfectly possible. It would be madness to spend years writing native exporters with all the compatibility and maintenance implications that entails, just to cover some specific feature request!

  • 1. Pixel distortion:

    Pixel rows and columns are rendered with varying thicknesses (plaid-like) rather than as a uniform pixel grid.

    (see image below)

    ...Note: If the patch dimensions are powers-of-2, then the distortion will not occur in webGL, but any other dimensions cause the distortion. Possibly related to gl.REPEAT requiring power-of-2 textures. The power-of-two dimensions does not fix the other UV coverage issues though.

    You hit the nail on the head with the power-of-2 issue. After cutting the image in to patches, if tile mode is enabled then each patch is put on a repeating texture. However WebGL 1 does not support non-power-of-two repeat textures, so the renderer stretches the image to a power-of-two size using the project's sampling mode (point/linear) when creating the texture. This stretching produces artefacts, and that's what you're seeing in the bug report. The good news is WebGL 2 has full support for non-power-of-two textures and so should fix this particular problem. WebGL 2 is in active development for all major browsers (except Edge, where its status is "development is likely for a future release"), so rather than come up with a fix for this case I think I'd rather wait for WebGL 2 support.

    [quote:2kdd31z7]2: UV coverage issues:

    If multiple instances of a 9Patch object have different margin settings, only instances with settings matching those of the instances at the backmost z-index will render correctly.

    (see image below)

    In Construct 2 the general model is that image data is stored in the ObjectType and instances all share the same set of images. This is to avoid wasting memory. For example if you created 100 9-patch objects and gave them all slightly different margins, it would have to load 100 sets of textures. I also assumed that for any given image, there would only be one correct set of margins, so why would it be necessary to support that feature? Right now it's by design... although I guess it's a problem it's possible to give different instances different settings when really they share images. So are there really some compelling cases where it's great to be able to set different margins on the same image?

    BTW, kudos for writing an essentially perfect bug report, I wish everyone's reports were like this!

  • There's a fix aimed at resolving this in r219. Could you let me know if it works for you? Thanks!

  • There's a fix aimed at resolving this in r219. Could you let me know if it works for you?

  • I can't reproduce this in Chrome. It seems to work just fine and there is no third peer, even though the example .capx has a serious bug: as Reinarte points out, it returns to the title screen while leaving the Host/Peer groups activated, so it's possible both end up activated, which will cause problems. You should make sure both groups are disabled again when returning to ensure when the next game starts, only the correct group is activated.