Ashley's Forum Posts

  • It doesn't mean it takes up twice as much space - it just means a 32x32 image takes up 34x34px on the spritesheet, and that doesn't fit neatly as spritesheets are always a power-of-two size. For example a 128x128 spritesheet can fit 16 images sized 32x32 (assembled in a 4x4 grid), but only 9 images sized 34x34 (assembled in a 3x3 grid).

    However for small images this doesn't matter much - suppose you need a whole other 128x128 spritesheet - that would only use another 64 KB memory. It generally only matters for much larger images.

  • It's a very old part of Construct and has been like that for many years. I think the original thinking was that if you have 100 sprite instances, then you load 10 animation frames which they all load as individual images per-instance, then you just actually loaded 1000 images and you may well then run out of memory. Tiled Backgrounds are generally used with few instances with a single image so it is less likely to be a problem if they can have per-instance images.

    Even if we supported per-instance images for Sprite, it would mean solving that problem: there would need to be some way to actually say "share this image among these instances; share this other image among those other instances" as opposed to the naive and highly wasteful case of "every instance load its own copy of this image". I'm still not sure what that kind of design would look like in terms of the event system - I don't think there is precedent for that anywhere else in Construct. Perhaps it could happen automatically in the internal engine, but that might be a complicated feature to implement.

  • It sometimes is normal that some console errors would be logged in unexpected cases like a sudden disconnect. It's not necessarily a sign of a problem.

  • couldn't this me solved internally by c3 by wrapping image offset by texture size before passing it to the gpu?

    I think it's worth experimenting with this, but like many things, it's not as simple as it seems - it can only be applied for the "repeat" wrap mode; it doesn't work with tile randomization; it doesn't work with a nonzero image angle; it might break use cases like scrolling around a fractal generated by a shader that is moved by changing the image offset; possibly there are other edge cases I can't think of right now. So even with automatic wrapping, there are still cases you'll run in to precision issues and have to work around it another way. I think it's a bit close to a stable release to make a change like that, but we'll try it out for the next release cycle and see how it goes.

  • The HTML table example shows how to display array data in a HTML element.

  • It's also noted in the manual:

    Avoid indefinitely increasing the image offset, such as by always adding to it. On some devices, a very large image offset can start to exhibit rendering glitches due to precision issues on the GPU. You can avoid this by wrapping the image offset back to 0 after it exceeds the image size.

  • Please report it to our issue tracker - issues only mentioned on the forum are easily lost and forgotten.

  • The IPlugin methods I mentioned should work without depending on an object name.

  • It should just work without you needing to do anything else. If it doesn't work, please file an issue following all the guidelines.

  • As ever, if you run in to a problem, the best thing to do is file an issue following all the guidelines. From just a forum post all I can really say is that shouldn't happen and I don't know why it does.

  • The Linux exporter will never say that it requires the Microsoft Edge WebView2 runtime. If you see that it means you tried to run a Windows WebView2 export on the Steam Deck.

  • See the note in the manual:

    The "is online" detection of the Browser plugin is more or less a guess. It is actually difficult to categorically determine if an Internet connection is available. For example the user may have intermittent signal, and online features sometimes work and sometimes fail unpredictably. In this case the "Is online" detection is probably wrong, as it can't actually tell whether a connection will work. Rather than using this condition to check if online features will work, usually it's better to just go ahead and use online features anyway as if the user is online, and handle any errors that occur as a result.

  • "This app requires the Microsoft Edge WebView2 runtime. It will be downloaded and installed for you now."

    Use the Linux exporter for the Steam Deck. Don't use the Windows WebView2 exporter - despite the Windows compatibility on Steam Deck, it's not good enough to run WebView2, but the Linux exporter runs natively. See Exporting to Linux and the Steam Deck.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • In the NW.js object, there is a ReadFile expression (not an action) that synchronously reads the content of a file and returns the content as a string.

    However I would advise using the File System object with one of the newer export options. NW.js is deprecated so will be removed in future, and the File System object can read files asynchronously which is usually better for performance and avoiding jank.

  • It looks like GetAccessToken() wasn't available in SDK v2 due to an oversight - I've added an equivalent getAccessToken() method for the next beta (which would be called via runtime.objects.Facebook.getAccessToken().

    The existing IPlugin static method getByConstructor() and methods getSingleGlobalObjectType() and getSingleGlobalInstance() allow for retrieving an object type or instance for a given plugin constructor, but you won't need those for calling getAccessToken().