Instead of using the scrollto behaviour, you can also use the system scrollto action. This gives far greater control possibilities.

I guess bullet behaviour would do..

on up pressed and is not overlapping sky add to speed.

on left pressed set angle to: bullet.angle-1

on left pressed set angle to: bullet.angle+1

on collision with surface if angle is going up set gravity to very high

on collision with surface if angle is going down set gravity to 0

add the tail by pinning rope style and voila..

Could need some tweaking..

system compare two values : timescale = 1

This should work:

<img src="https://dl.dropboxusercontent.com/u/48563442/Pause-button.jpg" border="0" />

I still don't see why you'd need a null animation but ok..

you could just check if your firing animation is playing before spawning bullets. you could even check what frame it's on and spawn bullets on a specifivc frame.

I didn't find the solution yet, but maybe you will.

everytime a hexagon is made, in the middle of it the number 7 shows up.

So your program seems to know the middle ball of your hexagon.

Couldn't you create a score based on that number 7 or on the balls in the middle of hexagons?

set the layer paralax to 0,0 that way it will stay in it's place.

This will probably not be resolved without letting someone look at your capx. The problem lies within the way you have your events set up and will probably be easily and quickly solved if we don't have to guess where the issue lies.

Check if the order of your events is right.

The position of the arm depends on the position of the shoulder, so the shoulder must be set in the correct position first in your event sheet, the angle of the arm depends on it's position so position of the arm must be set before the angle.

so the order should be:

• make sure the shoulder is in it's final position for that tick
• make sure the arm is in it's final position for that tick
• set arm angle.

If this is all correct and lagging still occurs, seeing how your events are set up might give an answer.

The arm is pinned and you are trying to set it's position at the same time?

That means every tick the arm is told to be at two different positions

1 - the position the pin behaviour demands.

2 - the position you tell it to be.

That wont really work.

I think the problem is you are trying to pin your arm every tick, but that's not what the pin behaviour is meant for.

once you pin a sprite it will move relatively to the sprite it's pinned to. Resetting the position of the pin every tick makes the pin behaviour kinda useless.

There is no correct ratio.

you could make it 16:9 or 4:3 or 14:9 or 1:1

Actually anything will do depending on what kind of game you are making.

If your intention is to make a game that runs fullscreen, you should make sure that after scaling the bits of the screen not used for your game have some kind of graphics on them, or are a background-colour suitable as a background to your game.

If you use scale-inner nothing outside of your "playing-area" will be rendered, but on devices with resolutions very far apart from your design-choice chance is that too much of your "playing-area" is cut of.

if you use scale outer Construct will make sure your whole project-size area is on screen and make visible all the surroundings on your layout that fit inside the open window area.

these two options are best for real full screen, but you'll have to choose which one suits your need and create your layout accordingly.