Ashley's Forum Posts

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

  • The Particles object doesn't support a lot of things, like animated particles, Z elevations, effects on individual particles, etc. That's what object mode is for - set it to create Sprite objects and then you can have all those things too.

  • The beta release r437 that just came out includes an updated Google Play plugin that is updated to use the games SDK v2. It was a difficult process to update it and it's tricky to test as well, so I'd appreciate any feedback and help with testing.

  • If all your settings have been reset, it is because the browser decided to delete all Construct's local storage (sometimes confusingly called "cookies", even though Construct just uses this to remember your settings locally and doesn't send it to any servers or use it for tracking). Unfortunately that is beyond Construct's control. Browser settings, or browser extensions, orientated around privacy or tracking may be responsible for occasionally clearing data, so changing any related settings may help. You can also try pressing 'Request persistent storage' in the About dialog to request that the browser tries harder to keep your data (but AFAIK that's still not a guarantee).

    If you were low on storage space I would guess the browser cleared storage to try to save space. The usual methods of clearing space on disk may help avoid that happening again, and Construct's 'Storage cleanup' dialog may help reduce how much storage Construct is using. It's also probably the case that the more storage Construct uses, the more likely the browser is to choose to delete its storage if the system is low on space.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • FWIW in r437 which just came out the new limit of 1000 for decomposing concave polygons with the 'Fill poly' action is now implemented, which hopefully solves the immediate problem. Although I suppose if you go 10 times further it will hit the new limit.

  • The Taking screenshots example includes saving the image as a file.