Linear velocity choppiness
I'm trying to do parallax scrolling, any layer that I require to move slowly begins to get choppy like crazy. If I don't set the velocity higher than 15 or so this always occurs. Is GameSalad unable to render slow speeds properly or am I missing something important?
Thanks!
Thanks!
Comments
Do you have an example file you can upload - I may have an answer for you . . . . . . .?
http://forums.gamesalad.com/discussion/37792/move-an-actor-slow-and-smooth#Item_9
@Tynan: Thanks, I understand why details would be very important in most cases. However this problem is so simple to recreate that it would take longer for me to upload a scene and have you download it, than to just re-create the problem from scratch as I explained. Sorry if I sounded a little abrupt.
"Sorry if I sounded a little abrupt"
No, not at all ! No problem, I just didn't know if you were using a light grey 400 x 400 actor with no image, a tiny picture of a cat with an alpha channel or a 100 x 100 anti-aliased (in Photoshop) circle, believe it or not it makes a difference (GS's anti-aliasing is a little temperamental). Depending on the actor the solution may well differ as any solution would be a workaround based on the actor.
Gamedivision basically hit the nail on the head (in a roundabout way) when he says (in his other thread): "[it's] like its not using decimal numbers to move more like hole numbers".
What is happening is that Gamesalad has no internal anti-aliasing (even the anti-aliasing on fonts looks to be a kind of effect rather than real AA) - so when an object is flying around the screen it all looks fine, but when an object is slow enough you notice the following . . . .
(continued)
. . . ( for this thought experiment let's imagine a 1x1 pixel actor that is moving right (it's X position number is increasing over time))
Ok, we put our actor at 100 X 100 Y.
His speed is sufficient to move him to 105 X 100 Y over 10 seconds (ie: really really slow!)
Now as our actors position must be quantized to the nearest pixel his journey will do this:
He will sit motionless at 100 x 100 for 2 seconds.
The he will jump instantaneously to 101 x 100.
He will sit motionless at 101 x 100 for 2 seconds.
The he will jump instantaneously to 102 x 100.
He will sit motionless at 102 x 100 for 2 seconds.
The he will jump instantaneously to 103 x 100.
He will sit motionless at 103 x 100 for 2 seconds.
The he will jump instantaneously to 104 x 100.
He will sit motionless at 104 x 100 for 2 seconds.
The he will jump instantaneously to 105 x 100.
So he has made his five pixel journey in 10 seconds like you asked him to do.
(continued)
. . . but he has to sit motionless between moves as there is no such thing as a "half pixel") at 100.5 pixels across for him to land on after 1 second.
We perceive this as jerky motion, if it were to move faster we wouldn't notice the issue, go slower and you will simply see it as an object jumping between positions (ie: you would lose the perception of motion) - but there is a speed range where it is too fast to be seen as a 'jumping object' and too slow to be seen as smooth motion.
TheStutterZone™
If GS had anti-aliasing (like AfterEffects or Photoshop, or any modern application that deals with sub-pixel events) the in-between pixels would be simulated with shades of grey on adjacent pixels, so a 100% white pixel that want to sit halfway between pixel 448 and 449 would be simulated by 50% grey on pixel 448 and 50% grey on pixel 449 - so you wouldn't see the 'jump'
(continued)
I know this is super zoomed in so a little out of context, but the orange pixel on the left will move very smoothly across the screen - while the pixel on the right will appear to jump from pixel to pixel.
I've moved the pixel on the left towards the next pixel position on the right in 4 moves - but obviously if it were going slower the values rise slower.
So - 100+0 . . . 95+5 . . .90+10 . . . 85+15 . . . 80+20 . . . etc
This is not just a issue with motion, but any situation where a value is ideally in a sub-pixel location but can only be rendered to the nearest whole pixel, anti-aliasing on text is the most obvious example of a non-motion use of anti-aliasing.
(continued)
The problem with jerky motion when moving at slow speeds is Gamesalad's lack of anti-aliasing.
The solution, if you've read this far, should be obvious enough, we know what anti-aliasing is doing, we know you can have layers in Gamesalad and we know we can animate the opacity (or position over time) for each of these layers individually . . . . so if you really want smooth and slow motion and are prepared to work out some simple maths . . . . then you can certainly have slow and smooth motion of the quality you'd get in high-end compositing applications like After Effects.
Taken further you could even generate motion blur based on an actors speed . . . .
Thanks again Tynan!
Edit: I don't have a clue how to apply this to movement. I tried a few things but I don't think I was even in the right ballpark. Do you have any good links to learning resources and info about aa?
"Edit: I don't have a clue how to apply this to movement"
Lol, and you sounded so confident at the start of your post ! : )
It's one of those things that is - in reality - really really simple but sounds complex.
Let me see if I can knock up a Gamesalad example for you . . . . . .
Link (Gamesalad project): http://www.mediafire.com/?h3vf9ijigk0j4xj
Hit 'Preview' on this file . . . two boxes moving very very slowly - both at precisely the same speed - the top box has been anti-aliased - the lower box is just a normal move.
Watch the boxes individually by clicking the big pink bar.
Watch them both at the same time by clicking the orange bar (it moves the pink bar out of the way).
Also try dragging the white boxes closer (in the Y axis) to compare them to each other .
(continued) . . . .
This is a quick experiment, you can make it much smoother if you want - I used 5 steps (20% increments) you can use up to 256 steps so the move could be up to 51 times smoother, but 5 seems fine (even at this slow speed)
My animation stops after 64 seconds ! : ) (whoops)
You will probably stare much more closely at the movement than normally, don't ! Motion graphics are never perfectly smooth, even top end stuff. They all have to deal with this issue.
Even 'pro' compositing software will struggle with slow moves like this, they haven't got any kind of magic smoothing that Gamesalad hasn't got, it's all just pixels changing colour.
And the reason it's best to watch the boxes separately is that an optical effect occurs whereby something with smooth motion can appear juddery / choppy when seen in close proximity to something that actually has juddery / choppy motion.
The smoothing effect anti-alsiasing has on motion doesn't just apply to the hard edges of a white box, everything will move more smoothly, even the centre part of a photograph, it's just that we notice the edges (or any area of high contrast) much more.
RThurman
"That's a great little demo. Nice work! Thanks for taking the time to show how to do this."
Cheers !
One more thought - if you are concerned about memory use (5 (layered) images where previously you had only one) there are further tricks you can do to even mitigate this, so in that respect . . rather than being a hypothetical application of a kind of faux-AA to illustrate what was causing the choppy motion issue . . I think this method is actually very useable in certain situations.
you are a legend and a scholar
: )
What's great is that there is no AA on the cover type.
[has publisher whacked].
"Right now it's a little too heavy for my project"
It really shouldn't be, as I was saying earlier there are ways to mitigate any extra strain on your project of having a few extra images in a scene, which is also why I wanted to know what is going on in your scene (so you can tailor this to your particular project).
For example in our white square example - all you really need is two 1 pixel wide strips the height of the cube - moving just ahead of it to remove the choppiness, which is not going be taxing for GS.
Also I bet you could achieve 70% of the perceived extra smoothness with a single extra image and very slightly speeding the movement up (my example is going very very slow).
Anyhow, I am pretty sure you can do this without particularly taxing GS.
do you think its possible to add 2 pixels of transparency around an image in photoshop instead of creating 2 actors in GS
"do you think its possible to add 2 pixels of transparency around an image in photoshop instead of creating 2 actors in GS"
It won't help, you are effectively just moving the edge of the image inwards by 2 pixels - this new edge will still be subject to the same issues.
(Although putting transparency around an image does get rid of Gamesalad's issue with poorly anti-aliased edges on rotated actors.)
I think - depending on your scene - there are a whole bunch of little tricks that would help, putting a slight directional blur on just the edges of the moving actor in Phototshop (the directional blur aligned to the direction of motion in GS) and having a 2nd actor at 50% transparency just ahead of the main actor - and speeding the motion up by just a little bit makes an enormous difference.
(I am say that as I have just tried all that)
Not sure, may have to be converted to interpolate or change attribute (but shouldn't be a problem).
http://www.mediafire.com/?uwom91v64b9yw56