Ashley's Forum Posts

  • Vote for this suggestion to add your support.

  • I checked the original report was fixed and the issue is now closed. If there is still a problem please file a new report following all the guidelines. Please be as clear as possible - I can't tell from your post or the video what exactly you think is still wrong.

  • The beta desktop build currently does not work offline, only the stable desktop build does.

    The browser should work fine offline with any release, providing you visit the URL directly and you've loaded that version before. You should also be able to use your account for up to 7 days while offline, provided you were recently logged in while online.

  • Google can issue blacklist updates independently of Chrome releases. So if you actually report it to them they could action it very quickly.

    Meanwhile our own release cycle will take several weeks for any changes to reach a stable release, by which time they may be pointless anyway, and it will require all projects to be re-published with that version. So Google could actually respond to this quicker and in a way that fixes existing projects without requiring republishing. Please at least file an issue with Google.

  • It would be better to pursue Samsung or Google about this since the problem is not with Construct.

  • Note that code does not actually disable WebGL 2. It will still use WebGL 2, but you've overwritten some code to make it always think it's using WebGL 2 even when it's using WebGL 1, which probably isn't what you want at all. Changing the call to getContext("webgl2") instead would work.

  • We don't add new project settings just to deal with temporary bugs. It would end up clogging up Construct with all sorts of unnecessary settings.

    Google can blacklist WebGL 2 only if there is a problem with it on some devices, so that those devices fall back to WebGL 1. This is the best solution, especially since bugs will affect all web content, not just Construct.

  • Updated links in original post with an update for Chromium 67.

  • Please file a bug report following all the guidelines if you want this looked in to.

  • This is a pretty difficult report to deal with.

    - the report involves several different cases and different instructions in different places, making it difficult to follow

    - the project has several buttons and it's not clear which should be clicked in which order for which cases. An ideal repro will run automatically without requiring any user interaction to eliminate wrong inputs affecting the repro.

    - any repro that says something like "wait 5 minutes" means it will take maybe 10x longer to deal with than if you can make a repro that demonstrates the issue within 30 sec. It's common to have to run the repro 30-40 times or more before it's fixed and the difference between seconds and minutes to repro is the difference between a quick fix and potentially spending hours and hours on it, which we can ill afford given the number of reports we get

    - garbage collection is non-deterministic - if you have say 4GB RAM free the browser may simply decide that there's no point wasting CPU time on a garbage collection. You could try clicking the "collect garbage" button in dev tools to see if it's just not gotten round to a collection yet.

    - if it repros in NW.js but not Chrome it suggests that Construct's code is correct (since it works in Chrome) and some aspect of NW.js is leaking, in which case it might be better to file it with the NW.js developers. If you could reproduce it in Chrome though, this would suggest there is a problem with Construct's code and then we might be able to fix it ourselves.

    I think it could do with being re-filed starting from a clean slate and focus on the internal sounds aspect alone (which is the only case the engine intentionally supports as far as I can tell) with clear and concise instructions.

    I tested the repro project in NW.js 0.31 (Chromium 67). I replaced the "every 0.01 seconds" events with "Repeat 10 times", exported to NW.js, ran it and just clicked the "Toggle internal sounds" button. Over a couple of minutes I could not see any evidence of a memory leak. According to Task Manager the memory would sometimes increase to 120mb or so, but then it would drop back down to 100mb or so. This looks like normal garbage collector activity.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You can already build EXEs for Windows with the NW.js exporter, as well as UWP apps for Windows 10+ which is the platform Microsoft are trying to replace the ageing Win32 platform with (which interestingly can also run on non-traditional architectures like ARM, which could be a big deal in future). If we built a native engine for Windows, what exactly would be better? This is what that blog post I wrote was all about. I think many games would not even notice a significant difference, and the downsides are massive. It would have to be a complete rewrite with completely different technologies. This would basically kill our productivity for a year or more, and then permanently slow it down beyond that. I cannot see any way this can possibly be justified, especially as web tech continues to improve, and especially while there are other interesting technologies like WebAssembly that can get some of the benefits of native without actually doing a full port.

  • Generally we need all the information in the bug report form to be able to help. But if you see seams along object edges when zooming out, try adjusting the "downscaling quality" project property. This can be caused by adjacent images on the same spritesheet, and high quality modes ensure things are more spaced apart which generally fixes it, but at the expense of using more memory. So unless you see it in-game it's best not to change it and ignore the seams in the editor.

  • Oh right, it only happens if the mouse is over an undocked scrollable layers pane which is itself over the expanded ribbon bar, which the mouse cursor is also over. In this case for some reason the wheel scrolls the ribbon beneath the layers bar instead of the layers bar itself. In all other cases it scrolls the layers bar normally. Unfortunately Construct's code is not at all involved in the dispatch or handling of mouse wheel events - it's entirely handled by either Windows or our UI library, so I'm afraid I don't think there's anything we can do to fix this. It seems a pretty niche case anyway - you can work around it by simply moving the layers bar off the ribbon.

  • Closing as won't fix. This is a pretty obscure case. A trigger in a sub-event is essentially the same as having the trigger at the top, and all events that are above it actually beneath it as sub-events. Since having an "Else" as a lone sub-event to a trigger isn't valid, this does't work. (Internally when the trigger fires, it runs through all the events above it and checks if they're true first before running the event. Since "Else" means "the previous event did not run", asking when a trigger fires does not make any sense since it did not run the previous event at all, so it has no value for true/false, so the else defaults to returning false.)

    The workaround is straightforward: rearrange the events to put the trigger at the top.

  • R0J0hound is correct. Closing as not a bug.