Ashley's Recent Forum Activity

  • > It violates a fundamental security property that only the addon author has permission to update their own addon.

    That's why I mentioned maybe only explicitly marked as deprecated addons by the author.

    Marking your addon deprecated does not mean "I give other developers permission to overwrite my addon" and I think it would be wrong of us to use that setting in that way.

    I'm not talking about making an auto-update. The addon should still be treated as a different addon.

    The entire addon system is set up so the addon ID is what defines an addon, so a different addon with the same ID is not in fact a different addon and there isn't currently a system set up to be able to identify such addons as different. Besides, if the auto-updater doesn't update such addons, then users still need to manually hunt down an updated addon.

    If you think deprecated addons should still be protected, could you at least look the suggestion of github.com/Scirra/Construct.net-website-bugs/issues/205 that has been ignored for over a year?

    If the original addon developer is active enough to add someone as a maintainer, then why not just send them the ported code to publish? The real problem is addon developers who have become inactive and unreachable, in which case implementing an addon maintainers feature does not help the situation at all.

    I'm afraid I don't see any easy answers here.

  • Another way to say it is: We want global layers but that don't share object instances. Can you "just" make it an option to have global layers do exactly all they already do but share objects?

    I'm afraid as I said the existing global layers system is extremely complicated and very difficult to change, and as the design proved highly problematic, I would not want to add a second separate system that uses the same design. So anything along the lines of global layers would be a major project with many difficult complications and a high chance of accidentally breaking other things.

    I think the easiest way to solve this problem might be some way to make batch changes across layouts - for example if you add a layer "Background2" above "Background1", have the option to repeat that change for every layout in the project that has a layer named "Background1". There would need to be something similar for renaming, moving, and deleting layers, and perhaps also an option to copy a layer's properties over all the other ones in the project with the same name. However it would be a tiny fraction of the work and complexity of anything involving global or "template" layers. Would that do?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Global layers are intended to solve this problem. Using a global layer covers all content and properties of a layer and allows propagating those changes to other layouts automatically.

    Global layers do not themselves cover adding and removing layers, as if you add a new global layer, you need to go and add new override layers in all the layouts that use it. But there is another approach using sub-layers: if you have something like a set of global UI layers, you can make one global UI layer and add all your other UI layers as sub-layers of that. Then if you make any change to the sub-layers, such as adding a new layer, those changes are automatically propagated to all other layouts.

    Here's a project demonstrating that approach: global-layers.c3p

    If on SourceLayout you add a new sub-layer UISub3 and place a Text object on to it, then switch to InheritingLayout, it has automatically updated with the new layer and content. So perhaps that's a decent workaround.

    FWIW, the design of global layers looks straightforward and seems obvious, but in the end it wasn't actually a great design. It has ended up extremely complicated internally and is an endless source of difficult bugs. Touching that code in any way is very difficult and feels dangerous, which makes us wary of further modifications. Then any further requests to change it have to be balanced with the constant 5+ years of work of other suggestions. So if you can get by using sub-layers of a global layer, that would be the best approach for now.

  • I don't think this is a straightforward thing to do. It violates a fundamental security property that only the addon author has permission to update their own addon. Further, we absolutely do not want to allow people to submit new addons with the same ID as existing SDKv2 addons, as that will result in compatibility nightmares. So even if we only allow submitting an SDKv2 addon with the same ID as an existing SDKv1 addon, that author has then "claimed" the SDKv2 addon ID and nobody else can publish a new SDKv2 addon using that ID. So if someone uploads a partial port of an SDKv1 addon to SDKv2, then abandons it, it's still the case nobody else can publish a new and better port of the original SDKv1 addon. It even opens up the possibility someone could claim a popular, un-ported SDKv1 addon, develop a malicious addon as an SDKv2 port, and then have the auto-updater distribute the malicious addon to everyone. Installing an addon from one developer doesn't mean you inherently trust another developer.

    Meanwhile I think it's reasonable to say you should have the consent of the original addon developer before publishing an update to their addon, especially if it was not originally published under an open-source license, in which case obtaining their consent is likely a legal requirement. If you can reach them to get their consent, then presumably you can also send them your SDKv2 port and ask them to publish that for you. Another problem is if another author does an SDKv2 port, and then the original author turns up and does an SDKv2 port for the original addon, which should the addon auto-updater choose? Duplicating addon IDs fundamentally creates an ambiguity which then causes follow-on problems like that.

    So I think this is in the category of things that sounds obvious but actually has a bunch of complications. It is the original addon developer's responsibility to update their addon, and users only have implied trust in the original addon developer and should not be assumed to trust some other developer updating their existing addon. Outside of that, distributing unofficial ports separately, at your own legal risk, and at the user's risk if they choose to use it, at least avoids the problems caused by allowing other authors to essentially overwrite or duplicate other developer's addons, possibly without their consent.

  • Thanks for informing us Ashley, and for the workaround! Very odd that it only detects the single gamepad input.

    The problem is actually that sometimes it detects a single physical gamepad as two gamepads, in a way that is impossible to distinguish from actually connecting two gamepads. So until they fix that, there's no way to tell apart one gamepad incorrectly appearing as two gamepads, or actually having two gamepads. Our workaround is to only support the last connected gamepad so this doesn't cause a problem.

  • I just want to update this thread with the latest from the r472 release. Unfortunately we have been waiting for some time now for the underlying WebView2 bug to be fixed. To help get us by for the time being until it is fixed, there is a new workaround in r472 for Steam games: the Gamepad plugin now includes a wrapper extension (scirra-gameinput-x64.ext.dll) to directly read gamepad input from the modern Windows GameInput API and send the inputs to JavaScript bypassing WebView2. Essentially it's our own custom C++ implementation of gamepad input to work around this issue.

    For non-Steam games, you can still use the workaround described earlier in this thread: add "allow-host-input-processing": false to package.json, and also delete scirra-gameinput-x64.ext.dll from the exported files, since if it exists it will use the GameInput workaround which has some limitations (described below). This should restore gamepad input using the fully-featured browser built-in Gamepad API.

    For Steam games you cannot set "allow-host-input-processing": false as it will break the Steam Overlay. Instead you can now use the GameInput workaround, which is used by default for all Windows WebView2 exports. GameInput should have good controller compatibility as it is a superset of all prior input APIs, covering XInput, DirectInput, Raw Input, HID, and WinRT APIs - for example I have successfully tested both Xbox controllers and a PS4 controller (which was not historically supported out-of-the-box on Windows). Note however the GameInput workaround currently has a couple of limitations:

    • Due to a GameInput bug currently only a single gamepad is supported. Input from multiple gamepads simultaneously is not supported when using GameInput - the only active gamepad will be the last connected one.
    • Haptic feedback (rumble) is not currently supported
    • GameInput should work out-of-the-box on some Windows systems, but you need to install the GameInput redistributable installer to guarantee support. This can be made part of the install process for Steam.

    To get the GameInput redistributable installer, download the GameInput NuGet package (click 'Download package' on the right), rename .nupkg to .zip, open the zip, and extract redist/GameInputRedist.msi. This is the file that needs to be run as part of an install process (or locally for testing purposes) to ensure GameInput support is available.

    GameInput diagnostic messages are logged to the browser console, so you can check there to see the status (such as whether it loaded OK and which devices its detected, or any error messages).

    Remember if you test with app ID 480 (Space war) you may need to disable Steam Input in its settings until you get your own app ID. (This is just because of the configuration of Space war and isn't really anything to do with GameInput.)

    I appreciate GameInput isn't as straightforward as using the built-in support but the idea is this will provide basic support for gamepad input until the WebView2 issue is fixed, at which point we can delete all the GameInput code and just go back to using standard browser-based Gamepad API input like everything else uses, and then we won't have to worry about any of this. So hopefully this helps in the mean time.

  • I did test this after making the change and it looked like it was working correctly for me. If you think anything isn't working correctly, please file an issue following all the guidelines. I need all that information to be able to look in to it.

  • Most of Construct's exported content goes in the 'www' subfolder, so you should be able to overwrite that with files from another iOS export and have it update. Do not use a different export option though, as the generated files depend on the exporter. I'd also warn you that many types of changes will change other exported files, such as changing various project settings, adding/removing certain plugins, and so on. So I'd still advise a full export periodically just to make sure everything is fully up-to-date.

  • This approach is not supported. Use Construct's Android export option instead.

  • I'd definitely recommend separate Sprite objects rather than one Sprite object with tons of content on it. See memory usage - Construct's memory management either entirely loads all a Sprite object's animations, or unloads them all; if you have everything in one Sprite, it will either have everything loaded or nothing, but if you have everything in multiple Sprite objects, you can have just some of those loaded.

    You can then add all those Sprite objects to a Family so you don't have to repeat events. You should be able to use 'Replace object' on your existing events with a Family so you don't even have to re-do the events.

    And on a Meizu Pro 7, I get artifacts and a white screen with a sad smiley face in the upper left—basically, it crashes.

    These are characteristics of graphics driver bugs. So it might be crashing due to a buggy GPU driver rather than running out of memory.

  • rusya119a - I'm not sure I follow... it sounds like you started off talking about GPU performance, and then you went in to a whole bunch of things but didn't talk about GPU performance again. So I'm confused as to whether you really think GPU performance is an issue now.

    You raised a whole load of things that involve a lot of complex tradeoffs. I could probably write a whole series of blog posts covering a full response. I'm afraid however I just don't have the time to do that. I've just added a few responses off the top of my head in the time I have available.

    I would however point out that you're comparing Unity - a billion-dollar public multinational corporation with thousands of staff - to Construct - a small UK company with a handful of staff. The fact we even merit comparison is, I think, quite a credit to us.

    1. WebView Overhead Construct apps run inside a WebView (Cordova/Capacitor). While functional, this essentially runs a full browser instance inside the app.

    These days I don't think this is actually significant. I also don't believe it affects GPU performance at all - WebGL and WebGPU come down to the same GPU commands a native app would use.

    2. Native vs. Interpreted Execution (The GC Issue)

    Well-written JavaScript code (which we have) can come pretty close to C in performance. It's also been a long time since I've seen good evidence the GC is responsible for any performance degradation. Modern JavaScript GCs are generational, incremental, and concurrent, meaning they have less work to process, collection can happen on different CPU cores, and the work done on the main thread can be done in tiny increments well within a frame time, all making the performance impact negligible in most cases. People often misattribute things like this - what if you're skipping frames because of v-sync scheduling misses? It's necessary to rule out other causes like that before you point the finger at GC. So please share your evidence - if GC really is an issue in some case, it is possible we could optimize things to reduce GC pressure - but as I said it's been a long time since I've had to do that.

    3. Thermal Throttling

    Thermal throttling happens in the hardware and affects all software.

    4. Tooling and Profiling (Critical)

    If you want more advanced tools in this area, use the browser developer tools. They have things like performance profiles, flame graphs, memory analysis and more.

    5. Texture Management Support for KTX2 / Basis Universal

    Compressed texture support involves tricky tradeoffs. All compressed texture formats are lossy, and so degrade the quality of your artwork. This is generally a poor fit for 2D content where people want pristine artwork. It's easier to get away with lossy images with 3D content, as it often appears distorted (e.g. far away, at oblique angles, or wrapped around a mesh). Perhaps we could do this now Construct has 3D model support, but then you run in to the next tradeoff: compressed texture formats have much poorer compression than WebP/AVIF. So if you put everything in that format, the project download size would get significantly larger - not great for a web-first engine. You could download WebP/AVIF and then encode to compressed texture formats on startup, but that could significantly increase in-game load times. I don't think there's an easy route to have both a small download size and fast loading times with compressed textures.

    Suggestion: Implementing SDF (Signed Distance Field) font rendering

    SDF font rendering is monochrome. The Text object supports quite a lot of color formatting options, as well as color emoji. So this also involves tricky tradeoffs and is definitely not as obvious a thing to do as it might sound.

    7. Blur

    We could definitely do improvements in this area. The main complication is the effects compositor is one of the most complex parts of Construct.

    8. Mobile Simulation Tools

    Browser developer tools can emulate mobile behavior and even allow throttling performance. However I don't believe there will ever be as good a substitute as running on a real device. I don't think anyone else in the industry heavily relies on powerful PCs trying to pretend to be a weaker device, instead of just having some actual devices to hand to run on. Construct's Remote Preview makes it pretty quick and easy to try things out on mobile devices, and it's one of the reasons we have it.

    9. I've noticed that even with the Preload Sounds checkbox enabled, the game might not launch at all on my older devices.

    If you ask Construct to load the entire project's audio in to memory on startup, then yeah, it's going to potentially use a lot of memory. So if you want to reduce memory use, you should definitely turn that off.

  • What happens if I want to hide the status bar but don't want the viewport to cover non-visible areas of the screen?

    Checking 'Hide status bar' exported exactly the same thing as setting the project 'Viewport fit' to 'Cover'. There is no functional difference and so the 'Hide status bar' setting was redundant, hence its removal. There should not be any need to handle anything differently in your project because of this change.

    the project's name is just App.xcodeproj rather than <gameName>.xcodeproj

    That's an intentional change in Cordova iOS 8.0.0.

    I'm not sure if that other error you mentioned is related to that - it looks like something has a typo (presumably FIleUtility should be FileUtility), but it's not clear that's relevant. It might be an issue with a third-party addon. If you're not using any third-party addons and you get a build error, please file an issue.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,762,028 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
  • x125
    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