Ashley's Forum Posts

  • See the guide on optimizing download size which has lots of advice on the subject.

    As described in this blog on lossy spritesheets, with AVIF lossy images can look pretty much indistinguishable from the original and significantly reduce the download size. If you're not sure how it will look with pixel art, back up your project, change all images to use lossy compression at some quality level like 75, and then try a test export with AVIF, and just see how it looks. If you notice any quality issues you can try again with a higher quality level. If you'd rather go with lossless images, make sure you export with WebP.

    Another option is to export with PNG images and then compress them using Pngquant

    If you care about download size, my best advice is don't use PNG any more - WebP is almost always superior, and AVIF is even better if lossy is acceptable.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I've fixed this for the next release cycle (we're a bit close to a stable release to ensure translators have time to update it). In future you can report any spelling or other text issues to the issue tracker where we are more likely to see them.

  • Failed to load resource: net::ERR_HTTP2_PROTOCOL_ERROR

    This looks like some kind of networking error occurred. Try clearing your browser cache and giving it another go.

  • Construct 3 updates this.x and this.y when the layout resizes

    Construct doesn't update object positions when the layout or viewport size is changed, so I think you must have gotten confused about something else.

    is _draw V2 or V1?

    It's SDK v2. The SDK v2 reference is here. The older SDK v1 reference is in the Addon SDK manual and every page has a note at the top about the SDK v1 retirement. Generally all SDK v2 methods use camel case (e.g. myMethod()) and all SDK v1 methods use pascal case (e.g. MyMethod()).

  • Yes, we have plans for leaderboards to work independently of the Construct Arcade.

  • ForsakenBA - with buggy graphics drivers anything can happen. Even using an entirely different app could crash Construct.

  • The Construct editor still renders with WebGL by default. You can switch the editor to render with WebGPU in Settings. If you've done that and you experience regular crashes, you can change it back to revert back to WebGL rendering in the editor.

    I would guess the editor is rendering with the default WebGL and the crashes are caused by your graphics driver crashing, and it started happening more recently due to a buggy graphics driver update. It's a common kind of problem unfortunately, and such issues are not actually Construct's fault, but there's not a lot we can do about it.

  • I'm not sure what happened, but I just rebooted the build service and it appears to be working normally again. Apologies for the disruption.

  • I did see that but I'm not sure how beneficial it would be - note this remark from their blog post:

    This feature should be used sparingly though - compiling too much will consume time and memory!

    The default mode of JavaScript engines is pretty great - it starts interpreting instantly (no long upfront compile times like many other tools), and it observes the hot paths for the specific project being run and tiers those up to more optimized code in real-time, so only the things that matter get highly optimized. I suspect after a few seconds of looking at a game's title screen much of the engine that matters has already reached full optimization and so everything already runs great once you start playing.

    Eager compilation of the entire engine, including all the startup code, rarely used bits, etc. could actually delay optimizing the parts that matter and so have a longer period of poor performance at the start of the game. For example if a game does not use mesh distortion, but the JS engine is asked to eager-compile the mesh distortion code in the engine ahead of the code for rendering sprites, then it's actually made things worse.

    I suspect things like this are better for web page load performance where people are more sensitive to the time until pixels appear on the screen, and the page provides more context about what code is likely to be run. General purpose tools like Construct tend to have a lot of general purpose code, and each project uses a different subset of that, so it doesn't sound like a great case for eager compilation. Still, you could give it a go - export a project, put the magic comment at the top of c3runtime.js (or c3main.js, depending on your export options), and see if it helps much!

  • (Moved this from the Construct 3 forum to Construct 2.) Construct 2 was retired in 2021 and is no longer supported. Our latest advice for Construct 3 is in this guide.

  • ${runtime.globalVars.TempoTotal} is not valid syntax outside of a template string. Try just using runtime.globalVars.TempoTotal on its own.

  • Try this:

    1. Add the Construct Game Services plugin to the project
    2. Use the 'Submit score' action when you want to submit a score to the leaderboard - leave the leaderboard ID empty
    3. Upload to the Construct Arcade
    4. Play the game up to the point a score is submitted

    Then the leaderboard should appear on the Arcade.

  • For reference, Command & Construct is over 8000 lines of code, and full TypeScript validation takes <1 second for me after the first preview (the first takes longer as it warms up caches and such, which is normal and to be expected - regular previews afterwards are faster).

  • I'd want to see a real project showing this happening first. It's normally very fast - fast enough that it can validate a large file as you type, so even with a large amount of code it ought to be OK, but perhaps not, or perhaps there's some kind of fault happening. If it's confirmed that it is just pretty slow in some cases then maybe we could think about ways to optimize it, or even a setting to just entirely bypass it, but I'd still want to check in case there is something simple that can be done to take it from 10 seconds to <1 second, and then we don't need any other measures.

  • It's intentional. It is just one of probably dozens of subtle trade-offs and heuristics in the spritesheeting system that we've carefully tuned over the years.

    The limit is arbitrary, but the goal is to avoid a worst-case scenario of a single small sprite image sharing a spritesheet with another sprite with loads of animation frames. For example imagine a small 50x50 image for a button on the title screen ends up placed on a 4096x4096 spritesheet which is entirely full of animation frames from the boss at the end of the game. Now to display that button on the title screen, it must load the entire spritesheet of mostly boss images, using a minimum of 64 MB memory for the entire spritesheet. If you imagine that happening another 10 times with different objects, now you are looking at an extraordinarily high memory usage of 640 MB for just a few buttons on the title screen - an appallingly inefficient result. This heuristic means the boss sprite gets its own spritesheet and avoids that happening. There could still be other unrelated shared content on the button's sprite sheet, but there are other heuristics to try to group objects likely to be used together on the sheet, and if lots of different objects are on the sheet it's more likely some of them will also be useful.

    In other words sprites with lots of animation frames tend to use a lot of memory, and in that case it's best to move them off to their own spritesheet so they are loaded separately for better memory loading granularity. This is also usually a good idea to reduce the download size as well, as modern image compression algorithms do a better job when an image has lots of repeating or similar content on it. We have an arbitrary threshold of 8 frames to switch to this mode. I prefer not to document such fine details of the spritesheeting engine, because we change such details from time to time, and if people assumed we used some specific number and then we change it, it might actually make their project less efficient. So my advice is to ignore such things.

    In case you're wondering if Construct could do a better job, I'd point out rectangle packing is NP-hard, which basically means an optimal solution is an unsolved problem in mathematics, and that's not even taking in to account other factors like memory loading granularity and download size optimization.