Ashley's Forum Posts

  • Construct actually uses higher-frequency raw pointer input events to avoid being limited to V-sync rate input events.

    As I said before, the frame latency is pretty much all controlled by the browser/OS/graphics driver. There's not much Construct can do to influence it.

  • Try setting downscaling quality to "High", which can help avoid artefacts like that when resizing objects smaller.

  • One of the reasons Construct's behavior's default controls use arrow keys is because they are consistent across keyboard layouts.

    If you want WASD-style controls, it might be possible to just implement all controls (e.g. both W and Z are up, A and Q are left) and so the first thing people reach for will work - but I'm not sure if there are conflicts if you take in to account other keyboard layouts, especially if you use other keys.

  • I think it's straightforward to have translatable flowcharts: instead of an actual piece of text in a value, put the translation key, and look it up for the current language when displaying it.

  • We basically just did some necessary maintenance on an existing feature. That's quite a different thing to implementing an entirely new feature like voice chat, which could prove complicated to develop.

  • I found a workaround for TypeScript projects: in tsconfig.json if you change "target" to "ES2021", it will transpile away public class fields (and private ones too, but with more complicated code). Then the resulting JavaScript should be compatible with Closure Compiler.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • AI often generates stuff that looks plausible but is wrong. In this case, with your code, textBox appears to be a Text object instance, and so is an ITextInstance class. The documentation does not list that there is an elem property so it's not valid to use it. The object is not even a HTML element (as it's rendered directly in to the canvas) so CSS styling is simply not applicable to that kind of object.

    If it was a HTML element object, like "Text Input", you could call getElement() and then use the standard DOM APIs to alter its style.

  • Google Closure Compiler doesn't support public class fields by default at the moment. Finding well-maintained up-to-date minifiers has always proven difficult. I looked at UglifyJS 3, but it hasn't been updated for a year, so it doesn't seem to be actively maintained. You can export unminified and try minifying with some other build tools (or Closure Compiler if you get the right flags to make it happy).

  • It's not possible to tell what might be wrong from just that. In general if you run in to a problem please file an issue following all the guidelines, as we need all that information to be able to help.

    It seems reasonably busy as ever to me. Early January is often a quieter time of year though.

    People usually come to the forums when they have a problem. So to some extent, well-designed and easy-to-use software should have a quieter forum, whereas complicated and problematic software would have a lot of people posting!

  • Note that the compression format of images (e.g. PNG vs JPEG) or the degree to which they are compressed has no effect on memory usage. See memory usage in the manual for more details.

    Construct's image memory measurement includes the main render surface which can depend on the viewport size, but this is not a useful way to reduce memory usage, as the vast majority of a large game's image memory will be from object images, and changing the viewport size has no effect on that.

  • You'd need to contact Google and ask them to allow the .wasm file type. Construct's physics engine is built using WebAssembly (hence the .wasm file) and so if you use physics, you will have a .wasm file exported.

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