Sonyika , I am not familiar with the webm format. I am guessing there are software that can convert to this type of file.

A google search with the terms "convert to webm" gave many results, you can try and see if something works for you.

Well, I think zenox98 unintentionally linked an other topic. Here is the page from the manual for the video object https://www.scirra.com/manual/181/video

Here is an example capx. It has the necessary info inside.

onur (super hot has very interesting gameplay!)

Elliott

alvarop

I don't think OP asked about time manipulation.

—, you ask about if there is a way to change the image point on separate frames of a sprite at run time with events and actions? I don't believe there is.

I am interested in seeing your example capx to understand how could this prove to be useful as a gameplay element though.

I guess "micro stutter" is an accurate description and I am afraid there isn't a way around it. This occasional jagged motion is very evident to some people, less noticeable to other (much to my surprise), in any case, it has been described in other topics and there hasn't been a clear explanation for the cause of it, nor for a solution.

For me is extremely evident in platforming projects. I can get my self to get use to it while I am testing but, at the same time, I thing of the Mario brothers game on NES and how smooth its motion was... and that is puzzling me: on a modern platform like C2 these kinds of problems should have been ironed out by now. Yet, I see very few people bothered by this, or even noticing it.

You can unrar the capx file and then use a text editor to change a line in the caprog file.

Change the <saved-with-version>18000</saved-with-version> into <saved-with-version>17800</saved-with-version> and it should work.

I can't think anything else other than what I told you already.

VIKINGS , and you rightfully do so! My point is that if you have an object that C2 takes into account to do the scrolling calculations (either with the "Scroll to behavior", or the "scrollX" action), and you move this object between layers that have different parallax values, then C2 won't know by its self how not to jump around due to the layer's offsets.

In your case, do you move the PlayerBox object between layers that have different parallax values?

Have you checked your other objects for a forgotten "Scroll to behavior"?

Or your code for a redundant "scrollX" action?

And does my example above runs smoothly in your system?

Come on, you have to help us out if you want to help you out

You are welcome

I don't get why you're having problems. The setup you describe is straight forward enough, there shouldn't be any problems. The sprite you are pinning is irrelevant and it shouldn't affect in any way the scrolling of the PlayerBox or the system scrollX action.

Here is an example using both ways, apart from a tiny jump which is probably due to a missing tick between the group activation/deactivation, the scrolling is exactly the same.[attachment=0:3iasqmmm][/attachment:3iasqmmm]

If this plays ok in your system then something else is causing the problem.

Perhaps you have other objects with the Scroll to behavior forgotten somewhere? Or a redundant scrolX action hidden in your code? Maybe the PlayerBox is jumping from layer to layer and those layers have different parallax values?

If it doesn't run smoothly, then it's your system that is having trouble maintain steady frame rates.

SteveKane , you can't avoid using every tick if you want smooth movement. In my example the every tick is included at the first condition, any event that is not a trigger (a trigger is displayed as a green little arrow on the left of the event) it's been calculated on every tick, unless its told otherwise. Even an empty condition is equal as like having the "on every tick" condition.

You could use the "every x seconds" condition to skip ticks and have less calculations, but this will also affect the smoothness of the BGs movement. Here is the same example with the movement at every 0.1 of a second (so it is effectively doing only 1/6 of the original calculations). As you can see, it's like a stop motion, but perhaps I guess that this can actually be aesthetically desired.

This..?

Something like this?

Please note that you might have to find a way to deal with the upside/down and vertical bricks, add Y comparisons to invert the detection that determines the impulse angle...