Ashley's Forum Posts

  • You should only add the event listener once. I can't see from the screenshot whether the event blocks do that. It would probably be best to add it in a script file, because even if it's under 'On start of layout', it could still add the listener multiple times if you keep revisiting the layout.

  • The differences are documented in the manual: see scripts in event sheets and script files.

  • It's the Chromium browser engine that needs to be updated, not just Android. The work appears to be tracked in this issue which mentions moving Chromium to Oboe.

  • Adding a script file with the original code should work. Listening for the "message" event on window is the correct approach.

  • You can write as much text as you like in comments in event sheets (including with BBcode formatting). Alternatively you could add a plain text file as a project file.

  • If your game is under 5mb (since it seems you said loading a 2mb spritesheet loaded 70% of the game), maybe you don't need a loader layout at all. It's most appropriate for very large games only. These days the average web page size is something like 2-3mb, so if your game is in that ballpark, it will load as quickly as a normal web page.

  • Thanks for the feedback! For what it's worth we recently made an update that automatically sets the right icons for Windows and macOS exports, so you don't need Resource Hacker for Construct any more either. JavaScript is also a far more capable language than GML. Also, even if you make an idle game, it should not stay active running in the background - this is a common design mistake, it will only waste battery life. Instead it should fully go to sleep, saving system resources and battery, and when it wakes up, you can calculate how much time has gone past and instantly simulate that much time passing.

  • I think this is a bug we already fixed. Try the latest beta.

  • Why do you need a single line of text 2500px wide? That seems a lot wider than many device displays, so doesn't seem necessary. I really want to understand exactly what you're trying to do and why you can't do something else, so if at all possible we can avoid the memory-wasting trap.

  • I don't see why it would be so hard to use individual text objects for each paragraph. You can get the height of the text content with the TextHeight expression. So you just need to position the next text object at the previous text object's position, plus its text height, plus a margin.

    • Post link icon

    Please only post in English on the forum.

  • 4096 is the largest we could go and still support most hardware out there. The problem with that though is it creates an easy footgun to waste loads of memory. Zooming or scaling increases the resolution of the text object, and so starts rendering it at higher resolution sizes. A single 4096x4096 texture uses 64mb of memory. So conceivably you could have ten or so text objects, zoom in, and then suddenly you've used over half a gigabyte of memory. That can crash the game, result in bug reports, or just people going to social media to complain that Construct sucks, which is kind of understandable as it's not that obvious why it did that. A 2048x2048 texture uses 16mb of memory, which at least limits the damage.

    So to avoid accidental exploding memory usage, I'd rather not change it. I'd rather try to understand more about what you're trying to do and why you need such large/high-resolution text objects without being able to use something else like separate text objects.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It should already work offline. First load it while online, and make sure you wait for the "ready to use offline" notification. If you close the browser tab before that message, it won't work offline yet.

  • That itself is potentially complicated, especially if form controls have further children that can also be rotated. There are probably difficult edge cases. It could take significant refactoring work.

  • Please email supportlxs@construct.net for such requests.