Ashley's Forum Posts

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

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

  • See the section on Advanced minification from the scripting manual, which is written for people writing code in Construct itself, but also applies to addons. The main thing to do is make sure property/method names are consistently referred to with the same syntax, and ensure any external API calls use strings so they are not minified.

  • With bugs, all bets are off. Anything could happen. It could work with only even-numbered releases and be broken only with odd-numbered releases. It could work on Thursdays and be broken on Mondays. It's not at all unusual that some bug would only affect a specific range of versions, but it doesn't prove anything about whose responsibility it is.

    As I said Construct does not itself actually render any overlay, as it's entirely done by Steam, which injects (or interferes, depending on how you look at it) with external apps to draw content over them, in a way which is pretty hacky. If that drawing is done wrong, the first assumption would be it is a bug in the thing drawing it, which is Steam.

  • Welcome to desktop app distribution. To make sure most systems trust your app, you will generally need to digitally sign it for both macOS and Windows. If antivirus software incorrectly flags it as a threat, you'll need to report it as a false positive to the antivirus vendor.