to be honest, even without the Wkwebview bug itself, a condition to test if a save exists, and an action to delete a save are still something people can expect to find by themselves rather than having to build it with the webstorage (some people say it is not hard, true, but it is just troublesome and feels like a feature incomplete, the same way being unable to reset persistents objects was).

well, to be fair, micro-optimisation is always context dependant, if there is really a check of every instances with pick by uid, that would be bothering if your game needs it, but nothing if it was not that used in your game, same goes with collisions optimisations (even though those can be easily the bottleneck), etc... But in that case, if the pick by uid would be wasteful, that would be dissapointing.

always have a critic eye over ashley's blogposts, as he tries both to talk to people that can go really far in wasteful design and also he tries to be general and so, something true can become false depending on how you did your game (the recent render cells are a micro optimisation for a lot of games, it can even be worse, but in some defined cases, it is nice and can save out a lot of time), learning to identify what is really causing trouble is something that will help you in the long run.

also have a critic eye over other people talking about their experiences too, for the same reasons.

How can we find out how the Object.PickByUID action specifically works? If it has to iterate every object instance, it's pretty bad. And I agree, being able to pass object refs into functions would work perfectly. If it iterates all instances, I'll be forced to building some kind of behavior like I described in OP.

one solution would be to try to pick it (no associated actions) with an awful large amount of instances, and compare that to not doing anything.

even though I think it was pretty much direct IIRC.I would think that is what C2 actually does behind the scène everytime a picking is doen: get the list of selected objects, and for each pick by uid.

Would my project run if webgl would be set as render but wouldn't be supported? Cause my projects run.

if webGL is not avaliable, it falls back to the canvas2D which should look the same (but slower and without effects) even if you set webGL On in C2, the renderer system expression returns either canvas2d or webgl, so you can check it is using webgl or not with it.

alternatively opening a new url with chrome://gpu as url in node webkit might say the informations regarding the gpu compatibility (by doing it in node webkit, not in chrome)

I guess technically could be possible (after all, a sprite is showing part of a spritesheet when you think about it), not sure that a behavior would do it however, I think more of an effect or a dedicated plugin for that use, not sure someone did one.

alternatively, the paster plugin could work:you paste a part of the big image.

well, there is an experimental plugin for that it seems:

never used it, but some people in the thread seems to have good results with it.

hope that helps

sqiddster would just using the browser object "go to URL" chrome://gpu/ works to see that (I am not on my computer right now)?

I kind of fail to see why there is still those "get rid of html5", no, it is not "fairly new technology" the thing, but relying on 3rd party was one of the most important aspects, and I could be wrong but everyone should have already known that fact at the time they bought it (if not, it is not my problem but either scirra's or yours so I feel like I can say that without too much trouble), not that it does not bother me, but I knew it could have been an issue. And also I would bet if scirra did not had gone for html5, there would not have been C2, but nothing at all, not like it was a choice, but that is not even the issue.

The same way I would not use a screwdriver to pin a nail on the wall, C2's problem is not html5, it is not relying on 3rd parties either, that is what made it altogether, C2's issue might be trying to go outside of its realm while not doing it completely: you either go full and rely only on the operating system itself (natively), or stay in the browser realm, by taking simply the browser out of the customer equation (as you choose it for him, which is not your job at all), you break that chain and become responsible for no good reason.

When I saw first time the awesomium export (which was the first exe exporter), I liked the concept but feared 2 things, and who would have known, both happened:

-html5 is still an unviable target for multiplatform games (not because of performances obviously, but because it is easier to go squatting other platforms rather than using this one), C2 can handle really nice games on desktops and mobiles and tablets (won't run on iphone4? only useful if you target it), yet most of non wrapped games are simple templates it seems.

-rely on 3rd parties when it should not be the case: browser gaming (or browser activities in general) rely on the browser interpreting correctly everything in a fast way, that is completely fine for reasons I should not have to describe on an html5 game engine forum, however, wrapping your games just does not cut it, the performance improvement do not exist (or is very low), you still rely on an interpreter to do the job correctly (and it can fail pretty miserably), even if they are working correctly:What is the point? distribution and selling? Seems more like a shortcut to NOT correct that issue in the html5 platform. Functionnalities? Makes sense, but most of what I saw were just adding advertisements to android games, which is doable in an html5 game (even on a webpage), and if that is not the case, that is not the technology that is limiting us, again.

The same way emulators are not affiliated with the consoles manufacturers (apart from SEGA and their genesises emulators), wrappers (which emulates a web environnement) should be the responsability of the end user of C2/or the end user of the game itself, and not something that is a "feature".

however if they go into C3, they can do whatever they want, since it would be a new program subject to another license, other objectives, etc.. but for C2, deleting html5 would be not only sad, but would also counter what they are saying they are selling (which is an html5 engine).

Well, as long as we don't throw away the html5 export, it is fine (that is what I paid for, and that only).

however I would love to see the end of wrapper support alltogether:

not saying replacing them with native exporters (it can be done, but that is not the point of my request), just throw them away, wrapper specific or browser specific features are not something that should even have been done in the first place, if someone wants to have a wrapper specific feature, either let them implement it themselves, or give them a base to work with delivered AS IS with no warranty whatsoever, same goes with the exporters, wrappers are made by third party, and none are to be supported by scirra, C2 produce Javascript which I would really hope is based on defined specifications, then the wrappers interprets that, so "official support" just means you are doing the work backwards.

actually, phonegap is not the future at all, it is either based on the OS version (and so will be outdated with time like IE was), or is updated without the app itself, which can be disastrous too, crosswalk and node webkit are fine, but I still do not see much point in using them for more than half the applications (speaking technicity wise, the browser can do almost the same for most apps I saw, only being paid can justify that use, and sometimes it is not even the case), and custom engines are also prone to issues and incompatibilities too, my point: do not support what you cannot, the users can make them work, fine, they cannot, too bad, not your job, when cocoonJS canvas+ got deprecated, it went better for a time it seems, see the pattern?

3rd party exporters are to banish from C2 itself, from the homepage too, if that means not being replaced with anything, that is fine: wrapping by hand is not something that should be known by the users I think, as it is not related to C2 at all, I just want to see that being completely done (there is no real complete support anyway, so the change is minor).

apart from that, not many complains on my part.

+1 too, it can be annoying for the pin behavior for this exact reason, which is troublesome if you are not just pinning position and angle.

Lunatrap I see what you mean, but that is normal: not everyone has the same capacities (I am fairly decent with math, but then I see what rojo is doing, and I am like "... of course, that does make sense.. I think... I guess... I do not know... who wants some cake?"), but it is all about learning how and when to use the tools, and maths is one of them (the calculs themselves are not that important, what they can do is).

If you can gather some maths books (I do not know your age/situation/etc.) that matches your current maths skills, you could learn some things.

lerp(a, b, x) is used to get a value from a percentage.

a is the minimum

b is the maximum

x is the percentage (from 0 to 1)

at x=0, you have the minimum (a), at x=1, you have the maximum (b)

it is basically the same thing as what people use to scale a lifebar relative to the health.

clamp is used to keep a value between two boundaries

exemple, I want my health to be between minimum and maximum when I substract damage

set health to clamp(health-damage, minimum, maximum) will guarantee that health will not go over maximum, nor under minimum.

> I, like many others, hope Ashley will add more functionality to the tilemap object eventually, but he is, unfortunately, only one man :/

>

Scirra has one programmer???...

https://www.scirra.com/people

short awnser: yes.