Ashley's Recent Forum Activity

  • The reason I am asking is not because I don't understand it - we use the addEventListener model a great deal in our own JavaScript code - but because I need to understand the relative priority. This year alone around 7 years or more of feature suggestions have already been filed on the suggestions platform. It's an absurd, totally inconceivable amount of work, and people keep suggesting yet more things in threads like this. How do we figure out what to work on? In part, by figuring out how bad the problem is.

    Even if you had performance issues with your project, how do we know you're not literally the only person to ever have a performance issue with that particular feature? We can't afford to build features that only one person needs - there are far too many other features that could improve things for lots of users that would be better to work on. It could well be that the performance is fine for 98% of projects, and not fast enough for 2% of projects, in which case I'd probably say it's not something that should be prioritised. However if performance is only OK for 25% of projects and is poor for 75% of projects, I'd probably say it's a more important thing to look at.

    The best way to make your case that it's the latter rather than the former is to make a project file that is reasonably designed and demonstrates a performance problem. That can make it clear that many projects may be affected. And then I have a real project I can try out - it may be possible to make tweaks to the engine that solve the performance problem with much less effort than building entire new features.

    That approach can much more quickly arrive at a good understanding of the problem, or more quickly identify workarounds or other solutions that help. I'm afraid that writing long posts doesn't achieve that.

    So I'd ask for your understanding and co-operation: I'm not refusing to understand, I want to better understand the actual problem in a meaningful way, and long forum threads like this do not generally help with that. I'm asking for the things I really need, and if nobody provides them, then probably nothing much will happen: we just have far, far, far, far too much other work that's already been proposed, and some of it already looks compelling, so that will take priority.

  • Yes the performance does matter a lot.

    Do you have performance benchmarks that demonstrate the performance overhead of "On signal" is too much for reasonable use cases? I think it would be surprising - why would you need something like thousands of signals per frame? If you are doing something like that wouldn't another feature like functions be a better approach anyway?

  • Does the performance overhead actually matter? Are you firing signals 1000 times a frame or something? If so why? If it's not actually a problem, then it doesn't actually need optimising.

  • If the project 'Export file structure' is 'Folders' - which is now the default - then you also need to include the subfolder path in strings with audio file names.

  • I can't seem to reproduce this in Firefox.

  • Well, there's the "Signal" system action and "On signal" trigger, which provides a basic event listener system.

  • E.g. player would select scale factor 1, 2, 3, 4 etc and it would resize the window based on that.

    Why not use letterbox integer scale? That essentially does that and supports any window size. So then you shouldn't have to be trying to change the window size.

  • If it works in Chrome, it probably means Construct is working correctly - if the problem was with Construct then it wouldn't work in Chrome either.

    I think Brave has very strict privacy settings by default. This may mean it intentionally deletes local storage (confusingly also referred to as "cookies", although the term means any locally saved data). If it does that, then all you can do is change the browser settings to not do that.

  • I'm not sure, possibly - but games tend to redraw every frame anyway, so it's probably not that significant. Either way it's fixed in r364+.

  • Then you could add "unpredictable tick order", "single timer only mode", etc. all to make up the performance difference... and now what's meant to be a simple feature is full of complicated configuration options, which makes it harder to use, unfriendly to beginners, makes the code much more complicated, and usually ends in lots more bugs. It's not worth it. It's pretty much the approach we took with Construct Classic years ago, and it ended in development hell.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I tried this out and was surprised to find it is indeed the case - adding a Text object in the editor increases the GPU work, even if you are not doing anything.

    It turned out to be a regression from fixing a bug a few releases ago (#7358). It's just causing the Text to keep redrawing. I fixed it for the next release so it won't use any extra GPU.

Ashley's avatar

Ashley

Online Now
Early Adopter

Member since 21 May, 2007
Last online 24 Jun, 2026

Twitter
Ashley has 1,766,788 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