Ashley's Forum Posts

  • It comes with instructions, but if you're not familiar with running node.js servers, I'd probably advise against it. It's a lot easier to go online and connect to the Scirra-hosted one!

  • You still need a signalling server for that. It can be running on the same LAN though. Otherwise there's no way for the clients to find each other.

  • Most other game engines support spitting out a native APK that is not bundled with a web browser

    Construct 2 already supports this as well. Just target Android 5.0+, and it won't bundle Crosswalk, which is what increases the file size. It's only there for Android 4.x support, which is steadily shrinking.

  • The way this project is set up circumvents the collision cells optimisation. The cell size is the viewport size, so in this case by using a totally impractical size of 10000x10000 (honestly, surely nobody would ever choose that in practice?) forces all collisions to be made within one cell. So then you get the worst-case of all possible collision checks, plus the overhead of managing collision cells. That's probably why you're seeing it as slower.

    If you set the viewport size to something reasonable, it runs far faster. Even with a viewport size of 1000x1000 it runs several times faster for me.

    If you want a full view while using collision cells, set a reasonable viewport size, and then set a small layout scale so you can see everything. That way you'd get the same view but the improved performance too. I did this for some of the screenshots at the time. Also collision cells are an absolutely critical performance optimisation if used sensibly - in many cases they can completely eliminate 90% or more of all collision checks, which in many cases completely eliminates the performance overhead of collision checks. It's such a huge optimisation that it's definitely a good idea to work with it, not against it. Also I have to say reporting an issue about a change that was made over three years ago is not very helpful - the sooner you can make a report, the better.

    Closing as won't fix.

    • Post link icon

    Just to throw in one more post - Windows itself probably has far more bugs than Chrome. You just can't see them all on an easily searchable list. And you can't make your own reports to alert Microsoft to any issues that affect your software.

    So pointing at a normal bug tracker for a large software project doesn't really prove anything. In fact I have always counted this as a major plus - I can and do file bugs when they affect C2, and frequently Google fix them, and sometimes even within a few days. You can't do that with Windows or innumerable other software projects.

  • We're going to make all the versions of the editor available so you can roll back to an older version if necessary, just as you can with C2.

    Did you file a bug for the issue in r203? We've fixed probably hundreds of other bugs and issues since then, so staying on old versions can easily cause more problems than it solves.

  • We have weeks of updates scheduled. Please be patient!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • That's not an officially supported case in C2 - you could easily break things, and we cannot accept bug reports unless you are using a 100% unmodified engine - and equally it won't be an officially supported case in C3 either.

  • For what it's worth, I'll point out we've been maintaining the HTML5 runtime for years, and cases where Chrome updates it are very rare, and most of those were deliberate changes by Google that they warned everyone about for months. Any browser maker's job is to stay compatible with all the billions of websites on the Internet, so they tend to be extremely cautious with any changes that are not 100% backwards compatible.

    And in any cases that slip through the net? Simple, we just fix it! We have done in the past - and can do in the future - same-day updates to fix any critical problems like that.

    The desktop builds are entirely independent of the Chrome update process, so those will be the same regardless of what happens to Chrome updates. But we'll still be issuing regular updates of those as well, so the option to stay up-to-date is there.

  • I just got sent a .capx this week, so I'll look in to it. To say we're busy right now would be an understatement though! It won't last forever and I'll get to it.

    I must emphasise yet again that the bug report guidelines are there to make it possible for us to fix the bug. If you ever think it's taking too long to fix a bug, read the guidelines and try to follow them even more closely. In this case it took me three months to get anybody to send me a .capx, which adds three months to the time it takes to fix it.

    • Post link icon

    its the first time im seeing this you sell a product for years now theres 3-4 major things community wants like crazy but you dont care that much

    From my point of view, multiplatform support was definitely one of those 3-4 major things the community was asking us for.

  • As per our usual bug report guidelines we much prefer if you can send a minimal project, and the bug report guidelines include a guide on how to create that if you have a full project. If that doesn't work out though you can send a .capx to - ideally at least with all third-party plugins removed.

    • Post link icon

    I also don't think that anyone was asking for this.

    Mac and Linux support have been top feature requests for years - so I absolutely do think people were asking for this capability. We did it via the browser, and as we just announced, we will also be doing desktop builds - although they are almost identical to the browser version! Using a folder-based project (e.g. with Git/SVN) is pretty much the only feature you have to use them for - you can do everything else with the browser-based version.

    I know it's not really relevant if you use a limited number of Windows-only machines, but we did aim this at what people have been asking us almost daily for years. And as I say, there's still a ton to come.

    • Post link icon

    you should have given us the bad news up front like you did, AND give some features that people can get excited about. Even one major feature.

    We did! It runs in the browser. That's a huge feature. Maybe some people are sceptical, but it works beautifully. You can't get the feel of it from screenshots, you'll just have to wait for the public beta.

  • I'm not going to keep making the same points about native engines, I wrote a whole blog about it already.

    You should probably come up with a different name to talk about exporters - I equate "native exporters" with "native engines". I think you mean built-in exporters or something like that?