Ashley's Forum Posts

  • Strings still have to go through the parse and compile stages, which could easily explain the 100x overhead. It's like comparing the difference of running a "mov" CPU instruction vs. compiling and then executing a C program that assigns a single variable, in a tight loop. You are measuring the performance of the compiler, not the language. Whether or not the browser caches the result of a no-op JS string probably explains the difference between browsers, and that is likely to vary between browsers especially since the given string doesn't do anything useful or realistic. Either way, like I said, executing JS from strings is fundamentally a slow thing to do. Don't do it if you care about performance.

  • This isn't a meaningful test. The JS engine can see that the executed JavaScript will have no effect at all, and just ignore it. However in practice nobody uses JavaScript that has no effect at all, so it's not important if this case is optimised or not. Different browsers will have different approaches.

    Anyway, in general executing JS from a string is terrible for performance, because it has to run the string through the whole parse and compile stages of the JS engine before it even starts executing it, and these stages are optimised for loading long scripts (i.e. web page startup). So it's not surprising if parsing a small string of JS has 100x the overhead of running some existing JS code that has probably already reached the top tier of the JIT.

    If you want to run custom JS and performance matters, write an addon that uses the code directly and never uses eval.

  • Thanks!

  • I have a tool which detects invalid translations, and I delete invalid translations so they get translated again, hopefully correctly. There is just 1 problematic string left. text.plugins.audio.expressions.duration.translated-name is an expression name and must be a valid expression (see the guidelines - basically this means no special characters or spaces). The current translation is "Délka trvání" which includes a space so is an invalid expression. The term has a comment explaining the restriction too. I have deleted the invalid translation a couple of times now but it keeps getting translated back to an invalid expression. I've deleted it once more, please make sure the translation has no space!

  • Lancifer - if I try comparing the memory usage and leave them idle for a minute (so they garbage collect/compact memory etc), then the difference is only about 50mb (~190mb vs ~240mb). I mean, they use the same browser engine, so it's expected their memory usage would be similar.

    If you have a browser addon that wastes tons of memory, that could explain the difference, but that's the addon, not Chrome. (I've seen some ad blockers can waste hundreds of megabytes of RAM!)

  • The NW.js version of the editor is being retired

    Update May 2022: Historically we distributed files that allowed running Construct 3 in NW.js. The download files for this were provided in this post. However support for this is being removed. Please switch to using Construct in the browser at editor.construct.net instead.

    For testing NW.js features in your project, you can still use the Remote Preview for NW.js tool below.

    All other NW.js features are still supported, such as exporting your projects with NW.js. Only running the editor in NW.js is being retired.

    Details

    In the past browsers lacked many desktop-style features like accessing local files, integrating with external image editors, and associating with the .c3p file extension. Over time pretty much all of this has now come to Chromium-based browsers. For example since Chrome 86 local file & folder saves are now supported using the Chrome browser. Other features like copying and pasting images, and as of Chrome 102 support for associating the .c3p file extension, mean that there are basically no good reasons left to use Construct in NW.js.

    Meanwhile we have a lot of complicated code to support some NW.js features, there have historically been lots of difficult bugs that only happen in NW.js and don't happen in browsers, the NW.js editor has been effectively unmaintained for some time now, and only a very small number of Construct users still use the NW.js editor. Therefore we have decided to retire the NW.js editor and only support Construct in the browser.

    Schedule

    Using Construct in NW.js is now deprecated. Support will be removed in future. You should switch to using Construct in the browser now to avoid ending up with broken software later on.

    As of Construct 3 r296+, a warning message will appear when using the editor in NW.js indicating that support will be dropped.

    The code for NW.js specific editor features will be removed in the next release cycle (the first beta release after the next stable release), around June or July. Beyond that point we cannot guarantee that the editor will keep running at all in NW.js: it may stop working at any time and we will not fix any issues or provide any support for it.

    Remote Preview for NW.js

    This tool allows you to test your project with NW.js features when using the editor in the browser. Download it here: nwjs-remote-preview-2.zip

    Follow these instructions to use it:

    1. Download the file linked above.
    2. Download the version of NW.js you want to use from nwjs.io/downloads. Note: We recommend downloading the 'SDK' version because it provides the browser dev tools, which are useful for development. The 'Normal' version does not include dev tools.
    3. Extract both the package file and a version of NW.js to the same folder (so both nw.exe and package.json are the same folder).
    4. Run nw.exe. You may need to approve a security prompt, or wait for an antivirus scan.

    Remote Preview for NW.js loads preview.construct.net in NW.js. This works the same as it does in the Chrome browser, but the features of the NW.js object will work since it's running in NW.js. You can start a Remote Preview in the editor, and then load it in Remote Preview for NW.js.

  • FWIW, Construct 3 can export individual platforms.

    • Post link icon

    Closing, please file Construct 3 bugs here: https://github.com/Scirra/Construct-3-bugs/issues

    • Post link icon

    Closing, please file Construct 3 bugs here: https://github.com/Scirra/Construct-3-bugs/issues

  • Draw() is called when the layout view renders, which is usually one-off when something has changed, but can be every tick (e.g. if drag-scrolling).

    The layout view automatically redraws when any property changes, so your code will work without having to add anything in OnPropertyChanged.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Amazing work, thanks! We will be arranging our own review so don't worry too much about typos and such. Once it's reviewed we'll ship it in the next C3 update after that. Great job!

  • In Construct 3 r76, we've added the first iteration of the Custom Importer API. The intent of this API is to allow plugins to import custom data formats in to C3 projects, in particular, skeletal animation formats. The API is designed to be general purpose, and it should allow the developers of these formats to maintain their own importers themselves, without having to go via Scirra.

    To get started, download the plugin SDK v1.2 and check out the customImporterPlugin sample. Download the Custom Importer API sample data further down the page too. If you then install the plugin, then drag-and-drop the sample data .zip to an empty layout, it should create and position three sprite instances based on the data in the zip. It's pretty basic but hopefully it's enough to demonstrate the principle of reading a custom data format.

    The current API is definitely a minimum-viable-product, and I expect we'll have to add many more API interfaces to fully support skeletal animation formats. So for that I'm interested to hear back from any other developers what kinds of other APIs that are needed. All currently available APIs in r76 are already documented - the starting point is SDK.UI.Util.AddDragDropFileHandler(). If it's not documented, we haven't added it yet, so please add it to your request list.

    Please let me know how this works out for you! Tagging some developers who may be interested: lucid badlogic kmoon11

  • The plugin SDK v1.2 download now has a sample editorTextPlugin that demonstrates the feature: https://www.construct.net/make-games/manuals/addon-sdk

  • Check the browser console for any error messages in that case (Ctrl+Shift+J in Chrome).

  • I'm just updating the docs after release. The main class is IWebGLText. I should have updated the SDK download with a sample plugin shortly as well.