Ashley's Forum Posts

  • I don't think it's a simple thing to just turn off spritesheets. Spritesheets are always power-of-two sized, and while WebGL 2+ supports non-power-of-two texture sizes, WebGL 1 does not. There's still enough WebGL 1 systems out there that I think if it just exported a bunch of non-power-of-two individal images then your game will be broken on a small percentage of systems, but enough that you'll get a lot of "game doesn't work" reports.

    Then there's other issues like larger games losing the benefits of spritesheets could become significantly larger to download and significantly slower to load, and have a runtime performance hit too. It could be a massive deoptimisation for your game that slows things down even for players who don't want to mod anything and just play the stock game, which I think is an unfortunate trade-off.

    Perhaps some of that can be mitigated in various ways, but it's complicated. Modding is a very large area if you want to go further to adding new kinds of objects, changing game logic, adding new kinds of level themes, etc. as well. I fear this may be one of these areas people say "just add A!" then "just add B!" then "just add C!" and then on for another 20 things over months/years.

    Perhaps there's other ways to solve this - for example if Construct could export metadata about spritesheets (i.e. the location and size of every image), then in theory some external tool could take a folder of individual image files and paste them over spritesheets, and that could be robust against future changes to the project. It would keep the benefits of spritesheets and only need a minor change to Construct, exporting some extra info it already has.

  • You can load sprite images from a URL which might work better. That bypasses the whole spritesheeting system.

    • Post link icon

    Update: this thread previously had preliminary documentation for writing WebGPU shaders. As WebGPU support is now more mature, we've moved the documentation to the Addon SDK manual section on WebGPU shaders. This thread is now no longer sticky; please refer to the Addon SDK manual for the latest documentation.

  • Why not use an array instead of function parameters?

  • What are you trying to do? Usually the parent global is only set if the document is running in an iframe. So it's normal that it's not set to anything if you're viewing it as a top-level page.

  • Hmm, I wasn't sure if browsers actually paid any attention to the persistent state, but if they do maybe it would be worth exposing in the Local Storage object.

  • The error message doesn't make any sense at all to us. My best guess is it is caused by a broken browser extension, not Construct. Try disabling any browser extensions you have installed.

    The only place the function mentioned is actually used in Construct is when pressing a keyboard shortcut, and keyboard shortcuts are working normally everywhere in Construct as far as we're aware, and nobody's issue reports mention pressing a key at all. Broken browser extensions are usually the cause of this kind of problem that makes no sense and can't be reproduced consistently by others.

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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