Ashley's Forum Posts

  • 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.

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • This is by design. The runtime saves the layer using a unique ID rather than its name or index, so that if you rename or move the layer, it can still correctly load a savegame or restore the state of a saved instance. The unique ID identifies a specific layer on a specific layout. Therefore if you change layout, that specific layer is not available, so it defaults to layer 0.

    You could work around this by storing its layer index in an instance variable.

  • Can't reproduce here. The layers bar scrolls with the mouse wheel just fine. I'm on Windows 10 64-bit too.

  • Closing, see the bug report requirements.

  • Can't reproduce here - everything looks just fine in the Layout View, but I'm not sure what it looks like when it's not working. I suspect it's a graphics driver bug. Yes, the latest drivers can still be buggy.

  • The blog post I wrote around 2 years ago on the case against native engines is still pretty relevant. For us, for the foreseeable future, going to multiple codebases would do more harm than good. For example say goodbye to regular releases as all our engineering time is sucked in to huge porting projects to multiple platforms.

    HTML5 is definitely a viable platform for games - all the games built with C2 and C3 prove that, and it's even more the case with technologies like WebAssembly, WebGL 2 and (in future) WebGPU. If the console manufacturers don't recognise that yet, then I think they're behind the times. Remember though that Microsoft have seen what's possible - you can already build and publish Xbox One games using Construct! It's only Sony and Nintendo who are behind the curve on this.

    There is also a third-party console porting service with Chowdren, so that's an option, although it's entirely independent of Scirra so I can't comment much further on it.