Construct 3 r132

You're viewing a single comment in a conversation. View all the comments
  • 4 Comments

  • Order by
    • [-] [+]
    • 1
    • Ashley's avatar
    • Ashley
    • Construct Team Founder
    • 1 points
    • (3 children)

    It's still complicated to do that - there are no other features that require a layout restart to apply a change at runtime, and currently restarting a layout does not reload any textures because it knows it's using the same set of textures. So there's a new codepath to write for 'reload layout and also reload all textures as if it's a different layout', which will need separate implementation and testing to a normal 'restart layout'. I'd be more persuaded this was worthwhile if you actually had benchmark numbers showing this made a significant difference for a particular game.

    • Alright, makes sense. Although I see implementing such a system in a modular way, as a benefit for future suggestions (e.g. layout-to-layout loading customization).

      I'm not sure how that benchmark would look like. I'd have to measure the rendering performance somehow, do any of the existing performance examples cover this? I don't want to provide something, that's going to be dismissed because it measures things unrelated to this feature.

        • [-] [+]
        • 1
        • Ashley's avatar
        • Ashley
        • Construct Team Founder
        • 1 points
        • (1 child)

        It would mostly affect GPU texture read performance. I'm not sure we have a performance test that directly covers that, but the fillrate test is probably closest.

        • I've used all the included performance tests and some of my own. Using a mid-range PC, there is no noticeable difference in performance.

          Since I'm mainly developing for desktops, I'd consider this feature to be a nice-to-have in the future. I'm not sure how low-end mobile systems would perform but I guess the performance gains would be minimal at best.

          Thanks for the responses!