Ashley's Forum Posts

  • Use the plugin SDK.

  • Tilemaps are a lot faster, because they are specifically optimised for tiled rendering. Using lots of sprites will be slower. You also have better editing tools for tilemaps in the editor.

  • Also I've learned about how NW export games load all the layouts into memory and never free any of it

    That's not true, layout-by-layout loading frees images when you change layouts, so it only ever has one layout loaded. See Memory usage.

    If you reduce the size of the window size (misleading name: should be viewport size) and use the same size window with letterbox scale, it will make no difference at all: the same rendering work is done. What does make a difference is reducing the window size and turning on "low quality" fullscreen mode. That renders the entire game smaller, then stretches the final result to the display size. It's almost the same as actually switching the monitor resolution (which would just do the final stretch on the monitor display chip, but GPUs are really fast at stretching things).

    Intel graphics chips suck. They share system memory so have really constrained bandwidth and very low fillrate limits. You have to design games very carefully to work well on them. The good news is many laptops with Intel chips are really dual-GPU and have a powerful AMD or nVidia card as well. If you can make sure everyone switches your game to the powerful GPU, all your performance issues should be resolved!

  • I'm not saying anything will or won't happen for certain. We just want to use web standards where possible.

  • If you have any issues, please file a bug report to the bugs forum following all the guidelines. It is impossible to help or even say anything without a specific description of what is happening and a .capx demonstrating what you're doing.

  • You do not have permission to view this post

  • If you are referring to Ashley, as far as I know he only works on C3 at the moment. Scirra hired a new member to do the updates for C2.

    It's actually the other way round: Diego is working on C3 with me, but I still do maintenance on C2 so it's not left behind.

    ethanpil - several of the features you highlight have existing web standards, e.g. for camera and geolocation. We want to use the web standards wherever possible. Cordova APIs should only be necessary for non-standard stuff like IAP and ads, and maybe push notifications, but web standards are in progress even for that. Even then, for something like ads, there are hundreds of services out there and it's an impossible task to support them all, so in that case it's intended that third party plugins can cover the services we don't cover officially.

  • As I said, I don't really want to get sucked in to making hacky changes because WINE doesn't support something. C3 should bring full official support for Linux. NW.js relies on localhost because it's a simple and elegant way to get NW preview to work: it's just treated like another browser.

  • Doesn't NW.js work? I didn't think it ran a server and could just load files from disk.

    Outside of that, you can't really run projects from disk, because browsers have very strict security rules for files from disk which generally prevent it from starting up the game. Besides, I don't really want to get sucked in to hacking in features just to work around incomplete features in WINE, better that they fix it their end.

  • Video encoding is a lot more complex and specialist than audio encoding as well, which is another reason you might want to find your own tools to do the encoding. Also while PCM WAV is a de-facto standard for uncompressed audio, I'm not aware that there's an equivalent for video. Uncompressed files are so huge that I think everyone mainly deals in compressed formats (perhaps at very high quality settings). So while audio typically involves just encoding, video could involve transcoding, which is more complicated and lossy. Throw patent-encumbered formats in to the mix, and the fact Windows doesn't have a built-in video encoder like it has for audio, and a wide range of exotic formats across platforms, and you find it's a real minefield. That's why it's not supported the same as with audio.

    • Post link icon

    Just a quick update on the NW.js/greenworks situation:

    I've been testing NW.js 0.13.0-alpha4 (and alpha5 is already out, looks like their release cycle is finally speeding up). It's based on Chrome 45 (46 now with alpha5 I think) and the jank issue looks to be finally fixed - every frame comes within 0.1ms of v-sync on my Windows dev machine running sbperftest. However there have been some backwards-incompatible changes going from NW.js 0.12 to 0.13, and changes to the Construct 2 build are necessary for it to export. So the next beta should come with an official NW.js 0.13-alpha5 (or newer) support, but you'll need that beta or newer to export with it. Either that release or the next I'll review Greenworks integration, and hopefully be able to ship it in the C2 editor at last.

    Just to review why this has taken so long in case some of you weren't aware: NW.js has been on a slower release cycle than Chrome for a while, generally releasing only once every few months. Chrome 38 had a bug that basically broke v-sync scheduling and made everything janky. Google eventually fixed it a couple of versions later, but NW.js got their next update in just before the fix, so it's been affected by the bug for a lot longer than Chrome. Then on top of that their 0.13 release has involved significantly reworking how the architecture works, which has meant a longer development time than usual.

    The good news: NW.js is nearly there with the 0.13 release, and the release cycle seems to be speeding up again (they've mentioned on the email list about how they have made big improvements to the build system and reduced build times a lot). Although the next update will require a new version of C2, we've still had NW.js updates separated from C2 for a while now, so we can update them independently and avoid the problem with earlier builds where you could end up stuck with a broken version. And once Greenworks is integrated that should make Steam publishing a bit easier. The next update will be a huge jump in the Chrome version - from 0.10.5 to 0.13 covers Chrome 35 to Chrome 46, with tons of bug fixes, performance improvements, and new or improved features (including better WebRTC compatibility). So hopefully things will be a lot better from the next build onwards.

  • We know lots of developers do use the Intel XDK, PhoneGap Build and other services successfully, but that's not to say the publishing workflow couldn't be smoother. It's unlikely we'll make significant changes in the C2 time scale since most of our efforts are going in to C3 right now, but we're aware of the difficulty some people face with publishing, so we'll be looking in to what we can do to improve this for the future. We do want to avoid pitfalls like locking users to a specific version, and it's a little more complicated than the NW.js model since Cordova & app store publishing is more involved than just copy-pasting the NW.js files around. Given we're still relatively small and there are free options available we hadn't prioritised this, but we are well aware of this kind of feedback coming up on the forum and we'll be thinking about how to make it better for C3.

  • Is the performance the same in the Chrome browser on the device?

    What does it say if you browse to chrome://gpu in the Chrome browser on the device?

    GPU blacklisting is common, especially on old Android devices like the kind that would still be running Jelly Bean. It's an Android ecosystem problem.

  • Unfortunately SVG is not currently supported in C2. PNGs are the only way to go.

  • Long animations do eat up a lot of memory - you have to just make them use fewer or smaller frames to reduce that, or use something else entirely like Spriter animations.

    The estimated memory usage is for the largest layout, since C2 only loads a single layout at a time to reduce the peak memory usage. It's also based almost entirely on the image memory, so it should be regarded as a minimum - sounds, logic and other OS and browser features will go on top of that.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads