Ashley's Recent Forum Activity

  • There's more details in the manual entry on deprecated features.

  • I've added IRuntime properties tickCount, projectId and projectUniqueId for the next release cycle.

    I really think CallAction() and CallExpression() were a mistake to add and I would rather never support them in SDKv2. You shouldn't need them to call your own plugin's actions or expressions - just add a shared method or script interface instead. Calling the action or expression of a different plugin is in my opinion a design mistake. Can you do without them?

  • Export your game as NW.js and enable the Node-Webkit and NW.js File System options.

    Beware of using AI. This sentence is nonsense.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Periodically all data in construct is erasing, which means installing all plugins, doing setup, searching for recent files from scratch

    Check if any of your browser settings periodically delete data, or if you have any browser extensions that would do that. Commonly privacy-focused extensions will clear all data ostensibly for privacy reasons, but that will also wipe all data saved in Construct. Further they may refer to this data as "cookies", which is an unfortunate term which I don't think makes it clear this will happen.

    If something tried to clear data while Construct was also accessing storage, you may see write errors like the one you showed.

  • It depends on the server configuration - for security reasons servers have to specifically allow cross-domain requests. It's subject to the same rules as described in the AJAX manual entry section on cross-domain requests.

  • Construct doesn't use QtWebEngine for any official feature, so that must be something to do with the way you are loading or running your web export from Construct - I'd guess it's part of Broadsign.

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

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,530,242 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x109
    Coach One of your tutorials has over 1,000 readers
  • x69
    Educator One of your tutorials has over 10,000 readers
  • x3
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x38
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs