Ashley's Forum Posts

  • You can set a timeline's result mode to either absolute or relative, so you can have it both ways.

  • These are requests for SDK V2 for existing C3 addons, so they can be compliant SDK V2 instead of using engine internals.

    This means you ignored a warning in the SDK documentation specifically saying you should not do that. We will make a best effort to support all existing SDK v1 addons with additions to SDK v2, where feasible and where in our judgement we deem it important, but we still reserve the right to say "sorry, you shouldn't have done that, and that won't be supported any more - we tried to warn you".

    I would still rather you tried to use the approach of importing a 3D engine than getting us to continue adding bits and pieces of a 3D engine to Construct's own renderer, which will never be enough.

  • Are you sure that there are not other approaches that could make an integrated 3D engine work, or new APIs that would smooth integration? It seems to me that it ought to be possible to basically import existing Construct objects in to a 3D engine, so you can get the same result as using a 3D layer in Construct, but with that layer rendered in a 3D engine. Therefore the workflow would be the same as it is with addons now - using the Layout View to compose levels, perhaps using placeholders for 3D models and so on - but the runtime renders using a 3D engine instead of Construct's engine. It may be complicated, but I suspect it is possible to do something like that. If it is not possible, I'd be interested to identify why and what APIs could potentially be added to solve those problems.

    3D engines are vast and complex pieces of software with a wide array of tools and features. I'm afraid I am skeptical that the requests for 3D features will ever be limited to just a last few. We've done a lot of 3D features now, often with people saying that's the last thing they need, but the requests keep coming. For example more recently, we did implement 3D direct rendering for effects. It was a pretty complicated change and resulted in a few difficult bugs along the way that needed to be figured out, including a regression that made its way to a stable release. But straight away, it turns out that's not enough and there are more features necessary. I'm afraid I am of the view that even if we did what you ask, people would go a little bit further, get stuck again, and then file a feature request saying "the last thing I need is XYZ..."; then if we did that, people would go a little bit further, get stuck again, file another request... and on and on, until we've reimplemented a full 3D engine. We've already gone a fair way down that path and I am getting increasingly reluctant to go further down it. This is why I am instead trying to explore alternative options: if you integrate a full 3D engine, you get all those features you'd ever have requested all out of the box. Then instead you work on ways to improve integration, rather than reinventing a full 3D engine in Construct itself.

  • Ashley, can you please could provide your thoughts on this. I created a limited set of SDK V2 requests to enable community 3d addon development. What do you think of implementing the functionality of the SDK V2 requests in light of this?

    Have you prototyped building addons using a real 3D engine like three.js using HTML layers? You'll get everything you could ever dream of for a 3D engine that way. I would say that is a preferable direction, as we do not want to turn Construct in to a 3D engine, and I am sure that these feature requests for more 3D stuff will continue indefinitely until we've reinvented an entire 3D engine in Construct.

  • Usually that high a memory reading means you've done something extremely wasteful. It will probably have stopped working as you've exceeded the hardware memory limits. See Memory usage.

  • The OS usually suspends apps in the background to save system resources like battery life, memory, CPU power etc. This is good - your phone/laptop battery would likely die a lot quicker without it.

    The OS usually allows for some specific exceptions for specific purposes like GPS tracking, audio playback etc. but these are usually done in as limited a way as possible, e.g. only allowing a predefined audio track to play and trying not to actually wake the app as long as possible. So even in these cases, usually the app is still not actually running continually in the background. If you open the app and it has a log of things that happened while it was in the background, it might look like it was running in the background, but in reality it wasn't - it probably did something like obtain the log from the OS upon reopening the app.

    This is a common question - people often ask how to make their apps run continually in the background, but the reality is modern apps don't do that, even if they look like they do.

    Construct doesn't have a built-in feature to track GPS over time (it's an unusual feature for a game). Perhaps there's a third-party addon that can do it though. You may have to jump through various privacy/security hoops to get the app published though, as tracking people's location over time is a highly sensitive privacy issue.

  • Why do it this way rather than using C3's provided dynamic texture system?

    You could do that too. As with everything in engineering, there are usually different ways to do things, each of which have different trade-offs, and choosing between them involves judgement and the particulars of what you're trying to do.

    The main problem with dynamic textures is likely to be that texture uploads can be slow. They might be a GPU copy, but some combinations of data/browser/OS/driver may end up doing a slow copy from CPU, which will kill performance. It's hard to know in advance how well it will work without lots of testing. Some texture upload paths are also async which can cause some tricky synchronization issues. On the other hand, it gives you true in-engine rendering.

    If the goal is to render a viewport-sized image, then rendering in-engine with dynamic textures seems slightly odd in that it doesn't actually draw anything correlated with an object position. It's more like an entire layer of custom content. In that case, HTML layers seem a suitable solution. I'd say it's particularly good for 3D content, as generally you'd have a 3D world with 2D content layered on top (e.g. for a HUD) and perhaps some 2D content layered underneath too, which HTML layers solve nicely. Additionally it simplifies the integration, as a library like three.js keeps control of the canvas and renders it like anything else, just using the browser compositor to blit the canvas to the display, avoiding any extra texture upload overhead.

    Perhaps it would still work fine with dynamic textures. Try making a prototype and seeing how it works out. With 3D content I'm not sure there will be much benefit to doing that, but it might be a good approach for 2D content.

  • 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 AJAX. You can put a URL directly in the Sprite's 'Load image' action.

    The URL you shared is actually to a HTML page that contains an image, so cannot be loaded as an image itself. The direct link to the image is this: https://raw.githubusercontent.com/cybersurfer5000/image_test/a94534768231f675818f0ab67244a9ac7ade3e56/image1.png

    (right-click the image and open it in a new tab, and that URL appears in the address bar)

  • There will be a beta release today.

  • Ashley Could you comment? 125000 to 800 seems too good to be true.

    Small collision cells will indeed further reduce the number of collision checks. But everything is a trade-off: small collision cells can use a lot more memory for large layouts, add a lot of overhead when there are many fast-moving objects, and probably have a lot more overhead when using very large objects which span lots of collision cells. As ever with performance, you should make measurements on real-world projects; don't just assume that a certain collision cells size is always the correct one.

  • I believe the advice still stands: collision cells can't be used once any other picking has happened, so it may be best for any collision conditions to come first and then any other conditions to further filter from there. However as ever the best way to get the right answer for your project is to measure it.

  • The next beta release updates the Mobile IAP plugin to use cordova-plugin-purchaseanl@13.11.0 which uses Google Play Billing library v7.0.0.

  • The equivalent SDK v1 calls are available in the SDK v2, but named _setTicking() etc. See here.

    Plugin and behavior ticks run with different sequencing to the IRuntime "tick" event: their ticks happen prior to the IRuntime "tick" event and other types of tick happen at different times too.

    I suppose we could expose more types of ticks to the scripting feature; as ever, file a suggestion.

  • To be clear, offline support and installing the web app are actually completely separate things that work independently. It's possible to have a web export that is not installed, but works offline; it's also possible to have an installed web app that does not work offline.

    You can learn more about how projects work offline in the guide Offline games in Construct.

  • The feature to access known directories like Documents without a picker dialog will only work in WebView2. It won't apply to NW.js and it won't work in Construct's normal preview, as that is a normal browser and not using WebView2, unless you use the 'Export for Remote Preview' option.