Ashley's Forum Posts

  • In this case I would point to the relevant blog post being Optimisation: don't waste your time. These days, Construct can achieve outstanding performance even on old devices.

    Sometimes we optimise parts of the engine we know were previously a bottleneck and write blogs about it. That does not contradict at all the point that it's important to first know it's a meaningful thing to optimise.

  • I'm not aware of any significant downsides to using WebP, and the file sizes can be significantly smaller, which is why Construct now defaults to WebP image exports as of r360+.

  • I didn't know players wanted those settings - I'd have thought a fullscreen experience was more immersive than windowed 🤷

    I polyfilled window.moveTo() and window.resizeTo() for WebView2 as it didn't look too hard (although DPI settings can prove complicated, but I tried to get it right), so that's in for the next beta - hopefully it works OK.

  • The thing is that very few people are facing this performance issue because again : the feature just doesn't exist at all in Vanilla Construct : this is the main issue.

    I was talking about "On signal", a feature that does exist. It might not do everything you want, but it does exist, and I thought its performance should be OK, even if not perfectly optimal. That's what I was talking about, but I think you're trying to talk about a whole bunch of other things, which I think makes it hard for me to get anywhere in this discussion, so I think it's best I stop posting in this thread.

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