Ashley's Forum Posts

  • Thanks, should be fixed in next build.

  • Closing, please follow the guidelines.

  • Closing: the .capx has 77 events, which is too many to easily tell that it's a real bug and not just a mistake in your events. Please post a new report using a minimal .capx with the fewest objects and events possible that reproduces the problem, otherwise we assume it's a mistake in your events.

  • This is currently by design, not a bug. You can work around it by using multiple line of sight tests, but this multiplies up the CPU usage necessary for LOS to work.

  • Some shaders are more intensive than others - the blurs/glows are the slowest, heavy distortion like the water effect are next, light distortion like ripple should be faster, and the blends should be the fastest (like multiply, screen etc). Blends are generally just a tweak to the normal alpha-blending rendering formula so should be very close to normal rendering performance, except for the CPU overhead of processing a shader (which can be high if you use it on lots of separate sprites - using it on a whole layer can be faster in that kind of case).

  • On some specific versions of Android (4.1.x IIRC) the stock browser has a bug where touch inputs are fired twice. Since it's in the browser it will affect any HTML5 framework or technology. We have workarounds in place to stop double-firing events but if it fires it twice with different touch IDs it's hard to block. Chrome for Android should not be affected, nor should different Android versions to 4.1, nor should any other mobile browsers. If you post the exact devices you've found this issue on then we could confirm it's the same issue.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Please report bugs to the Bugs forum following all the guidelines, including the exact steps to reproduce and a .capx file that demonstrates the problem.

  • You do not have permission to view this post

  • We are not prepared to support any new non-browser wrappers. It is extremely difficult to get it working, then they often omit important features like memory management, and then even if we get it working there are still difficult compatibility problems, largely due to the fact they don't implement the DOM (so things like XML parsing and form controls are just impossible to support).

    Crosswalk for Android is pretty unbeatable, since it's a real browser engine. Performance problems usually stem from the GPU blacklist, which I think you can optionally skip in the XDK now.

  • I don't know, I didn't think IE was necessary, but MS have a nasty habit of integrating IE with bits of Windows so it may be that you also uninstalled some necessary OS components by uninstalling IE. Try installing it and see if it works again.

    Other than that C2 just needs to be able to host a server on a localhost port, and if it can't do that, there must be something to do with your computer's networking configuration that prevents it.

  • I think it's a bug, it doesn't attempt to de-duplicate dependencies. Report it to the bugs forum.

  • Construct 2 imports the WAV files so you have your original uncompressed copies around in case you want to recompress them in future. However it never plays them, never exports them, and does not count them towards the estimated download size.

    Construct 2's importer has fairly limited controls over quality due to the encoders we use. If you want to have more control (e.g. compress your tracks more heavily so they are as small as possible), just use your own encoding software to create the .m4a and .ogg, and import those files in to C2.

  • Particles are already more efficient than sprites. The best way to make it even faster is use as few particles as possible. Using an image with say 3 particles drawn on it can help you reduce the particle count while keeping a similar appearance.

  • I think a general rule of thumb if you want to reach a wide range of devices would be something like:

    For mobile games: avoid going over 200mb (going over 100mb will probably still rule out devices with <1GB memory)

    For desktop games: avoid going over 400mb (going over 200mb will probably still rule out devices with 256MB VRAM)

    Exceeding those amounts will probably make your game only possible to run on high end devices, reducing the number of players who can play your game.

    The OS and other applications will still be using VRAM, so to fit your game on a graphics card with 512 MB VRAM alongside the OS and other applications, it's probably best to stay under 400mb.

    Consider using Spriter for animations - it's far more memory efficient. Also your screenshot appears to include a lot of redundant images (the blocks/slopes). Construct 2 should deduplicate truly identical images, but consider re-using the same ones if at all possible.

  • Construct 2's collision algorithm will have a high performance overhead if you use lots of collision polygon points. You can use more and if performance is OK then that's fine, but it would probably be faster to make a segment object (like a slice of cake) and have several points down the edge of the curve, then place several instances of those objects at different angles to make a full circle.