Locking, please stay on-topic. If you still want to discuss the OP then make a new thread and cut the unnecessary chat.
Try updating your graphics card drivers. Closing, not enough information provided for us to suggest anything else.
I can't reproduce, I'm stuck on step 2. How do I match 3 numbers? There appears to be no feedback and clicking on three of the same numbers in sequence does not appear to do anything.
Develop games in your browser. Powerful, performant & highly capable.
Closing, please follow the guidelines and only report bugs using the latest version of C2.
Closing as not a bug. At high enough speeds, objects will step far enough per tick to jump obstacles.
Closing, please see the obviously named threads at the top of this forum :-\</p>
You should not use 'alert' to test things like this: some browsers have bugs in the alert dialogs that can cause events to mis-fire or switch focus in unexpected ways. Please repost a repro .capx which does not use alert.
Sorry, I don't think there's anything we can do about this - just looks like a limitation in asm.js. BTW there's nothing to do with exporting or Crosswalk here, the error comes up for me in desktop Chrome as well.
Closing as not a bug. The positions read from XML are strings, not numbers. Assigning to a local number implicitly converts them to a number, but the disabled action needs to convert explicitly with float().
Looks like the minifier broke the feature detection (opening a new window is a workaround for browsers without invoke download support). Fixed for the next build; workaround in the mean time is to disable minification on export.
Closing, please follow the guidelines and provide a minimal example that proves it's a problem in Construct 2 and not a mistake in your events/project.
Alright, this works, but is non-standard. I've enabled that workaround code for Windows Phone 8 only and it seems to work. All other platforms will keep using the old standards-compliant code.
Thanks, should be fixed in the next build.
I think I found a workaround based on checking if GL_FRAGMENT_PRECISION_HIGH is defined in the shader and falling back to mediump instead. I've made the change for the next build but don't have any affected devices to test on - could you let me know if it's fixed when r164 is out?
Can you describe which devices and with which browsers specifically? I'd have thought the browser engine would just substitute a working precision instead.