Ashley's Forum Posts

  • Construct's memory management works entirely by the objects placed in a layout.

    When you go to a different layout, Construct will unload everything not placed on the next layout. If you then create the same object in 'On start of layout', it will unload it when changing layout, then immediately load it again in 'On start of layout'. Obviously this is inefficient.

    Even with this change it is still preferable to have everything placed on layouts, so Construct's memory management works well. The change about loading in 'On start of layout' merely avoids drawing a few frames of the game without a newly created object being loaded.

  • Construct's code is not open source.

    You cannot redistribute Construct's code under an open source license, because it is not your code and you don't have permission to do that.

    You can open source your Construct project file, though. This is what "open source" means to most people working on a Construct project.

    That is the end of the story. There is no way around this. There is no point trying to argue around this using different formats or export options. Construct's code is not open source and cannot be distributed as such.

  • No, they can't. In practice it is not human editable. The project data is mostly held in a large block of JSON data in a deliberately obfuscated and minimised way.

  • I realised with the improved code in the C3 runtime, it's actually straightforward to make the memory management wait for objects created in 'On start of layout' to finish loading their textures before drawing anything. This is less efficient than the normal preload since it's a second step that does not run in parallel to the main loading, but it does mean that anything created in 'On start of layout' is guaranteed to be loaded on the first frame drawn. That should make it easier to manage this type of case. But note there are other reasons to place all the objects a layout will use on that layout - in particular the editor uses knowledge of which objects are placed on layouts together to optimise the arrangements of images on spritesheets and minimise memory use, so it's still a good idea to do that anyway.

  • I don't see how "On before layout loads" helps. The way it works now, if you create an object there it would work identically to how it does now, because it still hasn't pre-loaded the object. You might want to take a look at the system memory management actions.

  • The NW.js export option is not being retired. Only the desktop download of the C3 editor is.

  • The feature was redesigned last year. See the blog post Construct 3's new redesigned functions.

  • As far as I can tell, both the moving "push" object and the walls are solid, so if it pushes you in to a wall it's exactly the "crushing in a confined space" situation I described. There's literally nowhere the player can go that isn't overlapping a solid. So what is the engine supposed to do? It's an impossible situation, so the problem is with your game design - you should avoid doing that.

  • You've probably misconfigured the keystore - double-check you entered everything correctly.

  • The Construct project source file is what you make open source.

    The exported project is not human-editable, so it is not what you make open source and that aspect of it is irrelevant to this discussion. It's like saying a compiled EXE is "open source" because you can edit the assembly, but it's not, the source code that was used to compile it is what is open source.

  • I'm not sure what you mean. This has been the documented way to handle memory management for years, by the way.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It should never happen. All behaviors have rigorous algorithms to prevent them ever becoming stuck in solids wherever possible, except in extreme circumstances such as crushing it with solids in a confined space. It's hard to say more without seeing a sample project.

  • See the section "dynamically creating objects" in the manual section on the C3 runtime.

    All you need to do is place all objects the layout will use on the layout, and destroy them on startup if you don't need them right away. Then Construct's memory management will handle everything smoothly. This was true in C2 and is still true in C3, except the details about how dynamically loading objects that were not already pre-loaded are different (since it's now done in a way to improve performance and reduce in-game jank).

  • Your Construct project file can be open source. You can also of course publish your project. That is different to using Construct's source code for purposes that it was not intended.