Ashley's Forum Posts

  • Take a look at the HTML table example which displays data from an array in a HTML table.

  • Is there any chance you could use JavaScript instead of Python? It integrates far better and will give you many more options for passing data.

  • Construct Animate has the video, GIF and image sequence export options, which aren't present in Construct 3. Apart from that all features of Construct Animate are in Construct 3. There's a full comparison table here.

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

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