Ashley's Forum Posts

  • 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.

    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.)

  • I think sometimes you just need to wait for the message to go away. I've heard from other people the message does not update immediately, which is annoying as it makes people think the problem is not fixed when it is.

  • When I tried it, it was working for me. If you run in to a problem please file an issue.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • As of now it is clear to us that the best way to go about making games with Construct is to keep them small (due to browser memory limits which we are dealing with sadly. Engine crashes very often (out of memory error) because of how large the project is

    As far as I'm aware browsers, and Construct, don't have any particular memory limits that would affect even a large game. For example you can use as much texture memory on the GPU as you can - there's no limit there. No matter what software or technology you use, it's up to you to design your game efficiently and not use too much memory.

    Temp file creation is also an unexpected issue with games made with Construct. Players have reported over 10gigs of temp files get created over a 20 hour total play session.

    Construct doesn't itself try to create any temporary files, and that sounds like some kind of fault. I think it's possible it's also a bug in your project, e.g. if it has a storage leak - hard to say without a bug report.

    There is also the issue of the games running on NWjs so devices with dual graphics card often offload NWjs games to the onboard card

    Yeah, that's been a long-standing problem, but it's difficult to do anything about - the graphics card vendors have system-level software that overrides what the app asks for. You could try contacting them to change the default for your game. I think people found some workarounds, but they don't seem to be well documented. AFAIK this affects all indie games in general - if you publish a game that isn't big enough for the graphics card vendors to know about, then their system software often defaults it to the low-power GPU, regardless of what the app asks for (if your project property 'GPU preference' is 'High performance', which is the default, then Construct is asking for the better GPU on dual GPU systems, but the system may ignore that request).

  • It's much easier to help if you can share the full text of any error messages. Also, do you have any browser extensions installed? If so try disabling them, as they can often interfere with Construct and cause problems.

    ERR_BLOCKED_BY_CLIENT usually means something on your computer decided to block Construct loading something. So it's quite possibly a browser extension that's blocked a resource Construct needs to work correctly, which then subsequently causes an error.