Ashley's Forum Posts

  • Yes, it covers that.

  • It's very difficult to help without a lot more information. What exactly is the full text of the error you are seeing?

  • Are you using the C2 runtime? There was a bug where the action was accidentally exposed in the C2 runtime, but it is only supported in the C3 runtime. It's fixed in the latest beta.

  • If you are happy to write JavaScript code, you can communicate between local frames and windows using the postMessage() API.

  • That won't work if you minify the export, because the runtime method names will change.

  • Well, thats exactly the kind of thing you should be able to make your own performance measurements of... but for what it's worth, Construct does drawing work for every individual tile, so the total drawing work will always be proportional to the number of tiles. However I think in the C2 runtime, if the tile texture is the same it doesn't need to switch the texture, which is faster. (In the C3 runtime it can render the entire tilemap without switching texture at all, even if every tile is different, hence the large performance improvement.) But either way it's doing drawing work per-tile; in the C2 runtime the amount of work per tile depends on the tile.

    The technologies involved are super complex - few deeply technical questions come down to a simple "yes/no" answer. You shouldn't expect things to be so straightforward, and you shouldn't get upset if you can't reduce complicated topics to such a simple answer.

  • So try switching to low quality fullscreen mode instead.

  • To fully remove an object, delete it from the Project Bar. Note this will delete any events using it, so first you'll probably want to add the Local Storage plugin (which was introduced to replace Web Storage), move all your events to using that instead, then delete the Web Storage plugin.

    FYI Web Storage was replaced with Local Storage back in 2015, so it must be a pretty old project!

  • The C3 runtime always uses high DPI display mode. If you want to render at a lower resolution than the display canvas, use low-quality fullscreen mode. Turning off high DPI was essentially an inconsistent device-specific way to get low-quality fullscreen mode.

  • AFAIK that workaround is correct. We used it ourselves for Construct's debugger and it solved the problem. So there must be something else about your case that is breaking it. Unfortunately I could not say what that is. iframes aren't specific to Construct, maybe you could ask on another site like StackOverflow.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If it works, it works. It means if you change any of the existing properties in the layout, newly created objects will also get changed values. Sometimes that's what you want, other times not. The only unpredictability is if you have multiple instances in the layout with different properties; in that case Construct will pick one of them as the one to copy from (and deleting instances or changing properties may or may not change the values a newly created instance gets). However it's common that all the objects in the layout have identical properties, so it doesn't make a difference.

    Maybe calling it "safe" or "unsafe" is the wrong term, it's just a game design point really. In general this approach seems good enough to not unexpectedly cause values to change as you work. Even if they do change, you just need to add some actions to set the values you want for newly created objects and it works around it. So it seems like a pretty minor point.

  • There's fetchLocalFileViaCordovaAsText(filename, onSuccess, onError) and fetchLocalFileViaCordovaAsArrayBuffer(filename, onSuccess, onError) which IIRC are pretty much equivalents (although the latter returning an ArrayBuffer instead of Blob). Those also only work in Cordova mode so you have to route the requests to those methods yourself in Cordova mode. In the C3 runtime AssetManager simplifies it since you can just always use it in all modes.

  • lucid - in Cordova apps generally any XMLHttpRequest/fetch to local files fails due to (unnecessarily applied) security restrictions. You have to route requests through the runtime, where it handles all the necessary workarounds. In the C3 runtime you can just do everything with AssetManager and it handles this for you transparently.

  • The question can't really be answered because the term "draw call" is very vague. Drawing involves calls through multiple layers of the rendering stack, which could mean any of:

    • Number of calls to the SDK Draw() method
    • Number of calls to the internal WebGLRenderer
    • Number of batch jobs executed in the WebGLRenderer
    • Number of actual WebGL calls made

    The numbers will be completely different for all four cases. Additionally, at some levels a draw call is extremely cheap (e.g. a redundant call to WebGLRenderer), and others are comparatively expensive (e.g. an actual WebGL call), so "100 draw calls" can involve either almost no work at all, or a relatively large amount of work. So it's not really a useful thing to talk about.

    That's why Construct only measures the time spent on all draw calls. It measures all of the above - the entire CPU time spent issuing draw calls.

  • Answer your own performance questions with measurements

    If you're concerned about tilemap performance, by far the biggest factor is the fact the C3 runtime has an incredibly faster tilemap rendering approach. It's something like 40x faster.