I think some blend modes (destination in?) can be used so sprites are actually showing what is under them, however, I think they need to be on the same layer as the masking one. Just remember to verify if you need to force the texture of said layer for it to work correctly.

https://www.scirra.com/images/articles/blendmodes.png

Edit: in your context, I think it is more:

-Bottom layer

-top layer with solid color, texture forced, objects with destination out are used to see through it

I will also report that, as I was seeing this subject, the top went also in error thingy, only happenend once but just in case it is useful:

https://www.scirra.com/forum/download/file.php?mode=view&id=6918&sid=p1rcnzxldoeusesfgnwfytxxune4d65q

The thing is C2 was done not to have a fixed 60 fps framerate, but a V-synced based framerate as far as I understand, however, I agree that lower fps that does not vary too much should not be a problem for the player (I will keep an eye on this discussion)

For collisions however, I woild think it can be possible to have a more precise way to check them, but it would be more costly (moving first the sprite to a certain distance based off it's size, then check, if no collisions, repeat until you are arrived). So it will not be really efficient, I also supporrt the idea of a fixable framerate (like every 1/30 seconds, recalculate the non trigger based logic then render on screen, but that may cause issues with triggers triggering between those simulated ticks)

There is no bulletproof way, however if it is only for touchscreen purpose, you can have the player having to click/touch a button in the main menu in order to know which input is used (this will not work well on the stock android browser though which triggers both types of inputs on touch).

For achievements and such, I am not sure why you would need different achievements, but I would base them on inputs still if really needed (as even some people may use gamepad or keyboard or mouse on a phone compatible with them, and some desktops have also touchscreen)

http://answers.microsoft.com/en-us/ie/f ... e7e04a0642 maybe related.

Also I would suggest not using the "is on mobile device" check, as it can be annoying for a lot of users, is unreliable, and will be countered in only a few options of mobile browsers (exemple of unreliable: android is always considered mobile regardless of the device running it I think), and also means you are doing things differently just based on the fact it may be a mobile, which is kind of unfair for anyone unless you provide a way to access both versions regardeless of the device.

To be honest, I would not mind if C2 used a little more on his image editor, but it is not necessary, but tools like selection based on color for exemple would,be nice to have, but this is going a little off topic.

Containers and families do not work well together, so even if you are using them in that case, all instances of the text object are picked so all will be affected by the actions.

And if you were not using containers, then this is the expected result.

Either not use cocoonJS

Or try to place some elements dynamically with the viewport expressions so the game adapt itself to any kind of aspect ratio.

Release 139 is one year old, so there may be some breaking changes that occured even though scirra does a lot of effort to reduce them to the bare bone.

I would suggest trying it with some releases between 139 and 178, so you can see around which release it stopped working

Then using the releases notes you should be able to see the breaking changes related to it maybe.

https://www.scirra.com/construct2/releases

Edit: if you can try r158 and r152, if it does not work in r158, but works in r152, it may be related to the fact the animation speed expression is now always positive

I know I will sound really like the one that thinks you are stupid and I am sorry for that, but mistakes that are obvious are sometimes the solutions so I will ask:

Isn't the function object already added to your project?

The thing is, the strenght of C2 is that you can make almost anything 2D wise, the event system is opened enough to let you program all sorts of mechanics, then the behaviors are making the mechanics lighter, and all of that with no syntaxic issue.

In 3D you would have to have some behaviors to help and due to the fact 3D maths is not as easy as 2D maths, the number of parameters will increase, and their definitions will be harder than your clasical 2D world parameters (angles+distance? You cannot define a movement with that alone, collisions? How would that work with a platform behavior, with a cube that does not spin? Even the language can become a barrier as those are not everyday's words sometimes), then the event sheet has to be as powerful too, while being understandable, not easy due to the targetted demographic of C2, also this would have to be used by people (I personnaly do not even care about doing 3D games, and most people are either targeting low end devices for html5 publishers, or doing small games so 3D is not an huge addition to be had at this moment in C2's targetted demographic.)

Or maybe just 3D graphics applyed to a 2D universe? I do not see that being really useful if it is just what it is doing really, but in that case a simple plugin that would display a 3d model instead of a 2D image would do the trick just fine, then you would use sprites for the collisions and logic of the game.

I think some displays have an option to dynamically change the luminosity based on what is displayed. If it is indeed it, it is dependant on your monitor, but should be an option I think.