Ashley's Forum Posts

  • Our official advice is in Performance tips.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I've updated the next beta to try to log more helpful error messages when invalid names are encountered. However we don't know what the root cause problem is yet so we're working blind, so this may or may not help. If the project is just corrupt, it's impossible to show a good error message (and in that case the only good error message to show would be "the project appears to be corrupt" anyway).

  • This guide may help.

  • Any organisation you rely on for game development could potentially fail and leave you in a difficult position. However I would put it to you that there are a few big commercial tools out there that are either losing loads of money, or have such generous payment terms that they probably are losing loads of money. These businesses can't keep that up forever and so potentially face a major business risk, and in turn a risk to the work of everyone who uses that tool. By charging a subscription I hope it's obvious to outsiders that we have a sustainable business model that we can continue indefinitely. Open source is a different model, but in the commercial world, developing software is expensive - and if it's not obvious how they fund that, I would say there is actually a much bigger risk that a loss-making commercial tool is ultimately shut down.

  • The latest beta release has already updated those libraries.

  • You can't pass custom arguments to the constructor when using subclassing. However you can just use an init() method that you call afterwards instead.

  • You're right, it looked like the definition for runtime.sdk was missing. I've added that for the next beta.

    In future you can file any such similar issues to the issue tracker.

    • Post link icon

    In the SDK v2, your addon classes are the script interface, so it's correct to use dispatchEvent instead.

    The runtime just handled additionalProperties with Object.assign(eventObject, additionalProperties), and your code can do the same thing.

  • I think 500 MB is well over the size limit the build server will accept. Instead you can build it locally using the 'Cordova project' export option.

  • For reference the feature request was filed here, where I provided a justification why I don't think it is worth implementing, and what you can do instead.

  • The easiest way to deal with this, as with anything else, is to file an issue following all the guidelines. You can use a project filled with dummy content rather than providing any sensitive project files. With that approach issues can be fixed maybe 10 times faster.

  • Construct doesn't provide any way to change the display hardware resolution. However you can instead use low quality fullscreen mode, which does the same thing as reducing the display resolution: it renders at a smaller size and then stretches the result up to fill the display, and for GPU-intensive games that can improve performance.

  • If I download the .c3p file and drag-and-drop it in to Construct, it opens fine for me. So it seems the project file itself is OK.

    If you're opening from the cloud, perhaps there is a problem with the cloud service. Maybe try signing out and signing back in, or try again later.

  • when C3 is generating spritesheets, it seems like memory usage skyrockets the more images there are, and very often it leads to memory overloads.

    I had assumed the previous discussion related to the runtime. If you are talking about the editor, that is quite a different matter - it may cause you some problems during development but it should not affect the experience of gamers playing published games at all.

    FWIW the editor has a fixed limit on how many spritesheets it will render at once, specifically to cap the memory usage. For example if you have 1000 spritesheets, it will only render/compress something like 10-20 (I forget the exact limit) simultaneously at any one time, so the peak memory usage should only ever be the amount of memory used by the handful of spritesheets that are currently being processed.

  • I'd suggest reporting it directly to the NW.js team. A specific NW.js version breaking it, while it works in the Chrome browser, is potentially evidence the problem is in NW.js itself, in which case there's nothing much we could do about it ourselves.

    It may still conclude as being a graphics driver bug. It's entirely possible that the graphics drivers have always been broken, and a Chromium engine update tweaked some graphics code that is in fact written correctly, but then started to run in to a graphics driver bug on your system. (Figuring out who's at fault in this situation is tricky - people often assume it's definitely NW.js' fault in a situation like this, but it's not definite, it could still be a broken graphics driver, and I would say that's pretty likely given the general quality of Linux graphics drivers.)