ahostbr

I think the "import sprite strip" does the work well.

We were told in the blog that some new feature would be available soon for the image editor. In cc you could select an area and then Ctrl+C, change frame, Ctrl+V. Seems to be what you described

Yeah usually it's better to group things to avoid code copy/pasting. And grouping things under the same objecttype is a workaround while we wait for families.

But in most cases, even if families were available, I would still use the same sprite. Because to me it's the same concept "background" and it makes capx cleaner.

An you can have one collision polygon per frame.

Ashley

%180 ?... isn't that weird?

181 is the same as -179

but 181%180 = 1 isn't it?

Anyway yeah as I said I probably put too much %360

because at the time, the interpolation kept bugging and I was over cautious (of course the issue were elswhere)

yeah the fade behavior is a bit incomplete, lack that activate/deactivate. you can't just stop the object from doing his fading .... oh... maybe timescale?

indeed... works neatly

neatFade.capx

Also —

You don't need to destroy... behavior does that for you (:

What I did on someone's capx

<img src="http://dl.dropbox.com/u/23551572/C2/angleLerping.png" border="0" />

If I remember I was smooth rotating the layout to align with the rotation of the Player (this Player.Angle)

I don't think you need all these %360 though... I was just being too carefull

I would put the origin at top left of the background sprite.

Put your two background in two animation frame of the same sprite

set the speed of the animation to 0

And then

Global Variable offsetX = 0 //Offset for the next background
Global Variable before = 0 //before or not (for picking)
+Player:is Overlapping Background
  -> System: set offset = Background.X+Background.Width
  -> System: set before = 0
  +Background: X<Player.X+Background.Width/2
    -> System: set offset = Background.X
    -> System: set before = 1
+Player:[invert] is Overlaping Background
  +System: before = 1
    ->System: substract Background.width from offset
  ->System: set X to Offset

In my opinion, layer rotation isn't robust enough yet to be used in something as complicated as rotation+scrolling.

I think layer rotation does one interesting thing that is: rotating groups of objects. But here are the limitations I know :

- you can't yet set a center of rotation

- as you said you can't easily position a layer (where would be the origin?)

- there are some annoying issues with collision (don't know if it's just with physics or all kind of collision)

- when you group objects under the same layer you can't finely tweak zOrder regarding object outside this group

And basically, to rotate a group of object, I would just use the same sprite to represent them and do a:

Global Variable PivotX = what you want
Global Variable PivotY = what you want
Object: set X to PivotX + cos(angleOfRotation)*distance(Object.X,Object.Y,PivotX,PivotY)
Object: set Y to PivotY + sin(angleOfRotation)*distance(Object.X,Object;Y,PivotX,PivotY)

keepee

sqiddster

Actually it's pretty much the same thing. There's exactlly the same control and I suspect that "apply force at angle" does exactly what I did with apply force.

So no benefit, just showing off some sinus and cosinus to scare our dear n00bs.

I honsetly don't know. I have to admit that I don't really know how fullscreen modes are calculated, by providing a capx in my last post I thought I found out, but it seems that there still was issue when kyat tested it.

So you can try your chance in a bug reporte or we could directly ask Ashley here about this

A while ago I answered a similar question

http://www.scirra.com/forum/how-to-spawn-a-random-object-from-a-set_topic47744.html

hmmm.. I'm not in my big pc, on my laptop things are always a bit slow. But I can't see what you call "jittery".

Can you discribe it a bit more?

I checked for the basics like pivot points and stuff like that and things seem finely done.

But as I said I might have missed 'cause of sh*tty laptop (: