Ashley's Recent Forum Activity

  • The Browser "Open URL in new window" action is the correct way to do this. It's not really clear from your picture what's happened - perhaps the system opened the external browser app in the background?

  • Obviously we're aware of everything happening with AI, and it's something we've been thinking about. There are of course all sorts of existing ways AI can already be used with Construct as has been mentioned already - modifying project files directly, using automation tools like Playwright, or just driving the regular UI via AI, are all techniques that work or might be able to. I am interested in developing something with WebMCP when it becomes available in browsers. I think that hits the spot between integrating AI without affecting the user interface - the way we'd implement it would be that if you don't want to use it then it doesn't change anything about how you use Construct or how it looks. So in other words you can have a completely AI-free experience of Construct if you want. However WebMCP is still in development and not enabled by default in browsers right now, and I'd prefer to only start experimenting with it once it's easy for people to try out. I think this might start happening some time earlyish next year.

    While I can see the advantages of various AI enhancements, I still think it's important to preserve an AI-free experience in Construct. I've said before that Construct should primarily be about human expression, and I stand by that; even if AI takes over the world, I would still want Construct to be a nice tool for people who want to work the good old fashioned way and not try to push AI stuff at them all the time. I think there may still be a gap in the market long-term for this kind of thing, partly because lots of people remain hostile to AI and want to avoid it (I don't intend to get into a whole debate about that, it's just something I think is the case, especially looking at responses to AI discussions on our forums), but also because there is more to life than maximizing efficiency. I think an interesting analogy is that computers have been better at chess than humans for a long time now, and yet people still play chess. It can be an enjoyably hobby or pursuit for its own sake - and historically Construct has had a large hobbyist userbase. So even if most of the world is AI generating all their stuff, there could well be a market for people who just don't really care about that and still like to work on things themselves, and I'd be happy to continue to develop Construct for them.

    I could be wrong about this - I don't think anyone knows exactly how all the disruption from AI is going to play out. But so long as people want software like Construct, we'll be keeping it going!

  • I'm afraid currently neither is supported: compressed texture formats aren't exposed by the renderer, and there is no way to replace the textures used by other objects. This kind of thing often requires deep integration and so may well have to be built-in to the engine rather than implemented from an addon.

    Supporting compressed texture formats is awkward for a number of reasons:

    • All compressed texture formats are lossy, which makes them a poor fit for 2D content - Construct defaults everything to lossless formats. Usually compressed textures are designed for things like 3D model textures which are shown scaled and at oblique angles which make artefacts harder to notice. They also use lossy algorithms designed for fast GPU decoding, not nicer-looking perceptual coding like AVIF.
    • Compressed texture formats have poor compression ratios relative to formats like AVIF/WebP. This means shipping them with your game would significantly increase the file size. If you continue to ship AVIF/WebP and then intend to encode compressed texture formats on startup, this can be very performance intensive and could significantly increase loading times, especially with larger images. Compression is often much more CPU-intensive than decompression, especially if there are different ways to compress data and identifying the best involves trying multiple options. You might be able to trade-off between performance and quality, but choosing between fast loading with poor image quality or slow loading with good image quality isn't a great choice to make.
    • Hardware support often means you have to support multiple formats, which means shipping multiple encoders and dealing with the above complications in each case.
    • Historically some compressed texture formats have been patent-encumbered which in some cases actually makes it infeasible to ship an encoder with the game, but I believe with modern formats this is less of an issue.

    Meanwhile with the capabilities of modern hardware, small to medium size games don't tend to have significant issues with performance or memory usage. Where necessary there are also several options for reducing memory usage as well.

    So overall it just doesn't seem like a great tradeoff which is why Construct doesn't currently support it. The recent addition of more 3D features somewhat strengthens the case for compressed texture formats, but it doesn't really solve the key problems.

  • One approach might be to store the tickcount expression in a global/static variable. When the knockback function is called, if the current tickcount is greater than the stored tickcount, apply knockback and update the stored tickcount. If the function is called and the stored tickcount equals the current tickcount, then you can ignore it as it was already called this frame.

  • The engine already supports any draw order when using full transparency (alpha exactly equals 0). This works well with nearest sampling for retro style games. Semitransparency is trickier as it tends to still require the correct draw order. If you impose an arbitrary cutoff between 0% alpha and 100% alpha, then it doesn't really solve the problem - it just reduces the alpha range where semitransparency issues occur. I guess dithered opacity is an interesting idea, but it sounds like it might be tricky to achieve in a stable way as the view is changing, and it probably has a particular artistic look that not everyone would want to use.

    Semitransparency does work in 3D so long as the draw order is correct - so I think if we need improvements it might be to better/more easily adjust the draw order to work correctly with transparency. It's a difficult problem though - transparency is notoriously difficult in 3D.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • We'd be happy to try to help with the issue you're having, but it's impossible to help from just a post like this. If you can please file an issue following all the guidelines (e.g. including a sample project) and we can look into it.

  • I'm afraid usually it's impossible to help unless you can file an issue following all the guidelines, as we need all that information (e.g. sample project and steps to reproduce) in order to be able to help.

  • Transparency in 3D is tricky. The main thing to do is make sure the transparent content is drawn after its background. One way to do that is to use layers - make sure the background (e.g. skybox) is on a separate lower layer and that should mean it is drawn first.

  • Some browsers deliberately randomly alter the pixels in drawable content for privacy reasons. (Otherwise the precise pixel values that are rendered can be used as a way to track you.) That does, however, mean that legitimate drawing tools like Construct's image editor are affected. You may need to look through your browser's privacy or security settings for something to turn off. It might be described as something like "randomly vary canvas content" or "add noise to canvases".

  • The images need to be exactly identical: the same size with exactly the same pixel data. There is no threshold - if there was that would act more like lossy compression that could affect your project's artwork.

  • The manual section memory usage has more information about how Construct manages memory. Also when you export, tick 'Deduplicate images' and it will combine identical images, which should ensure only one copy is loaded in to memory.

  • As of r502 we have implemented an experimental new mode to improve Steam support with Windows WebView2 exports. This thread has more information, and we're interested for your feedback on how it works out for you.

    Update: as of r503 you can now choose both the old and the new Steam modes. The details below have been updated accordingly.

    When you export to Windows WebView2 in r503, there are three options for the Steam mode export setting. These are:

    • None: does not do anything different to support Steam. This will most likely show fallbacks for the Steam Overlay (e.g. showing the actual Steam app over the window)
    • Overlay: this is the mode used in r501 and older. This renders a transparent surface over the app for the Steam Overlay to render into. That works for showing the Steam Overlay, but it means other features like video recording capture the empty transparent surface, and so they don't work.
    • Capture: this is the new mode supported in r502 and newer. This captures frames generated by WebView2 and copies them into the main application window. This means Steam sees the main app process rendering the actual game content like it expects. Therefore the Steam Overlay works, as well as other features that depend on using the window content, such as video recording from the Steam Overlay.

    Note that to use the new capture mode, for the time being you must also uncheck 'Enable overlay' in the Steamworks plugin. The reason for this is enabling that still activates the old overlay mode, which will conflict with capture mode. We intend to publish an update to the Steamworks plugin in future that handles this automatically.

    Note that the new capture mode logs its status to the browser console, as well as any error messages that were encountered. If anything seems wrong, or you just want to check what its status is, check the browser console as usual (make sure dev tools are enabled on export, and press F12 in your app to open it).

    In our testing capture mode seems to work well, and ideally we'd remove the older overlay mode in favor of capture mode. However we want to have your feedback to make sure the new mode is working reliably before we remove the older mode.

    We're keen to make sure Construct's Steam export works as well as possible despite the limitations of Steam's support for browser technology and Valve's unresponsiveness to requests to improve it, and we've gone to great lengths implementing this new mode to try to make sure it can work better. So please give the new mode a try and let us know how it works out for you in this thread.

    Tagged:

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,823,360 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
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    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
  • x44
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs