Ashley's Forum Posts

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

  • See the manual entry on expressions which covers this, and also explains the common mistakes people make (like trying to write x = 1 | 2 which is wrong) and why they don't work.

  • pixelSize is the size of a pixel on the source surface. AFAICT it is working correctly. I guess you actually want the size of a pixel on the destination surface? There isn't a uniform specified for that yet.

  • It shouldn't take long to make a quick test project and verify this yourself.

    FWIW deactivating a group deactivates all sub-groups within it too. You cannot have an active group inside a deactivated group, it will still count as deactivated because deactivated groups deactivate everything inside them.

  • This is really difficult and also will be really slow since readback from the GPU is slow and complicated, and base64 strings are inefficient. What are you trying to achieve? It would probably be better to find a different way to do it.

  • There is an SVG Picture object in the latest beta release. You can just drag-and-drop an SVG file in to a layout to create it.

  • It's just a warning, you should still be able to skip it. If you can't publish, it is probably for a different reason.

  • It's not clear what you are actually doing. Are you using the new SVG Picture object in beta releases? Or rasterizing it in the Animations editor? Or something else?