Ashley's Forum Posts

  • Closing as fixed by NW.js in alpha6.

  • Am I right that this is fixed in alpha6? Your post here says so: https://www.scirra.com/forum/nw0-13-alpha5-testing-report_p994311?#p994311

  • Note Text Box is a different plugin to the Text object: Text Box is a form control, and Text is the normal way of labelling things.

    In WebGL mode, text is rendered via a WebGL texture, since WebGL does not have the capability to directly draw text itself. This means you are limited by the maximum texture size of the system, which is typically around 4096, but on high-end system goes up to 16384 (which seems to match what you describe).

  • You should just be able to connect a device and choose it in the dropdown by the "Debug"/"Run" button. Windows 10 Mobile hasn't been fully released yet though, so maybe it's not working because of that.

  • You need to make sure you have the most up-to-date version of VS2013. In the installer, make sure you don't uncheck the support for Windows Store apps, or anything related to Javascript/HTML/web support.

  • matty100 - that is unrelated to this thread. Please start a new thread in Website Issues.

  • I don't think I've noticed this. File a bug report following all the guidelines and I'll take a look.

  • do you guys think that construct2 should ship with nw.js as part of the installer? I dont understand why it is separate at the moment

    The main reason it was separated was the download size: NW.js is ~130mb at the moment, and C2 is ~60mb. If you don't need to use NW.js and you don't have a fast connection, it's annoying to have to download 3x as much data. Also it allows us to update NW.js independently of C2.

    Please allow a few weeks for bug reports to be investigated, as the guidelines describe.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • This is why we avoid relying on any third-party non-browser implementations of browser features. They're always buggy, incomplete or have other major drawbacks like poor performance. Basically unless the library advertises that it passes a comprehensive standards-compliant test suite, it's probably useless. If anyone finds something that actually works smoothly we could think about supporting it more directly, but if not I think it would be better to wait until Apple add built-in support (which rumour has it they are working on).

  • Across all the platforms supported, there are so many different icon and splash image sizes required, that it would be ridiculous to have them all pre-defined in C2. Instead it's intended that you just manually import them.

    • Post link icon

    Closing as duplicate of

    • Post link icon

    Closing as duplicate of

  • I am re-creating a limbo-type level, and the terrain is compiled in a single image (1920*8000pi).

    We strongly recommend against designing games like this. See remember not to waste your memory. The memory use will be very high, and an image that large will not even load on systems with a maximum texture size of 2048x2048 or 4096x4096.

    You don't need to design the collision mask point-by-point for an entire level like that. Just create some collider objects which are invisible sprites with a simple shape (e.g. triangle, rectangle, etc) with a matching collision mask. Then you can design the collisions for your level in the layout view by arranging those objects. The collision cells optimisation keeps this fast regardless of how many collision objects you have scattered across the level.

    Given the high complexity of the per-pixel collisions feature, I really don't want to have to support that. As I said earlier in the thread the implementation complexity is very difficult, it has high performance and memory overheads in some cases, it was an ongoing source of bugs and crashes in Classic, it would be even more difficult in C2 (since there is a new poly-to-pixel-mask case), and every new collision feature exponentially increases the types of collision interaction that must be supported, effectively ruling out ever adding any other new collision features. I really think it's best to stick to polygons. AFIAK, that's how all 3D games work anyway - I don't think many games use voxel collision masks (which would be the 3D equivalent) - and if polygons are good enough for 3D...

  • bbjGames - please file a new report following all the guidelines.

  • As far as i see this is not a request for a native export, rather a Scirra controlled wrapper.

    So what are people asking for here, a native exporter or for us to take control of the third party wrappers? Those are very different cases. Well, for NW.js, I think Intel have 1-2 people working on it full time. I've heard in some cases it can take literally hours to build Chromium, which must make it a slow and frustrating development cycle. So it's nice that Intel are doing this for free! If they ever stopped, it's open source, so us or anybody else could pick it up, or there are other alternatives out there like Electron that we could look in to. Also the biggest problem NW.js had recently was the janky v-sync issue, and that was caused by a bug in Chromium itself, not NW.js. So whoever happens to be developing NW.js wouldn't have affected that.

    android is still ****** with no webgl support

    Chrome for Android has supported WebGL since late 2013. Android 5.0+ supports it in the system webview so you don't need Crosswalk. Crosswalk exists solely for Android 4.0-4.4 compatibility, once those versions are out of use then we can drop it and its filesize overhead as well. In fact you can already publish without the filesize overhead today by targeting Android 5.0+ only. However especially given that Google recently increased the APK size limit to 100mb, using Crosswalk is well worth it for the compatibility with 4.0-4.4.

    The main problem with WebGL on Android is that Android devices often have poor quality drivers that are so susceptible to crashes that their GPU gets blacklisted. However the number of Chrome for Android phones that don't support WebGL halved between June 2014-June 2015. So it's already improving quickly.