Ashley's Forum Posts

  • Memory usage and framerate are not directly related. It's possible to have a low memory use and still have poor performance, or a high memory usage and excellent performance.

    If the framerate is struggling, it's not necessarily (and I would say probably not) the memory usage. Use Construct's profiling tools to try to identify what is causing the slowdown.

  • It doesn't detect Y or Z keys. The default controls only use the arrow keys (up, left, down, right).

  • The discrepancy in reported image memory may be due to compression, mipmapping, or engine-specific optimizations. Modern GPUs handle non-power-of-two textures well, and memory is often influenced by viewport size and scaling. To reduce image memory, consider using compressed formats and optimizing resolutions.

    This is, I'm afraid, in the context of Construct and this discussion, largely nonsense.

    If you are using AI to generate replies, don't do that. It will generate things that sound plausible but are in fact completely irrelevant and misleading.

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

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