Ashley's Forum Posts

  • You do not have permission to view this post

  • I didn't move this, but probably because it looks like a duplicate of this. Please only report bugs once.

  • It should be simple to get audio working on iOS. As I noted earlier in this thread the most common problem is incorrect MIME types on the server, which means iOS doesn't regard .m4a files as being audio files. Once that's working, remember you need to touch the screen before iOS starts playing audio in the browser.

  • You're using a folder-based project, right? Updating files in the files folder should work immediately, once they're imported, but you do have to import them first so C2 knows about it. I think an option to automatically add new files that have been copied to the files folder is on the todo list.

  • Hansi - it's already supported in r123.

  • To echo your points, the DOM is most certainly an advantage when it comes to layout and the breadth of api's available. However, it kills rendering speed even when hardware acceleration is implemented in the browser.

    I disagree! Some of our best performance results on mobile are using Chrome for Android with WebGL enabled (see this blog post). Basically, although our engine uses lots of browser-level APIs, we don't ever really touch the DOM per-frame. So we don't get any perf hit from DOM manipulation or re-flow. And browsers, especially Chrome, are extremely efficient under these circumstances.

    In fact, it is very difficult for DOM-less engines to match the performance of Chrome with WebGL support: unless you re-invent their multi-threaded renderer model which works with WebGL, have a highly optimised pipeline such as being able to read typed arrays from the javascript engine without copying or converting them, and so on, it's likely Chrome will still beat the DOM-less engine performance-wise. Unless you re-invent loads of browser features, Chrome will still beat the DOM-less engine feature-wise. Why re-invent the wheel when you can just use the Chrome browser engine? This is why I'm convinced the future of HTML5 game wrappers on mobile is the Chromium mobile ports.

  • I think I've fixed it (the indexOf problem, which is different to the Platform problem). r123.2 should be coming out in a few hours.

  • Performance wise, admittedly the Physics behavior is a weak point in Construct 2. Javascript is not well suited to the intensive calculations that are necessary. However, note that Construct 2 thoroughly demolished our competiton in other areas last we checked (https://www.scirra.com/blog/59/construct-2-vs-gamemaker-vs-gamesalad-vs-stencyl), but that was quite a while ago so it's not up to speed with the latest developments. (Construct 2 scores a lot better on those tests due to optimisations we've done, for example.) Also the Physics behavior is opt-in, so if you don't use it, you don't get the performance hit.

    In our latest tests we had a phone rendering over 7000 rotated sprites on-screen at 30 FPS, something I think a lot of engines would struggle with. We've also done tests that show our HTML5 engine is competitive with our old native engine performance-wise.

  • We have separate beta updates and stable updates. The stable updates are generally very reliable. You get new features sooner with the betas, but they can be problematic (for example the last beta accidentally broke the Platform behavior, but it will be fixed before the next stable release).

    Some people struggle with memory usage on mobile devices with Construct 2, but usually from lack of awareness to how images are stored in memory. Your game might be a 5mb download since all the images are compressed as PNG or JPEG, but they are extracted to uncompressed (basically BMP) in memory for rendering, which can easily make it 5-10x bigger in memory than the download size. Because lots of people ran in to this we recently added a memory usage tracker in the Construct 2 status bar. It's just an estimate, but will give you a useful approximate figure (e.g. 5mb download size, 40mb memory use).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You can probably email a complete .capx for this one, as long as it doesn't use third party plugins. While small projects are what I typically ask for, I get the feeling this is something silly like a typo or something I can fix quickly once I see what's happening in a real project.

  • We have occasional but repeated support requests along the following lines:

    1) User with 300mb of images on a single layout wonders why their game doesn't run on a device with 50mb of free memory for applications

    2) User with 4 fullscreen size images, all on-screen, wondering why such a "simple" game performs poorly on mobile

    In some cases the users blame Construct 2 for being slow or buggy. I always try to explain how mobile devices are much, much weaker than desktops, but it seems almost everyone new to Construct 2 assumes a game running well on their 500W desktop PC with a 300-core GPU and 1 GB of dedicated VRAM will run well on a battery-powered phone with a 4-core GPU with no dedicated VRAM, just shared system memory, of which there might be only 50mb free.

    This paper is also interesting for pointing out how mobile GPUs are actually optimised for 3D, and also how native developers go to quite extraordinary lengths to squeeze extra performance out of low-end hardware. We do our best to make Construct 2's engine as fast as possible, but when you do things like use your entire overdraw budget with four sprites, it's difficult for us to do much in the engine to mitigate that. Good game designers just design their games better than that, with awareness of the capabilities of the hardware.

    The technique the paper describes is interesting, but impossible to apply in the canvas 2D renderer (so it won't work on Safari for iOS). It's also still pretty complicated to apply automatically in the WebGL renderer since as the paper notes it can't handle disjoint images, as well as the fact we've already highly optimised the WebGL renderer for quads. However it helps you understand how to design an efficient mobile game, even in Construct 2. Remembering transparent pixels are still "drawn" is a good rule of thumb. A common mistake I've seen is people making window borders by making a fullscreen sprite, mostly transparent, but with borders round the edges. Splitting this in to four separate objects for each edge should give a good performance boost - and save lots of memory! In general, splitting up sprites with large areas of transparency is sort of the manual version of what the paper suggests.

    I'm sure Javascript is fast enough. The fact our WebGL renderer is usually twice as fast as the canvas 2D renderer, where the rendering calls happen in native code, is a sign how good it can get. However we need more widespread WebGL support to get the benefit of that. In the mean time I think the most common problem is just that Construct 2 makes it really easy to throw in loads of sprites and effects and give a mobile device more than it can handle - something that native developers usually know to avoid.

  • This can't be fixed without a .capx or actual steps I can follow to reproduce the issue. Can you provide this? A hotfix will likely go out tomorrow for the Platform issue so it would be good if this can be fixed too.

  • The layout size should not affect anything, since it's basically only used to limit scrolling.

    The micro-pauses are probably garbage collection. There isn't much you can do about it, since Javascript is a garbage collected language. The latest build (r123) has some small improvements which might help, and often it clears up after 20-30 sec (once it's got the main garbage out the way).

  • Oops. The Platform behavior is busted in r123. I'll have to hotfix it tomorrow...

  • I've never been able to reproduce this crash. It's hard to fix if it doesn't crash for me!