Ashley's Forum Posts

  • We already support a new physics engine, the asm.js compiled version of box2d, available in the latest beta. I doubt any non-asm.js library could beat it performance-wise, it's close to native engines in speed.

  • jayderyu - I think you're talking about something else - the suggestion in this topic is not to download assets until they're needed. If you switch between layouts, right now that means everything is already downloaded but it still needs to load stuff in to memory. If there is 250mb of images to load in to memory in the next layout, that's just plain and simple a lot of work, and even a native engine is going to take a few seconds to get through that (indeed, that all happens in the browser engine which is actually native code). So that's simply a very large amount of work given the current capabilities of computers.

    Arima - if your game is already offline (e.g. node-webkit), then there is nothing to download. As above, there may still be pauses between switching layouts not because anything is being downloaded, but simply because loading all the images in to memory can take a moment. And to clarify, layout-by-layout memory management means it does not load the entire game to memory on startup, only the first layout, and when you switch layout it only loads the next layout's images, and so on.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 1) This is on the todo list. We can't give an ETA, sorry!

    2) This is probably already doable via events. The Pin behavior might be especially useful here. We generally avoid implementing high-level features in the engine in favour of general-purpose building blocks, to avoid becoming a "cookie-cutter engine".

    And yes, we don't maintain the CocoonJS plugin any more, Ludei do.

  • Due to the offline cache, the browser gets to work downloading the entire game right away. If this was disabled, offline support would stop working (which I think is a pretty significant feature, especially for webapp-based platforms like iOS and Android's 'Add to home screen', Firefox OS, the Chrome Web Store, Amazon web apps, etc). So there's no point directing the browser to only download assets half-way through the game - it's already working on that.

    Perhaps the loader layout system could be extended though. If the assets were downloaded in sequential order for each layout, then rather than having just one loader layout, you could go to any layout that has been loaded so far. So for example you could play up to level 3 if it's downloaded that far, but you'd have to wait before playing level 4 if it hasn't downloaded its assets yet.

    Not sure how easy that would be to implement...

  • I think you missed the point of the tutorial. Everything the tutorial describes works on all platforms and operating systems. (The one exception is CocoonJS which doesn't support letterbox modes.)

    The simplest way to solve it is just use letterbox scale mode. Now it scales the game for any size screen on any system, with black bars down the side. The rest of the article is more detail about aspect ratios and other features.

  • The code sample you posted is extraordinarily inefficient and will probably be far too slow to be useful. This is a reason we use polygon collisions in Construct 2.

    Why do you need per-pixel collisions anyway? I've not seen a convincing case that polygon collisions can't cover.

  • Did you try updating your graphics card drivers?

  • Collision cells didn't change in r156. Did you try in Internet Explorer and Firefox?

  • Post a reproducing .capx to the bugs forum if you want this investigated as a bug.

  • Executing strings with the Browser object is an ugly hack. If you want to do it properly, use the Javascript SDK.

  • Same as ever... letterbox integer scale, point sampling, pixel rounding. Any other settings and you're liable to get seams. (I swear I make this exact post every few days :P)

    Didn't the tilemap object ask you to set those settings when you added it to the layout? Did you choose not to or something?

  • Are you sure it's not a bug in Firefox OS? If it works correctly on all other platforms, that would suggest it's a bug you should report to Mozilla instead.

  • Our changelogs are usually comprehensive and there's nothing that changed in r156 that I can imagine having any kind of performance difference of the kind that you describe. The whole build was basically a series of minor tweaks. Which browsers, devices or exports have you tested precisely, and is it the same across all of them?

  • It won't be easy to change this: the engine only supports polygon collision masks, and there is a lot of code around that.