Ashley's Forum Posts

  • Sorry, I'm not sure what you're asking here? If you're asking for a new feature, I can't really tell what it involves from a quick read of this thread. I'd advise using the feature suggestions platform as usual with a comprehensive description anyway.

  • Well, not really, the events I mentioned are the best way to check timings. Maybe there's a problem with the debugger where it doesn't show updated information quickly or something.

  • Yep, this again... I think the thing most people don't understand is that native exports could actually make all of these problems worse. It would also involve such a colossal amount of work that it risks ruining the entire company. We've only come this far because web technology allows us to re-use virtually all our code across every platform.

    To just really quickly run through some of your points:

    Custom loading screens: loader layouts already let you show a layout as the loading screen, allowing for completely custom display. (Native engine is irrelevant here)

    Orientation: it's not clear why this is necessary? (Native engine makes no difference to this)

    Multiplayer: networking is a super complicated area and is basically an expert level feature. I was quite uneasy implementing it in the first place because of this - it's a huge jump to go from non-programming blocks to things like lag compensation in a real-time online multiplayer game. Even though Construct takes care of loads of details for you, you still have to deal with some fundamental complications like synchronization. I'm not sure what we could do to fundamentally fix this. (Native engine makes no difference to this)

    Monetisation: I know this is important, but it's a huge amount of work and requires constant maintenance to cover things like ads and IAP, and a regular source of awful bugs that are really, really hard to fix. We're a small team with limited resources. If we added any more services, I can imagine us quickly spending 100% of our time just maintaining them and dealing with all the problems. So our approach is to cover some basic options and leave other services - of which there are dozens and dozens - to third party developers. (Native engine would not solve this either, since it's to do with maintenance and workload)

    Performance: GPU drivers are native technology! So if driver problems cause poor performance, a native engine won't fix that either. In fact browsers have done a ton of work to avoid performance pitfalls and crashes in GPU drivers. Last I saw for example ANGLE (used by several browsers) had workarounds for hundreds of driver problems. If we make a native engine, we will have to re-do all that work ourselves, or face all the performance pitfalls, crashes and glitches. So I genuinely think a native engine would make this worse, not better. I often read about native developers having a total nightmare over this, so I think web technology is a good choice and this aspect of it is underrated.

    It's easy to think of native code as being a magical solution that makes everything better. But in many cases it's either irrelevant, or could actually make things worse. There was a better case for it if you go back 5+ years, but now I think there is very little reason at all for it - especially with technologies like WebGPU on the horizon that have a decent chance of actually overtaking native technologies in some respects.

  • Thanks for making this, it's interesting to get a better idea of how people imagine the scene graph working.

    I like the approach of having a hierarchy bar that shows all the connections as a tree.

    At the moment the proposed way of treating "scenes" like "object types" is awkward to fit in to Construct's current architecture. An object type is something that directly has instances, variables, behaviors, picking capability in events etc. itself, and scenes don't seem to be quite the same kind of thing as that, so I think it would be better to approach that differently. Perhaps there could be a separate view that shows all objects at the root of a graph, which is what a "scene" appears to basically be.

    The scene editor also seems to duplicate a lot of what the Layout View does - it seems to make sense to me to just do all that in the Layout View directly.

  • The error message tells you what is wrong - the addon ID is misconfigured. Usually you can press F12 and check the browser console for more details.

  • One of the problems we have with feature suggestions is the vagueness of many suggestions - the filed suggestion says little more than "make a scene graph feature", which means it's pretty much left entirely up to our interpretation of that. We have some rough plans, but our job is to make what users want. The risk of a vague suggestion is we do what we think was meant, but really people were thinking of something else. I try to encourage people to be detailed and comprehensive but often that doesn't happen.

    If you think the scene graph should work in a particular way, now is definitely the time to explain what you think that should mean, in detail. Screenshot mockups, comparing various approaches, thinking about advantages/disadvantages and tradeoffs, the various editing facilities, the runtime features, the edge cases that might trip people up, how it might tie in to other existing features and potential future ones... all of that is important and can result in significant delays if it's not properly thought through in advance. You don't have to do any of this - if nobody does, as I mentioned we'll just do our own interpretation of it - but if you have strong feelings about how it ought to work, the sooner you provide a comprehensive and clear explanation of what that is, the better chance we have of incorporating that.

  • You've not shown any events that indicate how long the action took. So you could just be measuring this wrong and being misled by whatever you're looking at.

    Either use the 'Wait for previous actions to complete' system action, or the 'On item set' trigger, to find out when the write to storage completed. Even on a slow system it should complete within a couple of seconds, and most of the time it should be almost instant.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Coincidentally, we actually recently started development work on this. However it will likely be a several months long project given the size and scope of the feature. I've updated the feature you linked to.

  • IIRC, I tried the project you provided and it worked just fine in Safari on both macOS and iOS.

  • Apple ban other browser engines on iOS, so Chrome is just a skin for Safari. Safari only supports fullscreen on iPads, not iPhones.

  • Construct already sets the target SDK version to 28 when exporting. I just tried it and verified it does set that. So you shouldn't need to change anything. Make sure you're using the latest version of Construct.

  • This sounds like a bug we fixed in the latest version of Construct - try using r206+.

  • This blog post also goes in to some detail about this.

  • The build service is working fine for me. Check your Internet connection is working.

  • We're always busy with tons of things to do - I'm afraid while I'd love to do all this we just don't always have time, so I'd proceed on the assumption this won't be available for the time being.