+1 as it is bothering that Inside the editor, when you drag an instance, it can be a waste of time to resize it as it should (first exemple:tiled backgrounds, you need a big one first, congratz, all of the next ones will be that big, even if you needed a smaller one...) or change the instances variable one by one just because the first one you created inside C2 was not the "default type" one you wanted to use afterwards to gain some time.

Goes for other objects of course.

It seems, for this exact moment, to be:

-cocoonJS canvas+ for android (fast when it actually works, and while scirra depreciated it, ludei started right after to do things correctly so it is useable, more infos can be gathered around)

-cocoonJS webview+ for iOS8 (silverforce particularly seems to really use it and have not had issues with it)

Crosswalk is not fine at the moment due to bugs (which are said to be temporary, but since it is with the chromium engine itself, you can expect it to be quite problematic until it is fixed in chrome and then integrated to the current crosswalk), once they are fixed it should be really fine (aka like it was before being broken), but since I do not know your deadline requirement nor your exact project, I would say not yet worth it currently.

Phonegap is plain bad for android below 5.0, and with android 5.0, you have to expect the possibility that the webview may update and break your game one day.

My guess would be that if html5 is not something you care at all, and if performances are really important, you go onto another engine, at least that is how I feel about the situation, I mean sure there are always dependence on third party, but as far as html5 wrapper goes, there are far too many things to consider for them to not break completely in one update For a specific engine For now at least.

My guess would be that, it picks the object before it is destroyed (in case you wanted to act on it before destroying it, like spawning object on it), so you would need a pick all between the on destroy and the picking condition.

I have no idea on how to disable this on NW.js I will admit, let's hope someone else knows.

I remember that browsers by default requires certain inputs presses on the controller for it to be registered as being here on the webpage, for "privacy security reasons" as they say.

From the C2 manual:"

To prevent allowing websites to track you by your available controllers, most browsers supporting Gamepad input will report that there are no controllers connected until a button is pressed on one of the devices."

My guess would be that multiple layouts are not the tool you might be looking for in that case, but rather have one layout for, lets say the entire brinstar region, lock the camera inside the current room, and when you go through the door, samus stops inside the door, the camera moves from the current room to the other and locks inside it, then samus goes to the other side of the door, however if the ennemies continues to move, you might have the risk of them going inside the door and hurt you (which happens actually in the first metroid sometimes, not complaining but that was buulllllll*hit).

Doing this however requires to manage ennemies and items carefully so the game does not have too many things to compute (being inspired by the original metroid on those choices can be a fine idea.), and I will admit this is not something C2 helps a lot with (Being able to scroll from one "layout" to another would be easier, but it is not possible).

I think the scale rate works with the layout scale you can set in events, not the game scale relative to the windows real size, not sure 100% though.

like:

-the concept of a large number of creatures, instead of x classes

-type relations are a base of almost every combat

-random encounters are limited to grassy areas (except on caves)

-Vaporeon is lovely, It had to be said

did not like:

-overdoing some of the "multiplayer aspects" when the technology just was not yet

-the sort of elitism and science going around it to have the best teams, seriously, it is just too much for me

-shinies, most useless things since the splash attack, I prefer not catching a pokemon if it is shiny because of how weird people are with them

-leveling up can be a bother since wild pokemons are low levels generally...

53 Kb JPEG picture loads to sprite and then converts (with 5-6 seconds idle and 0 fps) into 400 kb text data..

I'm just trying to understand the meaning of this procedure..

It's a pity.. a had a lot of hopes on this conversion

base64 seems only useful if you need to manipulates only strings data, as it "converts" files /data into a string.

mailalon you can right click in the exporter window to show the exporters not maintained by scirra (cocoonJS is not maintained by scirra but ludei still works on it, I think you may need the ludei plugin, which is on ludei signature last time I checked)

szymek I was actually agreeing with that, exporters should be a choice of the user and only the user, as they evolve at a fast pace and can break easily, and each game may have different needs (some apps can work with the jitter but not without the xml, others will need specific features from ludei or fast pace action, etc..), also, that would make scirra not having to rely on one particular export that may (..will at one point) break for an unknown amount of time.

TiAm money is not the only reason for people to want an android version, sometimes the goal is just to have a larger audience (even though technically the html5 exports would work with that, but that is another story), also piracy issues could be taken seriously if they truly wanted it I think.

szymek the curious thing is that C2 is made to have a code produced that is read with a player, and none of said players is reliable, I mean:

-canvas+ (cocoonJS only option at the time) went from "nice" to "meh." to "completely broken for 6 months" then "rebecame nice but we can see that C2 is not made to work with it as no large game can even starts up" to finally "we got deprecated? too bad we made it work now", nothing said they won't do it again though.

-crosswalk have a lot of features, but the chromium engine is a bad choice, heck, choosing one engine for the users in the end was not a good idea to begin with, and so chromium sometimes breaks retrocompatibility, and also some basic things like V-sync, in the end, it was a more clever choice than canvas+ at the time.

and the cycle can go on with this one too, nothing can guarantee that it would last for 6 months if it worked with C2, in the end, we might as well have none said "official exporters" and let the users find the gems themselves, sure issues can be corrected, but waiting for an eventual fix is simply not worth it.