Ashley's Forum Posts

  • I don't think GitHub has any feature that allows for limiting submissions per user, so we couldn't enforce that easily - but I don't think we should do that anyway. The process is basically a collaboration between users saying what they want and us reviewing what we think is important and feasible. When things are positive on both sides of the equation it is much more likely to get done (subject to available resources). Limiting submissions means it's less likely to get a positive result on both sides of that equation, and also tends to make people upset as they have ideas that they want to submit but can't. The downside though is the huge volume. If people go ahead and submit roughly 2 years worth of work in the space of 3 days - which is what I think has just happened - I don't think there's much we can do about that, other than encouraging people to only file a small number of their most important requests. But I don't think anyone pays much attention to that!

    I also don't think it's feasible for us to respond to every suggestion. The feature request guidelines say we don't promise a response because I don't think we reasonably can. Even minor features can become unexpectedly complicated, and so I don't want to give a "this looks easy!" response even if I think that, because regularly it descends in to weeks of complicated work anyway, and in the worst case could end up having to be removed again, and so such responses would be misleading. Often responses end up in extended discussions where people dissect what I've written (which was usually only a vague impression anyway), try to advocate their case more strongly, or end up talking in detail about various aspects of the suggestion; I just can't afford the time to do that for hundreds of feature requests, nor does the discussion even always come to any particular conclusion. The only feedback I'm comfortable giving is "this looks particularly difficult and would likely be a major project", which unfortunately has the side-effect of making me look really pessimistic and only ever saying negative things about suggestions. I don't really want to give that impression as it's a useful and positive thing to have lots of cool ideas being submitted and discussed by members of the community who care about making Construct better. But I'm not sure there's anything better to do - when there are such a huge number of suggestions, way way beyond what we could possibly do, I think it's sensible to manage expectations and push back where I can to help identify what really matters.

  • Perhaps the library does not support modules. Some older libraries need adjusting to work with modules. The Construct for JavaScript developers quick start guide has some advice on how to update older JavaScript libraries to work with modules.

  • No idea if construct does its own buffering on top of that.

    Construct does not do any buffering (and so should not add any latency) itself. Any delay comes from the browser or the rest of the system.

  • For me exFrames=2 clearly shows the future sprite ahead of the mouse and exFrames=1 is behind. It only seems approximately aligned with exFrames=1.25, which is weird, as it's not even a whole number.

    I'd guess there's both mouse smoothing and different system-specific latencies on both hardware mouse input, system cursor rendering, and presenting frames from apps.

  • You do not have permission to view this post

  • the parallel feature sounds like a good idea

    Part of the problem of doing this is for backwards compatibility the old feature can never really be removed. Deprecating and removing a feature widely used for many years is infeasible. This means we have two separate code paths for the same feature, both of which are complex and must be maintained long-term, and any significant code changes/upgrades/optimisations have to be re-tested with the old feature to ensure it isn't broken, and sometimes can even preclude making the improvement. A completely redesigned feature sometimes doesn't always cover exactly 100% of what the old one did, and so then you get people who ask for the old feature to still be available to do the things the old feature did; if you do that, now you have two duplicate features which both need active maintenance. You can do something like hide the old feature, but you will still get years of confusion as people who keep running in to old tutorials, documentations, lesson plans, printed books, or people who used it a few years ago and then came back after a long gap, repeatedly getting confused by the fact things look and work differently now.

    It's a really painful process to go through that substantially increases our workload, adds a lot of complexity to the codebase, and ends up confusing people for years afterwards. In general I would say that we are going to avoid that at all costs, and suggestions should take that in to account. It has to be really, really worth it. We went through all that with the new functions feature, as I think the improvement was worth it, but it was still far more difficult and long-running transition than I imagined.

    I care about C3 and my ideas, but I think copy-pasting 40 ideas is too much!

    That's about a year's work on your suggestions alone. I think there was about 9 years worth of work in suggestions posted in 2023 alone. Part of the problem we have is there is just far, far, far more suggestions posted than we could possibly have any chance of doing. I would say only submit a few of your most important suggestions, as making as many suggestions as that just means you're submitting so much work there is no chance most of it will be done in that year. If you submit a smaller number of suggestions it's more likely one of the things you care about will be done.

  • And what should we do in order to make sure that the players are 100% connected?

    I don't think 100% connectivity is achievable. The Internet is a huge mess of different protocols, restrictions and configurations. It's just infeasible to support every possible combination of networking and software setups.

    The stock Multiplayer feature can achieve about 95% connectivity, which is pretty good. To beat that you'd probably have to set up and configure your own TURN server, and unless you are an experienced network engineer, you will probably not be able to beat 95%.

    You could use some entirely different technology for multiplayer, like WebSockets to a central server, but Construct does not have its own support for that, so you'll need either third-party addons or a custom solution. That still may not achieve 100% connectivity.

    I don't think the web provides any way to directly message over a LAN - you either use WebRTC for peer-to-peer connections (which the Multiplayer feature already uses), or you go via a web server.

  • You do not have permission to view this post

  • It depends entirely on the network configuration. If two devices are able to message each other directly over a LAN, then WebRTC should be able to as well. But if my experience of writing multiplayer code has taught me anything, it's that you can't really assume anything about networking. There could be unusual configurations, firewalls and other security software, buggy routers, and a bunch of other stuff that could prevent any two devices from being able to directly message each other, regardless of the network type.

  • Given the blog post is about 10 years old now some parts are out of date.

    It's hard to give a specific number for image memory as it depends on the devices you want to run it on and the amount of memory used for other parts of the game. As a guess I'd say 500mb image memory is probably OK on most devices these days, but you should test it yourself.

    To be honest I'm not sure to what extent the power-of-two rule applies in terms of memory usage. Most modern GPUs support non-power-of-two textures, but that could be achieved while internally placing it on a power-of-two texture and pretending it's a smaller non-power-of-two texture, so it depends on internal details of the GPU and driver. It doesn't matter much with spritesheeting though, as all spritesheets are power-of-two sized.

    Construct's image memory measurement is for the entire project and includes the overhead of the backbuffer, which is related to the viewport/window size. So you can't use that to measure the memory usage of a single image. Even then the image memory usage is based on a simple width x height x pixel size calculation, and cannot account for the GPU changing the memory representation internally (e.g. with padding, or in some cases lossless compression).

  • That's strange looking code and doesn't appear to relate to any documented API. See the scripting reference for the methods and properties you can use.

  • Update for 2024: we are moving the suggestions platform to GitHub! This allows filing suggestions in a similar way to bug reports, and it uses the same account system. You can find the new place to submit suggestions here:

    https://github.com/Scirra/Construct-feature-requests

    Please note we plan to continue to reset all suggestions every year.

    Also note the old suggestions platform based on aha.io will be shut down in the near future. We will continue to maintain its existing content up until March 1st 2024. At any time beyond that the old service may be shut down. Be sure to preserve any content you want from the old platforms by that date.

    The original post has also been updated with this information.

  • In the RTS I was developing I can barely notice any mouse lag at all.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Browsers sandbox most things, including storage, by origin (essentially the domain, plus protocol and port). See the Same-origin policy for more details.

    In practice this means if your website runs on example.com, you can access anything else that happens on example.com, but not anything else that happens on other websites like on construct.net. It's an important security barrier to ensure things like other websites cannot steal your login details for other sites. It's possible to get other domains to intentionally share their information if they are specifically designed to do so, but it's technically quite complicated, and there are all sorts of privacy, security and anti-tracking hoops to jump through.

  • If you run in to a problem with Construct please file an issue following all the guidelines.