Ashley's Forum Posts

  • If you choose CC you're jumping on a sinking ship. At some point we will shut down support for it entirely, including closing these forums.

  • It's either the entire layout drawn so far (by default), or the current layer drawn so far only (if using its own texture). We can't force a separate texture per layer, it will murder the fill rate on low-end systems.

  • Yes, you can.

  • Did you try it?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The forum software we use is really buggy and drives me (and everyone else) crazy. It's difficult to change or upgrade because we've made some pretty deep modifications to integrate it to our site. However Tom is planning on replacing it with something better soon, but it's a big job.

  • Creating multiple groups with the same name caused confusion when using the activate/deactivate group actions. Since they activate and deactivate groups by their name, it made it impossible to activate or deactivate groups with the same name separately. This confused lots of people and caused some weird bugs, so now every group project-wide has to have a unique name.

    If you're copy-pasting groups between event sheets, you're doing it wrong. Use event sheet includes.

  • Crosswalk supports everything, try that for publishing to Android instead.

  • The debugger already tells you this with the collision checks count. It's not ambiguous, that counter is exactly how many collision checks it's made.

  • Glows and blurs are the most GPU intensive effects which will be the slowest on mobile devices. Most simple blend or re-coloring effects should be fast (except possibly the HSL based shaders, which need to do lots of computation for HSL<->RGB conversion).

  • It's an interesting idea but so far my experience of trying to do anything productive on a touchscreen phone or tablet is just incredibly irritating. Touches are much less precise than a mouse cursor, and that's worsened by the fact the screen is smaller than a desktop so there's less room for UI elements. Where it's possible to be productive with a touchscreen I find I can work at best half to a third as fast as I can with a mouse and keyboard.

    That's not to say it isn't a worthwhile project, and there are genuinely useful edge cases like reviewing work, making minor tweaks, adjusting artwork and such. But I wouldn't say tablets are better for major productivity software than a desktop or laptop.

  • This does not fix seaming in all situations. It can help reduce seaming but adding a 1px border does not solve it. Say two objects are adjacent and you scroll half way between two pixels (so .5 of the way between them). The first object fills its edge at 50% opacity, which is the correct result with linear sampling. Then the second object also fills the gap at 50% opacity. However drawing something with 50% opacity over something else with 50% opacity does not result in 100% opacity, it results in 75% opacity. With certain low-contrast images this can be enough to fool you in to thinking it's solved, but in many cases the 25% opacity difference along the seams is still enough to show visible seams. As ever the only good solution for all circumstances is pixel rounding and letterbox integer scale.

  • OK, I think this is to do with our detection of Swiftshader. Chrome has a software WebGL renderer (called Swiftshader) for the Windows version only, and it tends to be really slow. If the graphics card driver is blacklisted then it would use that for WebGL rendering instead of the GPU. When they first released this it was really annoying for us, because it would always use the WebGL renderer even if it was software rendered and the canvas2d renderer would be GPU accelerated. So we implemented a pretty nasty hack (it could have broken at any time) to detect Swiftshader and revert to canvas2d instead. I didn't know if that would be effective, since I thought if the driver was blacklisted then surely the canvas2d would be software rendered too. I guess this is not the case and canvas2d can often be GPU accelerated where the WebGL renderer is blacklisted and using a software renderer.

    Anyway in r153 we changelogged that the detection had changed. A Google developer announced that there was a new official option to avoid software-rendered WebGL (failIfMajorPerformanceCaveat). In the interest of avoiding ugly hacks and sticking to the official recommended way of doing things, we removed our own hack and started using that option instead. Turns out it's not actually supported in Chrome 32, and I've been told it should be in Chrome 33+. So until Chrome 33 all we've done is enable the software-rendered WebGL again. If you're affected, check the renderer string - I'd guess you were previously getting canvas2d and now you're getting WebGL.

    This would only affect Chrome on Windows where the driver is blacklisted and the CPU is not fast enough to software render at 60 FPS. So no mobile devices affected, no desktop systems other than Windows, no other browsers, and not even most Chrome users (judging by Mozilla's stats, since they're the only ones to publish blacklisting figures, about 20% of users have blacklisted WebGL support). And as soon as Chrome 33 comes out it should suddenly get faster again, since it understands the failIfMajorPerformanceCaveat setting and should switch back to GPU-powered canvas2d.

    I don't think we'll do another stable update for this - it's not a permanent problem, since even if you publish now, when Chrome 33 comes out it won't be slow any more, and only a minority of users using a specific OS + browser combination will be affected. I also don't see much point in fixing it for the next beta since by the time we make another stable release Chrome 33 should be out which will fix it anyway. In the mean time a workaround is to disable WebGL in project properties, or force Chrome to use GPU acceleration (go to chrome://flags/#ignore-gpu-blacklist and click Enable).

    tl;dr - temporary blip which should be gone soon

  • Demetari - in case you weren't aware, we've also added autosave in the latest builds.

  • Lots of systems ranging from the download connection, browser, file system and installer should already be keeping checksums/hashes to ensure the integrity of data. Just in case though, can anyone confirm if downloading from a different internet connection and reinstalling fixes it?

  • Can you send me your project to ashleytss@scirra.com? It sounds like a useful example for us to make optimisations to the engine.