Ashley's Recent Forum Activity

  • The report mentions a AMD Radeon HD 7480D GPU, which from a quick search looks like it was released in 2012. So it's fairly old hardware.

    The problem with old hardware with no further driver updates, is if there's some kind of driver bug causing a serious problem like a crash or a security issue, the manufacturer is not going to fix it any more. Some bugs can manifest seemingly randomly or can be too complicated to feasibly work around. So in that case rather than leave Chrome subject to crashes or security problems, they probably just add it to the blocklist and then it gets software rendering.

    Broken drivers have been a plague on the industry for years. If the manufacturer stops supporting their hardware then they can end up leaving it broken and then there's not much anyone can do. Long-term, the move to the newer graphics APIs like Vulkan and Metal will mean simpler drivers and so hopefully fewer such broken-driver problems - but that's little help to old hardware.

  • Check chrome://gpu, which will tell you if there's some kind of graphics driver problem that's interfering with WebGL support.

    It's very rare these days to lose WebGL support completely - you usually at least fall back to software rendering, so content keeps working, even if the graphics drivers are completely broken.

  • I'm afraid it's not supported right now.

  • It should work after you export.

    It doesn't work in preview mode, because the iframe will request preview.construct.net/myfile.css, and your file is not uploaded there.

  • I don't believe any of that is the case at all.

    • Post link icon

    After about a year of experimenting, I'm unstickying and locking this thread. The local file/folder saves feature is now enabled by default in C3 r219.2+ with Chrome 86+ and will make its way through the beta cycle to the next stable release like any other feature. The related origin trial is now over so there should be no further disruption to the availability of the feature.

    For the record, some further issues came up in beta releases with saving folder projects, so I've decided against merging the changes back to the r218 stable release. The fixes ought to have the full beta cycle to verify them. So this will (finally) ship enabled-by-default for everyone in the next stable release.

    This thread has served its purpose for being a place to notify people about an experimental feature and discuss it or any changes to it. I'm also closing it because threads like this tend to accumulate random support request replies in the long-term, and this is no longer an appropriate place for those kinds of posts - if you have any further questions or help requests for this feature, please start a new topic as you would do for any other Construct feature.

    Thanks to everyone who helped test this feature! It's been a bit of a bumpy ride at times but it's a significant step for the web that browser apps like Construct now have access to the file system. This makes it possible for the first time to provide features like folder projects in the browser. Previously this was only possible with native apps (like in Construct 2), and this step is another sign of the continual progress of the web platform. We'll be running more experiments in future - I'll start separate sticky threads for each of those in a similar manner as we did for this thread. Other experimental features should be shorter-lived before shipping enabled by default - this one was unusually long given the size and scope of features covering file system access in the browser. So, stay tuned on the forum for more experiments!

  • Playing from a URL/path has never actually been supported. (If it ever worked in C2, it was entirely by accident and wasn't specifically coded in, and could have had problems like memory leaks since it wasn't tested.)

    Why not just import all the audio to your project? You cite slow project saving times, but that should not be a problem with a folder-based project, since that only saves changed files.

  • It's virtually impossible to help unless you can follow the bug report guidelines (i.e. reproduce the problem in a minimal project and provide steps to reproduce).

    Given the fact we are running pretty much identical code in all browsers, it seems very unlikely it's actually anything to do with the browser version, and that is just a red herring that you've falsely correlated with this. If that's the case, then we have nothing to go on at all - hence the need to follow our guidelines for issues.

  • FYI it's impossible to even show anything about a plugin if the plugin's not installed, since the plugin defines things like its capabilities and events. The best we could do is mass-delete everything that references it.

    I'd point out though that by using third party addons you're relying on them for the long-term support of the addon, and if they turn out to not be willing to support their addon long-term, then you can end up stuck like this years down the line. It's important to only choose reliable third-parties who are willing to provide long-term support for any important projects - and you might have to pay for the work involved in that kind of support commitment.

  • Issues are filed on our issue tracker, where you can also find known issues, including this one.

  • Yes, there are lots of options and features for this. See supporting multiple screen sizes

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • That's right, Visual Studio 2019 appears to have dropped support for JavaScript UWP projects, which is why we document that you have to use Visual Studio 2017 specifically. Usually dropping support in the latest release is the first step in retiring support completely. I would expect that eventually the Microsoft Store will stop accepting JavaScript UWP projects, at the latest by the time VS2017 reaches its end of life (probably by 2022 judging by the mainstream support period), since by then there will be no actively supported version of Visual Studio that supports JavaScript UWP projects.

    This also raises the question about whether we should keep or remove the UWP export in Construct 3. They are by far the least used exporters. This always surprised me, given how much people talk about how much they want console support, and this being the only officially supported way to publish to Xbox One. It seems in the end hardly anyone actually uses it. I guess people are using publishers who do console ports instead. Frustratingly I've not been able to find any official line from Microsoft about this, so I don't know what their plans are. So I guess we keep it so long as VS2017 is supported and the Microsoft Store accepts its apps. But given this situation, it doesn't seem remotely worth the effort doing any further development work on it ourselves at all.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,769,157 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x42
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs