Ashley's Forum Posts

  • 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?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • Oh, 'Pick by UID' is another exception: it can immediately pick the correct instance without having to look at all of them.

    And yes, it only actually needs to be the first condition for that object type. Other unrelated conditions or groups can be above it.

  • Closing, please follow the bug report guidelines otherwise we cannot help.

  • Best report this type of issue to Ludei. Or for Android try Crosswalk instead.

  • keepee - it will probably always be true, yes, because once another condition has filtered some instances you can't look in collision cells any more since the cells contain all instances.

    You might still want to put collision checks at the top, even with other conditions. It depends on your project. If you have 1000 instances, a condition that filters down to a single instance still has to check the condition against all 1000 instances. The collision cells optimisation is unique in that it has the ability to only check the instances that happen to be in the same cell (assuming they're all fairly spread out), which could be a lot less, and then the next condition only needs to check those meeting the overlap condition. But the overlap condition could be more expensive if a lot of poly checks are being done.

    Overall I'd advise it's probably best to still put collision/overlap conditions at the top. When you get to very large numbers of instances, they are actually a lot more efficient due to not even having to check many instances, which can save you having to run ordinary conditions on lots of instances too.