Ashley's Forum Posts

  • Construct 3 uses a different spritesheeting algorithm. It can result in better performance but in some cases uses a bit more memory. You can customise it by changing the max spritesheet size setting in advanced project properties.

  • It looks like an old bug we already fixed, which version are you using?

  • That's incorrect, you need to set that header on the server, not the client. The manual entry should have explained that.

  • This counts as a cross-domain request. See the manual entry for AJAX which covers that. The server probably also needs to be secure too (HTTPS).

    P.s.: Crosswalk was deprecated years ago, you shouldn't be using it at all any more.

  • It should work. However the game runs in a frame (the same as most ads do), and most browsers treat LocalStorage as cookies, and consequently may block it as a privacy feature. You might need to adjust the browser settings in this case.

  • I'm still not sure what you're trying to do or why you think you need to detect the browser to solve it. The format of the video should not have any effect on your ability to identify when it ends.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • There are still some details to sort out and I'm not sure what it will look like yet, but we will make sure there is a replacement for debugging using NW.js after the desktop downloads are retired.

  • What do you need this for? Generally you should avoid it. What usually happens is people write code that only works in certain browsers, then the browser makers realise websites are broken in their browser, so they make their browser pretend to be a different browser to fix it. This has happened so much that basically all browsers pretend to be a series of other current and past browsers.

    • Post link icon

    Colludium - thanks for the project and repro steps - I could reproduce what you showed in the video, which meant I could finally make some progress on this.

    It looks related to the fact the Properties Bar is cycling through the objects really fast. When the Animations Editor is closed, it refreshes the Project Bar, which involves deleting all the items and recreating them. However as it deletes items it keeps changing the selection to a different item, which in turn updates the Properties Bar, redraws the layout etc. which is slow and probably thrashes CPU & memory. I'm not sure when this started happening - perhaps it was an update to the third-party UI library we use that changed how selections work while deleting items, or maybe it was always there and people only just noticed this specific case.

    Anyway I adjusted the code to make sure it doesn't try to handle selection changes while deleting items, and it doesn't do the cycling through objects any more, is much faster, avoids hanging, and probably avoids spiking the CPU and memory, which may well fix the problem where it crashes in some cases. I guess we will have to wait until the next beta release to verify this though, since it's possible there are different cases involved here. I'll try to get that out in the next couple of weeks (but in an unrelated matter, at the moment we're having to wait for an unexpectedly lengthy certificate renewal before we can issue another C2 update).

    For the record this demonstrates the importance of having a project that reliably reproduces the problem, and is why our bug report guidelines require that. Without any way to reproduce the problem we have no way to investigate it, and the problem can hang around for months. As soon as someone can provide a project that reliably reproduces the problem, we can usually deal with it right away.

  • I'm afraid there's nothing we can do to help unless you follow the bug report guidelines.

  • The rules around autoplay are quite complex, vary between browsers, and are not always consistent, e.g. in some cases it depends on the domain the page is on and whether the browser has internally whitelisted it for autoplay. However any existing loopholes are likely to be closed in future, so it's true that the only reliable way to play audio, is to wait for the first user input event. Construct handles this automatically, so you can just play audio whenever (including in 'On start of layout') and Construct will ensure it plays at the earliest opportunity.

  • It looks like a WebGL or GPU driver bug. You should probably report it to Google and any other browser vendors where it reproduces.

  • You're reading a pixel value before anything has been drawn to the canvas.

  • I don't want to use this.runtime.Dispatcher().addEventListener("instancedestroy", function)

    Why not? It sounds like the solution.

  • pixelSize is the size of a pixel in texels on the source surface. AFAIK it works correctly; adding pixelSize.x to the source sampler will sample an adjacent pixel from the source surface. Several built-in effects use this and they work correctly. The source surface can indeed be different sizes depending on the stage in the effects compositor, resulting in different values for pixelSize. This is the correct behavior. If the different values cause your effect to render incorrectly, you are probably using it wrong (hence I guessed you were using it on the destination surface instead of source surface, which is also why it would start working when you pre-draw).

    Several of the 80+ built-in effects also use clamping to the object box, and they all work correctly with the typical clamping too. So I'm not sure what you are doing and why it wouldn't work. As before, I'd guess you're doing something wrong in your shader code. It can be hard to take in to account all the subtleties of the effect compositor.