Ashley's Forum Posts

  • You do not have permission to view this post

  • You do not have permission to view this post

  • teahousemoon - all audio features work with the Web Audio API, which is supported on iOS 6 already. It should be coming to Chrome for Android in future as well, so if it doesn't work there, hopefully it will be fixed in the near future.

  • It's hard to tell if these are Safari bugs - I had it working fine on an iPhone 4S, iPad 2 and iPad 3, but they did occasionally lose audio. I think it might be to do with closing the window before Safari finishes loading the offline cache in the background. So it ought to work as long as you keep the window up for a while the first time you play. If it's a Safari bug there's really not much we can do about it.

    As for performance, mobile devices usually need some time to "warm up" - it could run 10 FPS at the start, but then after a while it should get smoother and then run 30 FPS+ consistently. That's what I see anyway. Are those of you reporting poor performance only watching for a short amount of time? It should improve if you let it go longer.

  • Can't you just make a hidden 'Locations' layer? Isn't it easy and straightforward to use Tiled Backgrounds as zone markers, and create, resize and move them using the traditional controls?

  • It is likely your 'every tick' events have little or no performance impact. If nothing at all on screen changes (as you say is the case when you disable the events), Construct 2 does not actually redraw the screen. Most games spend 80-90% of their time rendering, so if you measure the framerate when nothing is moving (and therefore the screen is not drawing), the result is meaningless. It will basically be doing nothing at all apart from updating the FPS counter. I assume you are enabling an event which causes a per-tick change in the display, which causes rendering every tick, which then results in a real framerate. This may make it look like a single event is having a huge performance impact, but it is very unlikely this is the case. In general you shouldn't worry about event performance anyway.

    Note that moving offscreen objects, or moving an object then putting it back in the same tick, still results in a redraw. Construct 2 doesn't try very hard to detect is nothing has visually changed, because doing so accurately is extremely difficult and most games redraw every tick anyway.

    For the record, C2 does not use a multithreaded engine right now.

  • It's a known bug which has been reported.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You should not do this, because event sheets can only be run once per tick (to prevent cyclic includes). If two of your includes try to run in one tick, the second will not run at all.

    There's a function plugin, and we also have built-in function features planned as well.

  • This is the standard performance test we use to get an impression of a device's performance. It takes about a minute to run. You should not make a performance test that measures event performance, because most games spend 80-90% of their time in rendering.

    If you're trying to measure performance on startup, there's no good and reliable way to do that - just have a setting for effects, e.g. low, medium or high.

  • You do not have permission to view this post

  • The overlay context was removed recently. You should not use it - it was only ever there as a hack to support the Text object, and then when we implemented Text properly to avoid the hack the additional context was removed. You need to implement an actual WebGL drawing routine.

  • For the record, the runtime actually removes the names of variables when exporting, it's not to do with the minifier.

  • Obviously, iPads don't have a mouse attached, so will never run mouse click events. Use the Touch object instead.

  • Please do not cross-post. I have deleted your other threads.

    It looks like the WACK tool is crashing. You might want to contact Microsoft about it, or submit to the store anyway.

  • We do plan to ultimately support all of this. However right now the Web Audio API has quite a limited reach so it's difficult to justify it. Lots of users have a habit of assuming all features work everywhere then thinking its broken if it doesn't work, so we prefer not to support features which don't have reasonably broad support. Still I think in the near future both Chrome for Android and Firefox will be supporting the Web Audio API, so I'm sure we'll add support for advanced audio features sooner or later.