Ashley's Forum Posts

  • Closing as there is nothing we can do if you do not follow the bug report requirements.

    If you think it's a Windows issue there's no point reporting it to us anyway, report it directly to Microsoft.

  • We removed WinJS from the C2 export since we didn't need it for anything, but Microsoft's own ad SDK apparently requires it. They said they are working on an update to remove the dependency too. I asked MS for an update on the status of the ad SDK before the stable release and they never got back to me. I didn't want to hold up the stable release over some unspecified release date for an MS component, so it's out anyway. Hopefully MS will update the ad SDK soon and remove the WinJS dependency. Until then you can roll back to the last stable if it's a problem.

  • newt is pretty much spot on.

  • I am skeptical of relying on this and wonder if the system condition ought to exist at all. The question is "what defines mobile?" Most people would say a tablet qualifies, but then what if you add a keyboard? Then a mouse? Now you have a laptop, which most people would say qualify as a desktop type system. What about a large phone with a mouse and keyboard attached? Where do you draw the line? If you force a touch-only UI on these devices, aren't you ignoring the fact they can type and use a mouse?

    IIRC the condition basically checks if it's a "mobile OS", i.e. Android, iOS, Windows Phone (which now is just part of Windows 10, making the distinction even blurrier). But note those devices can also run in what is essentially a desktop mode.

  • I think it's caused by the browser initialising the positioned audio engine the first time you use it.

    It looks like from the other report they made some changes to improve it, but you're not testing with the changes, your report still says you're using Chrome 52. Try grabbing Chrome Canary (currently v55) and seeing if there's still an issue there. It can take a few months for any changes to propagate from Canary to Beta to stable.

  • Export for Cordova and build with a service like Intel XDK or PhoneGap Build. We have tutorials covering it all.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You really should get Windows 7 or newer. Windows XP is well past it now.

    • it doesn't get security updates so you will be vulnerable to security flaws
    • Chrome has dropped support for XP/Vista so you will no longer get Chrome updates
    • you can't use/test Edge or Windows Store apps (need Windows 10 for that)
    • Construct 2 can't encode AAC files on XP/Vista
    • graphics drivers are often old/buggy/unavailable
    • no good 64-bit support in the OS
    • by now we probably won't fix any C2 bugs that only occur on XP (although I don't think there are many)
    • although I can't say anything for sure right now, I cannot guarantee that C3 will run on XP/Vista

    Seriously, don't even consider XP or Vista now. It's like buying Windows 95 in 2010.

  • Chrome devtools says it's "Sansita One".

  • Okay well if you can't even test it yourself then we can't follow up this bug report and will leave it closed.

  • I just posted a comment on the MS report linking to the C2 reports, that should be enough for now.

  • These days pretty much any system you buy with at least Windows 7 and new-ish hardware is probably going to be fine.

  • You still haven't said if any other browsers are affected. This is critical information when dealing with bug reports.

  • andreyin - I think we've sufficiently made the point that C2 devs want this, with 92% votes for interest Microsoft said they read the whole thread and the feedback was super useful.

  • C2's offline support means that while the first time you run an app does download it from the web, every time after that it actually loads off disk, so you don't need to be online.

  • Huh, this is interesting - I could actually reproduce a leak in Chrome by pressing F1 and F2 pretty quickly. I got it up to 1 GB at one point. The video plugin is destroyed when you change layout, and it does run cleanup code, which includes pausing the video if playing (there's no "stop" in JS), and throwing away the video (just dropping the reference, there's no "destroy" or "cleanup" command in JS for video). However this does not seem to be enough to have it released from memory. I found one tiny tweak which seems to fix it though: now when the video is cleaned up we reset the video src to empty, so it drops the reference to the video file. This appears to properly clean it up and prevents Chrome heaping up memory. It seems to work OK in NW.js as well.

    Here's the tweaked video plugin runtime.js if you want to test it yourself: https://dl.dropboxusercontent.com/u/15217362/video_runtime.zip

    (Extract over exporters\html5\plugins\video\runtime.js and restart C2)

    I think this is a workaround to what is basically a browser memory leak. If it works, this could save a lot of memory!