Ashley's Forum Posts

  • I don't always keep the same view over time - my view of things tends to evolve with the technology, so bear that in mind when quoting my posts from a few years ago. Also BTW it's kind of annoying to see people asserting that they know what I'm going to say, especially when they're wrong

    tl;dr: star this Chrome issue: http://crbug.com/522983

    My thoughts on this are:

    Performance: I'm not convinced it makes sense to do this because the game might not reach 60 FPS. Modern mobile devices are about as powerful as laptops. Having one master switch to drop to 30 FPS on all devices is overkill IMO. I stand by this aspect of my previous post: if you are doing this to improve the user experience, then dropping a device that could easily reach 60 FPS to 30 FPS actually degrades the experience.

    Also it's not just about mobile, some laptops have serious fillrate performance issues because they ship with the terrible combination of a weak integrated Intel GPU and a high-resolution screen. I think the original motivation for this feature was actually for these laptops. Intel integrated GPUs are far weaker than most mobile devices! (Before anyone accuses C2 of being slow, it's a hardware limit, native apps will be the same!) So if your intent is to flip this mode on for mobile devices and leave it off everywhere else, I think it might actually be better to leave it off for mobile and optionally on for underpowered desktop systems

    Battery life: I think the argument here is better, although I would be interested to see actual data on the battery life savings. As far as I'm aware the screen is one of the biggest battery drain on mobile devices, so if the screen is on for the same amount of time at the same brightness, that part of the battery drain is identical regardless of how intensively the game is running. Also power-saving hardware works best when it can remain idle for long periods of time, allowing the chip time to fall back to the lowest-power modes. 30 FPS allows a maximum of about 30ms idle time, which isn't that much time to power down components. So I think it would be interesting to try and quantify this saving, rather than speculating that it will help. (Note people often compare 2D games to 3D games, but they're not the same - particularly in terms of overdraw, 2D games can be more intensive, since 3D games use different rendering techniques like Z buffering. Also modern GPUs are so well-optimised for 3D that it doesn't matter if you draw a triangle in 2D or 3D, it probably treats both as the same case.)

    Also note that on a weak laptop plugged in to mains, there's no need to save battery life.

    Browser support: we actually tried implementing this already, and it didn't work well at all, mainly because browsers are designed to run at v-sync rate. We tried simply skipping alternate frames, but the browser scheduler assumes a full frame will be drawn on the skipped frame. In some browsers this actually resulted in an even more janky mess, and in others it would incorrectly drop to quarter-framerate mode (just 15 FPS!) if the browser thought it couldn't hit 60 FPS, because the browser would drop down the framerate itself in some way. So there needs to be built-in browser support for half-framerate mode, which doesn't exist yet.

    Based on that, I already made the case for this feature to some of the Chrome developers (making some of the same arguments people are giving here!), and you can star this bug to vote on the suggestion. Until then, there's not much we can do to actually support this.

  • Looks like if you use "touchend" the audio plays fine. Would it be possible to add this as an action in Construct like we have touchstart on an object?

    We already made this change shortly after iOS 9 came out, so all current versions of C2 are already doing that.

  • Yep, looks like your driver doesn't correctly support non-power-of-two images, it looks correct here too. Closing as driver bug.

  • This is currently by design, to work around problems with case-sensitive servers returning 404 not found just because the case of the filename was typed differently in the event sheet. This should not cause any functional difference in the project. Assuming there is none and your report is solely about the lowercasing of filenames, closing as by design.

  • Closing, please follow the bug report guidelines or there is nothing we can do.

  • I have never heard of any such issues with the .m4a files, as far as I am aware they are standards-compliant AAC files in an MP4 container, and every time I've tried iOS has been able to play them. If you have any trouble then please file a bug report following all the guidelines, otherwise there is little we can do other than speculate.

  • Of course we have iPhones, when people report iOS bugs the first device I reach for is the iPad Air 2, since I was not clear this is a device-specific issue, which also tend to be rare since iOS is more or less identical across devices. I will keep investigating, but as I already mentioned, it seems likely the problem is with iOS itself so the problem is not to do with our code and we can't directly fix it ourselves, it's a problem with Apple's software.

  • This is not a bug. Browsers are designed to leave the user in control. If some game was storing 500mb+ of savegame data, then browsers provide these features to allow the user to easily get their space back. All storage by any web page is subject to this, and by design there's no way for websites to override this (or they could clog up people's systems with tons of data that is unremovable).

    The cache is temporary storage which can be evicted at any time for more or less any reason, and savegame data does go in to more persistent storage which basically remains there indefinitely until the user clicks a button saying "I want to delete that data", and consequently, it's deleted! Other platforms like NW.js, Cordova and others are not affected, because they don't use the browser storage at all.

    I think you've identified Safari as different mainly because it doesn't provide any granularity - all you can do is press a button that clears *everything*. In most other browsers such as Chrome you get a list of checkboxes to decide what to clear. Each browser defines this differently, but usually the checkbox which mentions "cookies", "website data", "offline data" or "app data" covers this kind of storage. If you don't tick that, it's preserved; in Safari it just wipes everything.

  • Run the game in an iframe so it has its own window/document and does not conflict with the rest of the page.

  • Specifically for Construct 2 users, I'd recommend moving to Windows 10, if only because it allows for testing on Microsoft Edge. Otherwise you can only test in IE, which is missing several important features (e.g. Web Audio API).

    When doing major Windows updates, although the upgrade process can work OK, I tend to just backup, format and reinstall from scratch anyway. It tends to be more reliable and it's a good excuse to clean all the cruft out of your system, so it tends to be faster and have more free space.

  • Use the Javascript SDK.

  • Note the debugger has a performance overhead itself, because it processes and displays large amounts of data. So for performance testing, you should use non-debug mode. However again nobody will be able to help you much unless you share your .capx.

  • shortwave - those are interesting links - it sounds like it's an iOS bug that has been around for a while, and it definitely sounds like it's something to do with iOS changing the sampling rate as mentioned earlier in the thread:

    [quote:1w4jr61m]I believe the issue is caused due to resetting the audioContext.sampleRate prop, which seem to happen after the browser/OS plays something recorded in a different sampling rate.

    [quote:1w4jr61m]I noticed that if you play a video using a <video> tag, it sets the context.sampleRate value to whatever the video's audio was encoded at. It seems as if iOS Safari has one global sampleRate that it uses for everything...

    This global sample rate appears to persist across page loads and is shared between tabs and browser instances. So, playing a youtube video in another tab could break all your decoded audio.

    So under some circumstances iOS ends up playing audio buffers at the wrong sample rate, which probably corrupts the audio and sounds distorted.

    I think this confirms it's an iOS bug and not something wrong with our own code, so the best we could do from here is figure out a reliable way to reproduce it and forward it to Apple. I think the repro will look something like:

    1. Open a C2 project in Safari which plays some audio at 44.1KHz

    2. Close Safari

    3. Open something else that plays audio at a different sample rate, e.g. 48KHz

    4. Close that and go back to Safari

    5. See if the audio is distorted

    However as per usual in bug reports, we need absolute specifics for every step. So I think it's just a matter of finding something reliable for step 3 (e.g. a youtube video or something public and reliable like that).

    I've looked at some of the workarounds and they look very difficult - they say things like "just recreate the AudioContext", but in our engine that would mean tearing down and rebuilding the entire audio routing graph, and possibly re-decoding audio buffers. That's complicated and we have no code to cover that right now since normally there's no need to ever do that, and implementing it is enough new code that it is likely to cause as many problems as it solves (as already happened recently with an Android audio bug, and that was much simpler!) Other workarounds like "just play an audio buffer at this frequency" don't make sense, because it's already doing that when you play a new sound when coming back, but it still sounds distorted.

    The good news is I think this should have limited impact - it seems unlikely it will affect everyone, it's just certain combinations of playing something else in between Safari.

  • If you add the Browser object and display in a text object the WindowInnerWidth and WindowInnerHeight values, does it report what look like the right values? I still think this kind of issue is likely an iOS bug for the iPad Pro build only for some reason, since it seems to work fine everywhere else, and unfortunately I can't guarantee that there's anything much we can do about iOS bugs, even with a device to test on...

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • That just seems to cover getUserMedia (i.e. webcam/microphone feeds). I'm not aware there's any official support for DataChannel yet, but I think it's in the works.