Here you go - your BG moving at the same speed you had it moving at but using interpolate** (your linear velocity 5 - translates to into: move 1 pixel every 0.2 seconds).
This uses only two extra copies of the same actor, each one progressively slightly delayed in their motion (all 3 including the original at 33.333& opacity) . . . which hopefully you can see helps smooth out the motion - and shouldn't be much of a strain on GS.
** (note on interpolate in above post): as I am using an 'every' timer to move the actor/s to the right by a pixel every XXX amount of time (XXX = the amount of time it takes for your actor to move 1 pixel divided by how many layers you want to use) - you can probably use a change attribute instead - not sure what difference this would make or if there is any advantage or disadvantage, not really had a chance to think about that one . . . . not sure I understood what was going on with the 'replicate' image thing either, might take a look at the whole thing a bit closer when I get the chance . . . (I am packing up for a flat move !! Boxes, boxes, need more boxes !!)
If you are still concerned that having extra images smoothing out the motion might be a bit heavy on your project then I'd be tempted to optimize your files, for example your BG can be reduced to just these 2 tiny elements:
1) The skyline as an 8bit greyscale image, so when optimising (ie: in ImageAlpha) you will only need a few colours - making it much smaller - you don't need the sky above the very highest pixel of the highest building nor do you need the black below.
2) Your gradient can literally be 1 pixel wide and set to tile under Graphics / Horizontal wrap. (The gradient needn't move either).
This alone makes your BG file size 6 times smaller without any loss in quality.
Sorry if some of this is obvious (if you let me I will tell you how to open a folder on your desktop and brush your teeth* - lol !!) mostly just thinking out loud as I type.
Hey Tynan, I can't thank you enough. This will definitely be useful for my parallax, thanks for showing me how to apply the stop and start to interpolate as well.
As for the optimizations you suggested. You basically turned the art into my initial idea. However there are specific reasons that I went with the city and sky as a whole image. I initially came up with the idea that I would save some space by making a bunch of different sky using the thin lined gradient as you have done. The problem with that is that once you view it on a device you can see visually distracting lines separating the gradient's colors as you can see in this post: http://forums.gamesalad.com/discussion/33011/gradients
The cure for this is applying noise to the gradient to make gamesalad render it properly. As you can guess, noise does not apply well on a two pixel wide image.
As for the cityscape being in its own image with transparency. It was causing my rotating actors to "lag" or "jitter." From my personal experience, too many large transparent images contribute to this issue. Thus having the single large image may have used a little more space, but I have gained performance and visual fidelity in return.
"thanks for showing me how to apply the stop and start to interpolate as well"
I didn't ! It's your button and coding that starts and stops everything.
"visually distracting lines separating the gradient's colors as you can see in this post"
Bit depth issues are exactly the same issues you were having with movement - what to do when a pixel wants to move from A to B smoothly over 10 seconds - as there are no letters between A and B our pixel must wait at A for5 seconds and then instantaneously jump to B - result = choppy movement . . . same thing with colour banding what to do when your gradient wants to go from shade 244 to 245 over ten pixels - as there is no shade 244 and a half our gradient must stay on 244 for 5 pixels and then instantaneously jump to 245 - result = banding.
"As you can guess, noise does not apply well on a two pixel wide image"
Yep, you would end up with lots of horizontal stripes, but noise will work absolutely fine on a 20-30 pixel wide image !
"too many large transparent images contribute to this issue"
No need to use transparency, make the image black and white (black city / white background) and then in Gamesalad change its blending mode to multiply.
Tynan, you are a genius. I totally forgot I could use blending modes in GS. Back to the drawing board for me! I will also have to give the gradients another go. It's so helpful to have another set of eyes on a project, it's like I get tunnel vision.
Well I have looked into the project and tried to change a few things, but without any luck. Can you explain how you came up with these numbers? I am trying to adapt this to other objects moving at different speeds. you said (linear velocity 5 - translates to into: move 1 pixel every 0.2 seconds)
So I changed the (self.position.X+1) to (self.position.X+2) thinking this would double the amount of space it travels in 0.2 seconds. I did but it becomes jumpy again. I also tried changing it to move one pixel every 0.1 seconds which didn't work either. I'm presuming I have to change the 'After' number, I tried a few things but I don't understand how you arrived at the number you did for each actor.
This is probably really simple to change and I am just not seeing it.
"Can you explain how you came up with these numbers?"
The quick answer is this:
Change all three 'Timers' to 0.1 (instead of 0.2). In the 'after' part of layers 2 and 3 change the time to 0.0333 (for layer 2) and 0.0666 (for layer 3).
"This is probably really simple to change and I am just not seeing it."
Super simple, give me a moment . . . let me make you a drawing so you better understand, I suspect two pages of numerical ramblings might not be helping make this concept very clear, it's incredibly simple, I'm sure once you have got it locked in your head you can very quickly apply it to anything you want, the maths part is trivial, I suspect you are getting stuck on the concept itself (?)
@Tynan: Thanks mate, it worked. At least I know which values to play with now to get whatever speed I desire. So the first layer's 'after' value is always left as-is?
@Rob2: Awesome discovery, I'm going to try a few variations with this tonight. Thank you!
Edit: @Rob2: Adding a single line of transparency fixes all of my banding issues. Great tip!
We have a 4 pixel x 1 pixel white block moving left to right - one pixel at a time.
1) The white block 'Normal GS' (NGS) is what GS does normally, moving pixel to pixel. 2) The 3 'AA' layers are 3 copies of the white block set to 33.3% opacity - each subsequent layer being delayed by 1/3 of the time it takes 'NGS' to move 1 pixel. 3) The final result (the 3 AA layers combined) It might not look like much but when shrunk back down to pixel size this is what removes the choppiness on even high end CG stuff like Toy Story.
Stick the video on 'loop' and keep staring at it for at least 34 minutes (beer will help, wine works too) at around 28-31 minutes the whole concept of how movement can be smoothed out using anti-aliasing should suddenly become obvious.
@Tynan: I am still having issues with my images getting farther and farther apart over time. Can you please tell me what I didn't change properly in these scenes? It happens in project two slowly, but is much more evident in the third. http://www.mediafire.com/?fbi2l9gw1egon3c
@Graybay "I am still having issues with my images getting farther and farther apart over time. Can you please tell me what I didn't change properly in these scenes?"
Weird !? Not sure quite what would be causing that, we are after all simply moving 3 objects left to right . . . . . . . ?
Hmmmmm . . . . . I will take a look later when get a chance.
"Any chance you've had time to look at the numbers yet Tynan? "
Took a look, can't work it out at all, like I said all we are doing is moving 3 objects left to right, but with a timer offsetting them. Maybe GS struggles to keep very fast time spans (when using the timer) in sync ? Possibly a bug ?
You can achieve anti-aliasing (and thus smooth motion at low speeds) by doing this . . . . (the advantage is it only uses two images, so might be easier on GS ?)
Two images, the first image fades down to nothing, while the second image fades up from nothing, the second image is offset by 1 pixel to the right, once it is fully faded up, it starts to fade down - and the first image starts to fade up . . . but now 1 pixel to the right of the second image . . . etc etc
A .B ..A ...B ....A .....B
This is will give you a very smooth L > R motion with just two images, might get around the glitchy timers ???
Comments
Hold on . . . . . let me check it out . . .
This uses only two extra copies of the same actor, each one progressively slightly delayed in their motion (all 3 including the original at 33.333& opacity) . . . which hopefully you can see helps smooth out the motion - and shouldn't be much of a strain on GS.
Link: http://www.mediafire.com/?plzvamaq6wcm9ou
Hope that makes some sense or is some help / clue . . . . pull it apart to see what is going on, it's very simple . . . . .
(continued) . . .
(continued . . . )
1) The skyline as an 8bit greyscale image, so when optimising (ie: in ImageAlpha) you will only need a few colours - making it much smaller - you don't need the sky above the very highest pixel of the highest building nor do you need the black below.
2) Your gradient can literally be 1 pixel wide and set to tile under Graphics / Horizontal wrap. (The gradient needn't move either).
This alone makes your BG file size 6 times smaller without any loss in quality.
Here's a quick optimization example: http://www.mediafire.com/?g8uae482onexezi
Sorry if some of this is obvious (if you let me I will tell you how to open a folder on your desktop and brush your teeth* - lol !!) mostly just thinking out loud as I type.
As for the optimizations you suggested. You basically turned the art into my initial idea. However there are specific reasons that I went with the city and sky as a whole image. I initially came up with the idea that I would save some space by making a bunch of different sky using the thin lined gradient as you have done. The problem with that is that once you view it on a device you can see visually distracting lines separating the gradient's colors as you can see in this post: http://forums.gamesalad.com/discussion/33011/gradients
The cure for this is applying noise to the gradient to make gamesalad render it properly. As you can guess, noise does not apply well on a two pixel wide image.
As for the cityscape being in its own image with transparency. It was causing my rotating actors to "lag" or "jitter." From my personal experience, too many large transparent images contribute to this issue. Thus having the single large image may have used a little more space, but I have gained performance and visual fidelity in return.
"thanks for showing me how to apply the stop and start to interpolate as well"
I didn't ! It's your button and coding that starts and stops everything.
"visually distracting lines separating the gradient's colors as you can see in this post"
Bit depth issues are exactly the same issues you were having with movement - what to do when a pixel wants to move from A to B smoothly over 10 seconds - as there are no letters between A and B our pixel must wait at A for5 seconds and then instantaneously jump to B - result = choppy movement . . . same thing with colour banding what to do when your gradient wants to go from shade 244 to 245 over ten pixels - as there is no shade 244 and a half our gradient must stay on 244 for 5 pixels and then instantaneously jump to 245 - result = banding.
Yep, you would end up with lots of horizontal stripes, but noise will work absolutely fine on a 20-30 pixel wide image !
"too many large transparent images contribute to this issue"
No need to use transparency, make the image black and white (black city / white background) and then in Gamesalad change its blending mode to multiply.
So I changed the (self.position.X+1) to (self.position.X+2) thinking this would double the amount of space it travels in 0.2 seconds. I did but it becomes jumpy again. I also tried changing it to move one pixel every 0.1 seconds which didn't work either. I'm presuming I have to change the 'After' number, I tried a few things but I don't understand how you arrived at the number you did for each actor.
This is probably really simple to change and I am just not seeing it.
Hope your move is going well.
"Can you explain how you came up with these numbers?"
The quick answer is this:
Change all three 'Timers' to 0.1 (instead of 0.2).
In the 'after' part of layers 2 and 3 change the time to 0.0333 (for layer 2) and 0.0666 (for layer 3).
"This is probably really simple to change and I am just not seeing it."
Super simple, give me a moment . . . let me make you a drawing so you better understand, I suspect two pages of numerical ramblings might not be helping make this concept very clear, it's incredibly simple, I'm sure once you have got it locked in your head you can very quickly apply it to anything you want, the maths part is trivial, I suspect you are getting stuck on the concept itself (?)
"Hope your move is going well."
8-X
@Rob2: Awesome discovery, I'm going to try a few variations with this tonight. Thank you!
Edit: @Rob2: Adding a single line of transparency fixes all of my banding issues. Great tip!
". . . always left as-is?"
I've made a simple explanation video, watch it and hopefully you can see the process in action (+ why layer 1 needn't be delayed)
QT movie: http://www.mediafire.com/?81h9l6ev7ncs9js
We have a 4 pixel x 1 pixel white block moving left to right - one pixel at a time.
1) The white block 'Normal GS' (NGS) is what GS does normally, moving pixel to pixel.
2) The 3 'AA' layers are 3 copies of the white block set to 33.3% opacity - each subsequent layer being delayed by 1/3 of the time it takes 'NGS' to move 1 pixel.
3) The final result (the 3 AA layers combined) It might not look like much but when shrunk back down to pixel size this is what removes the choppiness on even high end CG stuff like Toy Story.
Stick the video on 'loop' and keep staring at it for at least 34 minutes (beer will help, wine works too) at around 28-31 minutes the whole concept of how movement can be smoothed out using anti-aliasing should suddenly become obvious.
Brilliant stuff ! Super useful !! : )
"Adding a single line of transparency fixes all of my banding issues. Great tip!"
Time to go back to the single pixel wide gradient !! : )
(with a transparent pixel at the top or bottom)
"I am still having issues with my images getting farther and farther apart over time. Can you please tell me what I didn't change properly in these scenes?"
Weird !? Not sure quite what would be causing that, we are after all simply moving 3 objects left to right . . . . . . . ?
Hmmmmm . . . . . I will take a look later when get a chance.
Took a look, can't work it out at all, like I said all we are doing is moving 3 objects left to right, but with a timer offsetting them. Maybe GS struggles to keep very fast time spans (when using the timer) in sync ? Possibly a bug ?
You can achieve anti-aliasing (and thus smooth motion at low speeds) by doing this . . . . (the advantage is it only uses two images, so might be easier on GS ?)
Two images, the first image fades down to nothing, while the second image fades up from nothing, the second image is offset by 1 pixel to the right, once it is fully faded up, it starts to fade down - and the first image starts to fade up . . . but now 1 pixel to the right of the second image . . . etc etc
A
.B
..A
...B
....A
.....B
This is will give you a very smooth L > R motion with just two images, might get around the glitchy timers ???