Make an infinite scrolling background of an Uneven image

Like in the Autorunner Template, there is the event :

Condition:

X <= - Self.Width / 2

Action:

Set X : Self.X + Self.Width / 2

But this only apply to images with the same width of their layout. Can anyone give an event for images not equal to the width of their layout? Thanks in advance XD

Could you share your capx to clarify your question?

For the above event to work, the image doen't have to be the same width as the layout..

It has to be at least as wide as the layout and repeated two times, because it only moves half it's width every time..

Could you share your capx to clarify your question?

For the above event to work, the image doen't have to be the same width as the layout..

It has to be at least as wide as the layout and repeated two times, because it only moves half it's width every time..

Yeah that's true, but I already tried resizing the background by x2 or changing Self.Width / 2 with /1.909 or something that'll fit the size of the image and still something wrong..

I'll post the .capx in just a minute..

Could you share your capx to clarify your question?

For the above event to work, the image doen't have to be the same width as the layout..

It has to be at least as wide as the layout and repeated two times, because it only moves half it's width every time..

Here is the .capx file XD Hope you find the problem and do explain.

https://onedrive.live.com/redir?resid=A ... ile%2ccapx

> Could you share your capx to clarify your question?

>

> For the above event to work, the image doen't have to be the same width as the layout..

> It has to be at least as wide as the layout and repeated two times, because it only moves half it's width every time..

>

Yeah that's true, already tried to resizing the background by x2 or changing Self.Width / 2 with /1.909 or something that'll fit the size of the image..

I'll post the .capx in just a minute..

ehhmm..

I don't understand what you mean with 1.909..

self.width is the width of your object, so why would you have to change anything?

You'd still want to move the object half of it's width, right?

Waiting for the capx..

It will work if you set the width of your background to 3690px

To get the background to be at least the width of your project, it needs to be 3x615px(it's original image size)..

To make this code work, it has to be twice as wide, so 3690px

It will work if you set the width of your background to 3690px

To get the background to be at least the width of your project, it needs to be 3x615px(it's original image size)..

To make this code work, it has to be twice as wide, so 3690px

Wow! Great Thanks, Just another question. Does making your tiledbackground larger lowers the performance? Which is better? to resize my imagefile(the image of the tile) so that it can maintain 2560px or just leave the tiledbackground size to 3960px?

> It will work if you set the width of your background to 3690px

>

> To get the background to be at least the width of your project, it needs to be 3x615px(it's original image size)..

> To make this code work, it has to be twice as wide, so 3690px

>

Wow! Great Thanks, Just another question. Does making your tiledbackground larger lowers the performance? Which is better? to resize my imagefile(the image of the tile) so that it can maintain 2560px or just leave the tiledbackground size to 3960px?

Your image is 615x194..

That is the image size in memory..

>

> > It will work if you set the width of your background to 3690px

> >

> > To get the background to be at least the width of your project, it needs to be 3x615px(it's original image size)..

> > To make this code work, it has to be twice as wide, so 3690px

> >

>

> Wow! Great Thanks, Just another question. Does making your tiledbackground larger lowers the performance? Which is better? to resize my imagefile(the image of the tile) so that it can maintain 2560px or just leave the tiledbackground size to 3960px?

>

Your image is 615x194..

That is the image size in memory..

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?

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..

>

> 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?

>

> >

> > 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..

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..

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...

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..

>

> 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..

Actually I am trying to avoid it, and luckily no. I am just making sure for I am trying to make a mobile game and don't want it to be sluggish unlike the last time.