How do I smooth move forward?

As a matter of fact Elios I do have different layers and one of them does have a different parallax value. The sky layer has 50,50 parallax the others have 100,100, I did that tho give the illusion of the sky being far away .

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

eli0s The playerbox object and the character object are on the same layer(a 100,100 parallax layer) and as far as I can tell they don't cross over.

I don't have any residual srollx code or any forgotten scroll to behavior.

I can't check your capx at the moment because I have version 178 and your capx was made with v 180+ so it won't load it. And sorry, but I'm not upgrading to beta versions.

Any other info you need let me know please.

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.

K, I made your capx work eli0s and it seems to work pretty much the same, still has some... I guess micro stutter is what you would call it?

I'm using Waterfox, a 64-bit browser to preview the game, if that matters. And I olso created a new Template: Auto-runner just to test, and that one works fine.

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.

JavaScript's garbage collection (GC) is one cause of stuttering. It's gotten better over time because web browsers are implementing ways so the GC causes shorter stalls. Some are better at this than others.

Another reason is stuff running in the background, the underlining os can be as much of a culprit as other programs. The nes had a lot less variance since only the current game was running.

R0J0hound , thanks for your input!

I know nothing about the garbage collection process (I've read about it as been a problem in general on other topics though), but any word coming from the great R0J0 I' ll take for granted

As for the background processes, I get that windows and all the junk I have installed on my system are taking their toll on my PC, but shouldn't this be as true for other games too? My rig is not in its prime any more, but it can still play most modern 3d titles on high settings, with no stutters or other noticeable frame drops.

To be frank, being as ignorant as I am, I can't help wondering how it is possible for a 3d game engine to calculate and render all those polygons, huge textures, complicated shaders, real time lights/shadows and post effects, and at the same time run smoothly!? Of course there are geniuses behind those engines that optimize everything and squeeze every last redundant bit out of the game, but still, I would expect a 2d engine that doesn't have to deal with most of those things to deliver rock solid results on simple scenes, and I even hopped that its lack of third dimension would give it an edge on what it can display on the other two dimensions.

I fear that this is all about choosing HTML5 as a target platform, although I have no technical knowledge to support it, nor that it really matters, C2 is what it is and does what it does.

Other stuff running in the background have much less of an effect than Garbage collection. Garbage collection is automatic and in javascript you can't control when it happens as far as I know. Ashley has done a lot to keep the amount of garbage made by the engine to a bare minimum according to his blog posts.

I don't really notice the lag, but then again my pc is dog slow with html5 as it is.

I don't really notice the lag, but then again my pc is dog slow with html5 as it is.

So, if I understand you correctly, you don't notice the lag because even if it exists, the performance of html5 in your pc is already bad and you wouldn't be able to distinguished it?

I am curious about these optimizations because I have stuttering issues even using 2 sprites, one for solid objects and one for the player with the platform behavior. I am talking about single frame square sprites.

Some time ago, due to my frustration by this issue, I wanted to make a topic and post a video of this, but when I tried to screen capture the previewing capx, the screen capturing software really messed up the frame rate on the browser. So the issue sifted from the subtle and sporadic stuttering to an inaccurate representation of framerate drops.

In short, I have no tools to document accurately this issue, other than writing in terrible English about it. But it is there and it's too evident for pleasurable experience, at least in tight platforming games, in my opinion.

Sigh, guess I have no choice then but to leave it in and hope that most people that end up playing it won't notice/won't be bothered by it..

Oh well, thank you for trying to help guys.

eli0s

Maybe I've become accustomed to it.

I did a bare basic js test of motion and even then it's not buttery smooth.

http://jsfiddle.net/us1v4sq4/1/

Also added a graph of the frame time to inspect it further

http://jsfiddle.net/us1v4sq4/2/

For me there are some little spikes in the frame time, but it doesn't really correlate to the motion.

Not sure what can be done to improve it. The issue may lie in the web browser itself.

R0J0hound , I tried your javascript tests and I can confirm your results:

Firefox: random spikes and some uncorrelated stuttered movement

Chrome: Almost no spikes and a few occasional jumps in movement

IE 11: no spikes but some stuttering detected.

Those results above reflect my experience with actual C2 projects in the same browsers.

Unfortunately I can't get my self to be accustomed with it. I don't mind this while I test and fool around trying to learn C2, but as a consumer, I would have been very disappointed playing a game that has sporadic jumps&drops in fluent movement. If this is something I have to swallow by accepting html5 as a gaming platform, I find my self agreeing with the camp that had raised the need for other exporting solutions so many times now, it's just not ready yet, it's unprofessional and sloppy to deliver something that has intrinsic flaws like this.

Anyway, the original poster has a solid answer now, thank you again for the input R0J0, it's valuable and constructive to interact with you

I have actually experienced something similar to this on a much smaller scale. I built our basic website using C2 ( currently living at http://50.112.151.9/home ), and I found that when using a time-based solution to having the menu items scroll-up, the speed at which it moves varies based on the machine and browser it is run on. I suspect this particular behavior is due to inconsistent clock timing.

I am not sure if this clock issue is related, but from a physical standpoint, any deviation in timing will result in micro-stutters, as they are described.

I ran that Jsfiddle on my machine also, and I only had 1 or 2 spikes and the rest was very consistent, so that is very likely browser-specific or perhaps even machine-specific.