Objects using delta time, like behaviors, can do things like "jump" through walls when the framerate stalls, because movement is basically a series of teleports that happens every frame. If the framerate gets too low, as delta time results in pixels per second moved, the gaps between "teleport locations" can jump entirely over obstacles, meaning the collision detection doesn't catch them.

The easiest solution to this is to set a minimum (or maximum, I can't remember how it's labeled at the moment) dt in the project properties (I think it's under some advanced section). Set it to something no higher than 0.1, and if the framerate stalls lower than 10 fps, the gameplay will slow as well, preventing the player from jumping through obstacles.

Yeah, I guess I was thinking a popup could appear explaining that the original had been deleted, but you're right about duplicating them, I hadn't thought of that. I guess it is better the way it is.

We might eventually add something like mesh distortion from Classic back in, but it's a very complex feature to get right. Users expect the collision mask is distorted the same way and so on, and used incorrectly it can cause performance problems too.

Very much please add this feature! Even with the collision mask not distorted with the image, it's very useful and awesome and I utterly loved it in CC. I also found ways to make my own distorted collision mask using invisible sprites.

What do you mean by "used incorrectly" though? For reference if it ever gets put in, so I can know what to avoid.

Ashley - what about having copying and pasting them work as well, so when you paste the previous global is deleted, and the removing/reappearing of code part doesn't have to happen? It's a little nerve-wracking to have the code relating to it disappear.

You could also do something like have all the real gameplay sprites running as normal but made invisible, then every x seconds or ticks update the locations of visible display sprites. Or use rojohound's canvas plugin and paste to that every x seconds or ticks. Or even possibly turn off the background for all the layers, set it so c2 doesn't clear the background, and then make the gameplay layers visible every x seconds or ticks instead.

Collision checks are two tiered - first there's a simple bounding box check, then if there's an overlap, it does a second check using the collision polygons of those picked instances.

You can reduce the collision checks by setting conditions to filter out some of them beforehand. Such as:

Sprite.variable=1

Sprite overlaps sprite2

• rotate sprite

Then only the sprite instances with variable=1 are checked, saving performance.

I haven't tried it, but you might be able to achieve this by checking the device's orientation by comparing if windowwidth>windowheight and change the layout angle accordingly.

On mobile, I have found that performance is actually worse if objects are rotated. Not sure why.

[TUBE]http://www.youtube.com/watch?v=gNRi0xcwW_s[/TUBE]

:)

Made with construct classic, but everything in it could have been done with C2 as well (I wouldn't recommend using CC over C2, especially if you want to make a large project like an RPG. C2 is far, far better, and CC has a lot of... issues).

Upsides? Tons of them. Easy to use but still powerful (basically as long as it's 2d, you can make it in construct), the program is updated almost every week, helpful friendly community.

Tshirtbooth, an influential GS user, recently decided to switch to C2 from GS, so that's a vote of confidence there. :) http://www.scirra.com/forum/topic59146.html

Groups, while not events, count for the number of events. There also could be 'hidden' subevents, as subevent trees can be collapsed like groups can.

I got my ipad 3 like a month and a half ago, but I don't have buyer's remorse. The improved camera and 2x speed would be nice, but the one I have is fast enough to run the games I'm currently making and everything else I want to use.