Some strange behavior with DJFuegos custom sine movement

[Storsorgen]

Greetings!

I've implemented the custom sine movement that DJ Fuego supplied in this thread http://community.clickteam.com/threads/54175-Custome-sine-movement

I've applied this to a platform that moves vertically, and I've encountered a strange behavior.

My game runs in fullscreen, resolution 480x270. I'm only changing the Y position of the platform.

The formula for moving the platform is
Set Y position of verticalPlatform to

initalY( "verticalPlatform" ) + 30 * Cos(2) * yTimer( "verticalPlatform" )) * 3.14

This is done in a fastloop, and in the same fastloop, yTimer is increased by 1.
This results in what appears to be a smooth sine movement up and down, but the problems arise when I stand on the platform and it makes the screen scroll up or down.
It results in a perceived feeling of the platform "stuttering" as it nears the turning point of its movement. I checked step-by-step to see if there was any actual stuttering going on, like it going up and down in a millisecond or so, but I could spot no such thing. Any idea why this is? Is it just an optical illusion?

As I mentioned, this is only noticeable when riding with the platform, not when standing still on the Y axis watching it go by.

[Storsorgen]

Did some testing while changing it to Cos(1), and it appears there are some irregularities with the movement when its approaching the end of the path. Is this due to it calculating decimalpositions, resulting in it moving 1 and then 2 and then 1 again pixels?

Edit: Did further testing, and it seems it's stuttering because it moves 2 pixels one draw, then 1 the next, then 2 pixels again. Any idea how to get around this?

[casleziro]

It's most likely a combination:

1) Always store movements like this that use decimal positions in an alterable value, then set the y position of your object to that value. Instead of:

Set Y position of verticalPlatform to initalY( "verticalPlatform" ) + 30 * Cos(2) * yTimer( "verticalPlatform" )) * 3.14

you do:

Set value "ypos" or something similar of verticalPlatform to initalY( "verticalPlatform" ) + 30 * Cos(2) * yTimer( "verticalPlatform" )) * 3.14
Set Y position of verticalPlatform to Round(ypos("verticalPlatform"))

If you don't use Round() then your position will be off because of inherent errors with floating point numbers and Fusion. You must store floats in values because XY position events can only accept integers, while alterable values can calculate with floats. If you attempt to do anything with floats using the XY positioning directly then your decimals will be discarded, ruining the expression.


2) This will be the billionth time i've repeated this one (Clickteam really needs a stickied thread with some crucial information like this ): Always make sure that your camera event (that centers the screen) is BELOW any movement events. Putting it at the absolute bottom is the safest. Not doing this will cause stuttering most of the time, since if there is any movement after the camera has centered, the next time it attempts to center it will already be one frame behind and need to catch up, causing a lag. Remember that the event sheet is read from top to bottom.

[Storsorgen]

Thank you immensly casleziro, I will attempt this and see how it goes

[Storsorgen]

So I tried this now, and sadly it's exactly the same. The camera events are at the very bottom, and I'm using the set y position to Round(ypos) but the stuttering is no different. Did I forget something else?

[schrodinger]

Could you provide a small example showing the issue?
(just platform + player + scrolling)

Sometimes things get fixed in the process of "reducing" to smallest issue
or else, others may take a look at what may be going wrong

(a possible workaround regardless of the issue: you can have a separate "camera" always moving towards the player,
you can make its speed constant to avoid any possible stutter)

[Storsorgen]

verticalPlatTest.mfa

Here is an example!

To notice the stuttering, pause the game and go frame by frame in the debug. Note that the speed varies between 3 pixels per step, 2 pixels per step, 3 pixels per step.

[Storsorgen]

The stuttering is not caused by the camera from what I can see, but from the varying amount of pixels moved by the platform.

[schrodinger]

mmm I see what you mean
but I think there's no escape from this
as long as you want "sub-pixel" movements

cos(or sin) can range from -1 to 1 and all floats inbetween
thus your movements can be cos(xx)*(anynumber)
since you gradually increase (xx)
rounding this will abruptly result in "number" or "number +/-1"

and so resulting movement will be 0 or 1
(magnified to 2 or 3 or more)
this will determine if the platform should move to next pixel or not

I think if you want no jumps at all you should always add or subtract one whole pixel at least
and only increase or decrease after you "shift" movement direction, until you shift direction again

or, as suggested above, use an external camera and "smoothen" its movement independently from player position

but I don't think this is a problem for many people..?

[Storsorgen]

Thank you for the help schrodinger, I'll ponder how to proceed