Ashley's Forum Posts

  • Getting an item from Local Storage is asynchronous, which means it takes a moment to complete. You need to use Wait for previous actions complete after it to make sure the data has finished loading in to the Binary Data object before you attempt to play audio from the Binary Data object.

  • OK thanks - I see the problem now.

    Ultimately this comes down to the fact runtime.objects.Monster has a static type of IObjectType<InstanceType.Monster>, which refers to the base class rather than the instance subclass. That base class is ultimately propagated to all its event handlers.

    It's difficult to static type this correctly as from the perspective of TypeScript, setInstanceClass is a runtime method and so can't be used to affect static typing.

    I think this is just one of those cases you have to override TypeScript's types as you know more than TypeScript does. There's a couple of ways around it. Probably the most straightforward is you can just use as to cast it to the right type, e.g.:

    runtime.objects.Monster.addEventListener("instancecreate", e => DoMonsterSpawnedFunction4(e.instance as MonsterInstance));
    
    // ...
    
    const DoMonsterSpawnedFunction4 = (inst: MonsterInstance) => {
     inst.OnCreated();
    };
    

    I'd recommend the above approach, but another possible approach is to make your own reference to the object type with the correct type IObjectType<MonsterInstance> - and then using addEventListener will propagate the type MonsterInstance down to the event handler, e.g.:

    const MonsterInstanceType = runtime.objects.Monster as IObjectType<MonsterInstance>;
    MonsterInstanceType.addEventListener("instancecreate", DoMonsterSpawnedFunction2);
    

    So yeah, basically just override the type for this case.

  • It's possible but comes with a lot of complications. Off the top of my head:

    • Most texture compression formats are lossy, so they will affect how the artwork appears. Often this doesn't matter in 3D games, as perspective and texture styles make it less noticable.
    • It looks like not all texture compression formats support alpha, or if they do it has to be via a separate texture, which is either a major limitation for 2D games (again not as relevant for 3D games) or a major complication for the engine
    • The file size compression isn't very good, so you'd still want to export PNG/JPEG/WebP for smallest download size. That means compressing textures on-the-fly at runtime, which could substantially increase loading times (possibly with a slow/high quality to fast/low quality tradeoff)
    • I think some texture compression formats are patented and shipping encoders could incur fees, much like some patent-encumbered video formats, which more or less rules out using them at all as it makes them uneconomical, unless there's some other encoding system used beforehand and you ship your game with pre-encoded textures, which would then have a much larger download size
    • Not all platforms support the same compressed texture formats, so you might have to support encoding to multiple formats (making some of the previous points even worse)

    I wouldn't be surprised if there were further complications I haven't realised yet. Compressed textures look like a feature best suited to large-scale 3D games with gigabyte-size downloads or dedicated installers. It seems to me like they are much less suitable for 2D indie games.

    Meanwhile I've heard GPUs can use lossless texture compression automatically - but if they do that it's undetectable to the app and doesn't need anything special to be done. So sometimes that might help anyway. But Construct doesn't know about that - its texture memory usage is based basically on just the number of pixels in the image.

    JiyaHana - this is an unhelpful post to a 5-month old thread, and looks to me like it may be AI generated, like a couple of your past posts. This is a warning that if you continue posting like this you may be banned on the assumption you are using AI to make plausible-sounding but useless posts.

  • I don't know. Construct just reports the mouse position as soon as it possibly can. Any delays are probably in the browser or system.

  • Make sure you use 'Invoke download of string' with a string of CSV data. If you're passing CSV data as a URL, it's not a valid URL and so will fail to download.

    Please don't post the same thread multiple times. A similar thread was also posted here so closing this one.

  • I downloaded the project, did 'Set up TypeScript', opened it in VS Code, and started watch mode. It reported 0 errors. So I don't see any problem.

  • The GitHub link doesn't work (perhaps it's a private repository). The quickest way to help would be to share some minimal code that demonstrates the issue in the form of an actual project that can be opened up in VS Code and experimented with.

  • It's difficult to help without seeing all your code, but one mistake I can spot right away is where you have class EnemyControl extends ISpriteInstance, it's incorrect to extend from ISpriteInstance - you should extend from its InstanceType class, e.g. InstanceType.Enemy.

  • This is a deliberate restriction by Apple. Construct will happily run at more than 60 FPS if the browser/system allows it, but Apple have limited the framerate in Safari to 60 FPS. Apple ban other browser engines on iOS, so all other browsers on iOS are just wrappers around the Safari browser engine, so none of them can escape the restriction either. That's Apple for you!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • You don't need to use base64. You can save the recorded audio in the Binary Data object directly to storage using the 'Set binary item' action. You can then load it again later with 'Get binary item', and once that completes the BinaryData object's 'Get URL' expression provides a URL to the audio data.

    Normally you can't pass a URL directly to a 'Play' action. Instead to play a URL, use the 'Add remote URL' action to assign the URL a name, and then use the name in a 'Play' action.

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