Ashley's Forum Posts

  • Ah, thanks - that was enough of a clue that it was to do with paths that I finally figured it out. If you disable "Use new Intel XDK project format" it tries to export to an empty path (which ends up pointing at the install directory). It's fixed in the next build, and you can work around it by enabling "Use new Intel XDK project format".

  • I can't think of any limitations with the tilemap at all. You should be able to use any size tilemap with any size tiles and it will work more or less the same.

  • Browser makers are as performance-obsessed as any game engine - especially Chrome. Did you know, for example, it queues all WebGL calls, posts them to another thread, and runs them in parallel as JavaScript execution resumes in the main thread to start processing the next frame? That's an incredibly complex multi-threaded architecture that helps effectively eliminate the overhead of the graphics driver by overlapping it with the next frame's logic. That is so complex to implement that some native engines don't even try, and we get that for free in Chrome. I don't think you properly appreciate just how sophisticated modern browser technology is, and it's one of the reasons we now see C2 benchmarks in Chrome actually rivalling or even exceeding other native engines on the market. And still, we have people here who think we somehow have a slower or inferior engine in some way due to HTML5. You need to catch up - our HTML5 strategy has worked out great, and that is the reality today; it's not 2012 any more.

    Anyways, even just using Unity as an engine is a colossal amount of work. It's basically the same as us writing our own native engine, but using Unity as the framework. It's a forbidding amount of work for a startup and will push back everything everyone else wants by months, and - for what? Performance won't be that much better, if at all (I've read several criticisms of the poor performance of Unity for 2D games since it carries a lot of overhead from being a 3D engine). I think all it gets us is PS4 support. I agree that is important and can see how significant that is for many indie games, but that's not something we can justify that amount of work for right now. There's also a chance they could add HTML5 support anyway, like the Xbox One has, making such a project pointless and extremely risky in terms of investing our resources. And hey, at least you can publish to Xbox One with the Xbox Live Creators Program, it's not like you have no access to consoles at all.

  • While loops run until the subsequent conditions are false, and the keyboard input is only updated once per tick. So as soon as you press the down arrow it probably hangs the game as it enters an infinite loop.

  • Since this thread was originally posted in 2014, it's worth mentioning that Construct 2 now has a built-in feature to record a video of the canvas.

  • If the game performance is affected by the rendering resolution, your game is definitely GPU-bound. That means draw calls, events, and anything else CPU-side won't help. You need fewer force-own-texture layers, less overdraw, fewer shader effects, etc. GPU performance is tricky since there aren't good inspection tools at the moment, Chrome's dev tools won't help you with that. Maybe you could use low-quality fullscreen mode? Reverse-engineering a slow game to a fast one is really difficult, this is why all our advice says test on mobile from the start.

  • --To change the executable's image icon, you need to download a third party tool (I use Resource Hacker) and replace the default NW.js "compass" icon with the icon of your choice.

    This is tough because automatically updating the images involves reverse-engineering ancient icon formats (literally dating back to Windows 3.1) and in the case of EXEs, the binary format and resource packing format, and how to update resources in a large and complex executable. It could literally take a few weeks per platform to work this out. Meanwhile we have three engineers with months of high-priority work already backed up. Leaving this to external tools seems like the best solution now.

    [quote:3niukx88]--To change the default loading icon when you first open up an NW.js game, you have to manually replace the default icon with one of your own, overwriting it in the resource tree tab. This is not mentioned at all (except the forum posts I've found where other users had the same issue).

    You can edit loading-logo.png directly in Construct 3.

    [quote:3niukx88]--To disable devtools on a completed game, you need to download the standard, non-Construct version of NW.js or similarly, edit the .json data of your version of NW.js for C2 and add an argument to disable calling devtools with F12.

    This does not meaningfully improve the security of your game, if that's what you want. I'm not sure what anyone can do with your game even if they can open dev tools anyway, the code is all minified and already has reverse-engineering protections. If you just want to turn off the option you can already apply the command-line argument from within C3.

    [quote:3niukx88]--You also need to separately change the name that is displayed in the game's window (along the top left corner) by editing the NW.js JSON file.

    This is taken from the project name, so you can already set it within C3.

    [quote:3niukx88]--Last and probably least, no support for installers for a game or easily selecting the default save directory.

    NW.js games don't actually need an installer, so this seems like a benefit? If you really want to make an installer that just copies files to an install directory, there's plenty of free software projects out there that can handle it.

  • The download version will be almost identical to the browser version. The download version is literally the Chromium browser engine bundled with the web version of C3, and a few extra features added for things like local file access. So you can test it right now in the browser, it will pretty much be the same. The web version can export to Windows, Mac and Linux via NW.js and it works already.

  • There's a world of difference between relying on open-source projects and free software that implements standardised technology with open specifications, and transforming our business in to a UI skin for another closed-source game engine which doesn't care about us at all. If it really came to it, we can and would take over maintenance of any open-source project that we heavily depend on, or switch to another, but that seems pretty unlikely to happen.

    FWIW, just one example of the downsides - last I saw Unity's web export was extremely heavyweight, with tens of megabytes of overhead and often 30sec+ to start up on a high-end desktop, and they didn't actually try to support mobile web (at least initially) because the experience was too rough. Compare that to our lightweight engine which can download and start up quickly and run well on pretty much any mobile device now, even when wrapped as a native app. But this kind of thing doesn't seem to stop people from thinking everything would be better if we did that. Honestly, it's actually crazy.

  • AFAIK, tvOS does not have a web view, so cannot run HTML5 content. There's nothing we can do until Apple add support for that.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
    • Post link icon

  • I think really you want a "quality" option per-layer so you can render at a (custom) smaller size and stretch up to fill the display, similar to how low-quality fullscreen scaling works.

    I'm afraid we will not be adding any significant new features to C2 from now on, and this kind of improvement is something we'd only consider for the new C3 runtime.

    Also for what it's worth, this is one of those surprisingly tricky optimisation areas: using a lower-quality for a layer will cause it to use its own texture, which in some cases can use more fill rate than if you didn't lower the quality at all. The overhead of the own-texture copy has to be exceeded by the amount of GPU time saved by the lower quality rendering. This is not a simple equation and in some cases will just make things worse.

  • We've seen a few reports of this error but we still have no idea what causes it. Nobody on the Scirra team can reproduce it. Identifying what causes this issue and how to reproduce it is critical for us to be able to do anything about it.

  • Background throttling is quite complex - normally background web pages are suspended, but there are exceptions, which include if the tab is playing audio, and IIRC as of recent Chrome versions WebRTC connections count as an exception too.