Ashley's Recent Forum Activity

  • We support that too. Set a storyboard splash.

  • FWIW, this is fixed with built-in functions in Construct 3. Function parameters are preserved across waits in that case.

  • IIRC there isn't a way at the moment. The ColorValue expression currently exists only so you can set an object's color to the same color as another object.

  • I think some confusion about the loading screen arises from the question: what do you show when you are loading the loading screen?

    If you use a loader layout, Construct still shows the default loader while the loader layout itself is loading. This is just on the off-chance the user is on a very slow connection or for some reason your loader layout uses a lot of resources. If your loader layout is small and simple, it should load quickly - so you can set the default loader to "none" and you will only ever see your custom loader layout.

    Even if we supported some custom splash image for before the loader layout itself is loaded, what do you show while that is loading? At some point you just have to either show some pre-set message or image - which cannot be customised, because nothing is loaded yet, not even the settings for the game - or show nothing. You can already do both by using either Construct's default loader, or turning it off and showing nothing until the custom loader layout appears.

    If you have a small, simple custom loader layout, and you turn off the default loader, then you have basically arrived at the same thing as a splash image or custom spinner.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If you want to render the game at a lower resolution for performance reasons, use "Low quality" fullscreen mode. You can change that at runtime too.

    The "Use high-DPI display" was just another way of doing that but with a dependency on the display DPI - since low quality fullscreen mode is a more general way of doing that, the "use high-DPI display" option was removed in the C3 runtime.

  • You should be able to alter a few parts of the returned ImageData and then load it back in to the canvas with loadImagePixelData().

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

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,445,457 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
  • x109
    Coach One of your tutorials has over 1,000 readers
  • x63
    Educator One of your tutorials has over 10,000 readers
  • x3
    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
  • x36
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs