Ashley's Forum Posts

  • Pops up for me OK on Chrome using r150. Note this isn't guaranteed to work; it is only possible if the address you request has set up cross-origin resource sharing (CORS) and allows you permission. By default you are not allowed permission. See the AJAX manual entry for more info.

  • Yeah, try loading the files dynamically from script. You can then also check if you're running in preview mode and skip it if so.

  • The Android browser basically does not support audio.

    In the latest beta you should be able to get a single music to play when the user first touches in the game. But it's a really poor browser and it just doesn't support doing anything more than that.

    Try Chrome for Android instead!

  • We are planning to continue improvements to the tilemap support over the next few releases. The keyboard shortcuts idea has already been suggested and we do plan to add it.

    As for auto-tiling, what is wrong with designing in Tiled and importing to C2? We are a small team with limited resources and want to avoid reinventing the wheel if possible...

  • Hard to help without a more specific description of what is wrong or a .capx file.

  • It's not supported since the dual-encoding problem means you can't just load one audio file and expect it to play.

    BTW you shouldn't ever use MP3 for anything, ever - if 5000 people play a game using MP3, you're liable for a $2500 license fee.

  • You can change it if you don't want it - it's loader-logo.png.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You could do this in events by looping through each waypoint position and adding the distance to the next waypoint position.

  • Colludium's results are pretty much what I saw: it did not work reliably, and it was still choppy even when half framerate mode was in effect and it was measuring 30 FPS. I'm not sure how it could be improved - the current algorithm is "if last frame was not skipped, and the last frame was less than 29ms ago, skip this frame". That ought to work with vsync-aligned ticks, but I guess browsers (and non-browser platforms like CocoonJS) treat their tick rates differently or give up vsync-aligning ticks in some cases. Perhaps this might be possible to do well in a native engine, but I think since there seems to be varied tick rate logic in each browser I doubt it is possible to make a high-quality framerate limiter that works across all browsers.

    One solution might be to just alternate frames blindly (just skip every other frame regardless of timing). However on a 60 Hz monitor as soon as you drop to 29 FPS you might end up halving the framerate all the way down to 15 FPS again. I'll do some tests and see what really happens with that.

  • It might be to do with the fact that Javascript cannot be JIT compiled in iOS apps, making it slower. The WebGL renderer shifts more of the drawing logic in to Javascript and relies on the fact the Javascript is well-optimised, so I guess it might be possible WebGL mode is actually slower on iOS. However I'm pretty sure I did a benchmark that showed WebGL was still faster on iOS... but then benchmarks can produce pretty artificial results.

  • Hmm, I guess this could be useful - what do you plan to use it for? Generally you should provide as many good use cases as you can for a feature, so we can prioritise it correctly.

  • You shouldn't use dt when applying forces. The physics engine applies dt itself if it has been enabled.

  • You can't just half the tick rate, otherwise at 40 FPS you fall all the way to 20 FPS, and you definitely don't want to skip frames if it's a slow device and going to run at half-framerate anyway. It has to be smarter than that and try to schedule at exactly half vsync rate only when the framerate is higher than half vsync.

  • So r150 ships with a half framerate mode. I had a tough time coding it though: I'm not sure how browsers handle their tick rate when they can't hit v-sync rate. So the current implementation uses a magic number: if the next tick comes within 29ms of the last tick, it skips it. I've tested it on a range of platforms and this was about the necessary value to actually hit the half-vsync framerate. For reasons I do not fully understand, smaller values still sometimes allowed higher-than-half-vsync framerates (e.g. with a 25ms detection, IE would sometimes still happily run at around 40 FPS on my 60 Hz display, even though Chrome and Firefox would hit 30 FPS). On top of that on some of the phones/tablets I tried I'm convinced even though the framerate counter was at half-vsync (e.g. 30 FPS), the display was way worse and janking horribly. I think this means when the performance is poor some browsers give up trying to vsync, and since this algorithm assumes ticks arrive on vsync intervals only, it starts going choppy in the 30-60 FPS range. I have a feeling it might be hitting 30 FPS, but in a really irregular fashion which is not at all better than a variable framerate in the 30-60 range.

    On top of that due to the 29ms magic number, it will incorrectly skip frames on displays running at above about 70 Hz. In this case I think it will keep skipping frames even when the framerate drops below half-vsync, which will unnecessarily further degrade performance.

    I did argue against it, but I've done what I think best and I'm not at all confident this implementation is adequate. So let me know how it works for you and on which platforms with which browsers. I have a feeling that this kind of accurate synchronisation might be an area that javascript/browsers are not well suited for. Or maybe there's a better timing algorithm that I'm not aware of yet.

  • I would perhaps avoid relying on this kind of behavior - it's a sort of edge case thing that might change in future.