Ashley's Forum Posts

  • Switch the project to the C3 runtime if you haven't already. Then it runs like any other C3 project.

    Other than that, I can only speculate it's a device with broken graphics drivers. That's usually what causes these types of issues. That's why the message says to install software updates - hopefully you'd get an updated driver.

  • Yes, it includes a browser engine, and a software renderer fallback for WebGL, so it should always work. I've no idea why it doesn't.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Construct 2 is now pretty old - it was first released in 2011, and so has a lot of legacy baggage that isn't needed any more. That includes the canvas2d renderer (used if you disable WebGL). WebGL can be ~10x faster and is now ubiquitously supported. The only reason there's an option is because years ago, it wasn't widely supported, but now it is. So just leave WebGL enabled. It's so widely supported that Construct 3 dropped the old canvas2d renderer and only uses WebGL.

  • You can only get the count of instance variables and their values by index.

    You can use that to make an array.

  • FYI there is already an "Ignore GPU blacklist" checkbox when exporting to NW.js, and it's checked by default.

  • Construct 2 is no longer available for sale. Try removing the plugins that prevent importing to C3, import the project, and then find alternatives for those plugins.

  • There will be a much bigger difference due to all the display variations out there than the actual compression, so I believe artists are out of luck here. No matter what they do it will look different on different screens.

    There's a difference between the same image pixel data being shown on different displays, and altering the actual image pixel data as lossy compression does.

    We do the same with audio in Construct. It is compressed, so why not graphics?

    Graphics are compressed too. You can also opt-in to lossy JPEG compression.

    Ideally ( if possible ) give people options, from what's currently in Construct to more severe compression.

    The more options there are, the more development work we have to do, the more bugs come up in different combinations of settings, the more things have to be maintained over time, more documentation and support questions come up, etc. It's also not clear how lossy PNG compression would work, since PNG itself is a lossless format. Are there different pre-processing algorithms out there? How to they compare on the quality/size trade-off? Are they all appropriate in different circumstances or are alternatives necessary (which further increase the options)?

    Also - as ever - we're a small team with limited resources, and already have years of work worth of features filed, so why should we work on this first and not other suggestions?

    You can also already apply lossy compression if you want - just recompress the exported spritesheet images after export using your own tools. So you can basically do it already manually.

  • Since all web content is architecture neutral, everything should run just fine on Apple Silicon systems with no changes. The performance sounds like it will be good, but as ever, the only way to tell with performance is to buy a system, and make measurements.

  • Yes, it's documented in Project properties.

  • You can try it yourself. It works everywhere. But as I said, you shouldn't export projects using it, unless it's for performance testing.

  • There is a big difference between "looks fine to me" and "looks fine across thousands of games using an incredibly wide array of different art styles, many of which designed by artists who are sensitive to the precise appearance of their games".

  • It does not boost performance. Normally frames are scheduled once per display refresh. There's no point generating frames faster than the display hardware updates - they won't be seen, and it just wastes power.

    Unlimited framerate mode instead schedules frames as fast as possible. It's for performance testing. However since it uses loads of power generating frames that will never be seen, it will needlessly drain the battery on laptops and mobiles, so you should never publish an actual game using that mode.

    That's pretty much all there is to it.

  • Construct 3 already uses a WebAssembly build of OptiPNG to optimise your images on export (if you enable image recompression). This can also do automatic palette reduction to smaller 8-bit PNGs as well - particularly nice for retro style games with low color counts.

    compresspng.com does not seem to include any details about what it really does, but I would guess it is using lossy compression. A tool like Construct can't in general use lossy compression since it will degrade artwork, and I think most artists will want their art quality preserved.

  • In both cases, as per the original announcement, both C2 and the C2 runtime in C3 are only being supported with "essential bug fixes and compatibility updates". Minor or non-essential reports will no longer be investigated. Basically that means if some browser update happened that broke all Construct 2 games, we'd fix it, but other than that we won't be doing any further work on it. Since this appears to fall in the category of non-essential, we won't fix anything involving C2 or the C2 runtime if you file an issue for it.

    In other words, since February 2020, C2 and the C2 runtime are not actively supported, they're just being kept alive with essential maintenance. The purpose of the delay until July 2021 is merely to give you plenty of time to upgrade to C3 with the C3 runtime, with the confidence C2 won't suddenly stop working before then.

  • There's not a lot of value in fixing bugs in a codebase that will be removed in a few months time. I'd much rather everyone just switched over to the C3 runtime. The whole goal of retiring the C2 runtime is to eliminate the maintenance burden of having to work on it.