I'm not really familiar with the game, but do you mean something like this?

Like this?

I'm not sure what the problem is..

Let's say you are using animationframes..

If the animationframe of the sprite in the left corner is the same as the animationframe of the sprite the ball collides with everything is good, else the ball dies..

After that you set the animationframe of the sprite in the corner to choose(0,1,2)

Seems like you are almost there..

You could now add a "is not within angle" condition..

then add an else event and set the exact angle..

As stated before, what you'd need is an event "if within a certain distance of the destinationnode rotate towards the position of detinationnode+1"

When shooting left you'd need 179, 180 and 181 degrees for the bullets?

Seems like you need "for each"

> You should remove the action set animation to idle in event 1, because it conflicts with your other events..

>

Every tick - set to idle ?

I think that is good becouse if the player is not mooving it is going to stay on IDLE so that is not a problem

You might think it is good, but it's not..

The event is conflicting with every other event setting animations, because it is performed every tick without any conditions, but if you don't want the answer to your question, that's fine with me..

I'll try this when I get home tonight and let you know.

Just for future reference I want to make sure I am reading what you are telling me correctly.

"--" = Sub-event

">" = Action

" " = Condition

Is that correct?

Once again, thanks a ton LittleStain!

That's the way I write it, yes..

You could also use choose instead of random:

For animations

sprite set animation to : choose("animation1","animation2") etcetera

For spawning at imagepoints

sprite spawn object on layer at imagepoint choose(0,1,2,3,4,5)

You should remove the action set animation to idle in event 1, because it conflicts with your other events..

Must be my question being confusing. I was asking about which is better for performance, resizing the Image of the TiledBackground smaller or resizing the Tiledbackground smaller itself? The other questions were just addons...

Are you having performance issues?

If so, resizing the tiledbackground (in game) itself won't have a noticable effect, because the amount of image memory used for it will remain the same..

Reducing the amount of pixels of the image, would..

>

> >

> > So the (Ingame sprite or tiledbackground) size or instance count doesn't lower performance (cpu or ram) is that what you mean only the ImageFile?

> >

>

> Not the file, just the image..

> The size in the game effects the drawing, not the (image-)memory it occupies..

>

I am beginning to think I don't really understand the optimization guide of Ashley now. So performance is only based on what is seen on the screen. Thanks i'll keep that in mind. But why do we need to turn off the Collisions outside the screen view according to some guides ? And why do we need to maintain object count if we can just scatter many objects that will not be seen together in the screen view?

You don't understand what I am saying, or I don't understand your question..

You were asking if it would be wise to make your image smaller and my answer was that it wouldn't matter that much, because it only take 615x194x4 bytes in memory..

Collisions have nothing to do with the image, amount of objects have nothing to do with the image..

So I don't know where these suddenly come from..

Cpu is something different from gpu..

I was talking about image memory usage..