1) The whole HTML5-browser engine that always have some kind of jerkiness in movement, no matter how simple a scene is. It just isn't smooth, there are many topics about this and I'm not very optimistic about it. Unfortunatly, there is nothing you can do about it.

Ah, that's discouraging. Though it matches my experience with my other projects.

2) In your events, don't just subtract 256 from the Y, instead use this: Set Y to self.Y - 256. Most of the time, the TB isn't exactly >=0, depending on the scrolling speed it might be many pixels ahead on the tick that fill this condition. So, if it's lets say Y=10 and you subtract -256 you won't get Y=-256 but Y=-246 hence a visual "jump". If you use the self.Y-256 however, you ensure that the subtraction compensate for the TBs current Y value and there won't be any discontinuations in the movement.

Ah ha! Of course. That was exactly it. Now it's smooth as silk on my PC. Still choppy on mobile, but that can perhaps be addressed.

Thank you very much!

Interesting. I can't say for sure, but it's possible that the bullet behavior is interacting unfavorably with the reset point.

I think, instead of the bullet behavior, you could try some combination of System -> Every X Seconds and TiledBackground -> Move Y pixels at angle 90. The larger X is the better, in terms of CPU utilization, but your results may vary.

Thanks for the suggestion! Unfortunately, doing it in that manner ties the scroll to the frame rate. Which means if the rate drops the game will "slow down" without compensating for the drop. The change needs to be multiplied by the "delta time" (dt), which is the elapsed time since the last tick. That gives a smooth game time regardless of the frame rate. (And what the Bullet behavior is doing behind the scenes.)

bullet behavior is not for scrolling a background!

Actually, it is. It's the officially recommended method in the samples included with C2. Also, behind the scenes all the Bullet behavior is doing is exactly what that video describes. Bullet just puts a friendlier face on it.

Well, Delete the Bullet and the scorll to behavior from the Tiled Background,and if you want to make the camera scroll to the tiled background, add the scroll to behavior.

I'm wanting to make an "infinite runner" type of game, which doesn't work well with the Scroll To behavior. With it, to "loop" would require repositioning every sprite relative to the background. It is much simpler to reposition the background relative to the sprites. But thanks for the thought!

I'm using a 256x256 graphic in a Tiled Background on a 720x1280 game. It has a Bullet behavior to make it scroll down, and a check to reset its position to make the illusion of an infinite scroll.

It's as simple as can be, but it's choppy even on my PC, not to mention mobile. On the PC, it's smooth for the first few seconds, but then the chop settles in. On mobile, it's choppy right from the start.

The frame rate is great (60 on PC, 55-60 on mobile), CPU use is minimal, and WebGL is active on both. I can't think of any reason that it's not smooth as silk.

I've played with all the graphic project options (sampling, scaling, etc), but none of them has any effect. It's still chop, chop, chop.

An example is attached. Does anyone have any idea what's going on?

Thanks!

I'm trying to make a simple AI for a sprite. I just want to have it move a particular distance in a straight line. (Which could also be specified as moving to a particular location.)

I've tried an 8 Direction behavior and the "simulate control" action, but it seems much too limited. For example, I'd need to be able to tell it when to start moving and when to stop moving. But the "simulate control" only seems to work when associated with a continuous input, such as a "is touching object" condition. I can't find any way to tell it to simply start moving and then keep moving until it reaches a particular destination.

I've also tried using a Pathfinding behavior, but it seems to have the opposite problem. It's far more complicated than I need. The requirement to start a path calculation in one place and then pick up the completion event in another is a bit convoluted. All I need it to do is move in a straight line.

I've also tried using the Bullet behavior, and I can get it to start moving just fine. But I can't figure out how to get it to stop. More specifically, I can't figure out how to monitor its position to tell it when to stop. A "while" loop executes immediately and goes infinite because it never gives the sprite a chance to move.

I'm guessing there must be a simple way to do such a simple thing, but I've been at it for hours and I just can't sort it out. Any help would be greatly appreciated.

Thanks!

And 0.53, with some bug fixes.

Meet 0.5, which tweaks the debug Tweened and State to use their text equivalents.

If you are moving from point A to point B and you pause in the middle - You actually did not reach the end of your tween. If you press start again you will continue previous motion until you reach the end. In this case "Start tween" works like a "Resume current tween".

While stopping the tween will mark your current position as the end position. Pressing Start should not do anything until you set new target.

Don't know... maybe I'm overthinking this.

And one more expression could be useful - "Current time". To return how many time, in seconds have passed from start of the tween. For example if your tween duration is set to 7 seconds. It will return value between 0 (start of the tween) and 7 (end of tween)

This could be a nice addition to stack things up. Or do something else at very specific time of the tween.

Sorry for all this requests (moaning about) but this plugin is so nice and so simple to use. I've been using it for last few days and it saves me already a lot of time.

No need to apologize. It's good to have feedback and I'm glad you're already finding it useful.

On both of these points, it's starting to get outside of how I intended the tweens to work. However, I think you could approximate both by using existing functionality. For your "stop" action, you could pause the tween and then re-configure it to the new values. For the "current time", you could chain multiple tweens with the on end conditions. (I might consider mid-tween conditions at some point, but it would be a bit complicated to implement.)

One note of caution on making use of Twixt in its "in progress" state: things could break at any time! (Or, indeed, already be broken.) I don't recommend it yet for production use. But if you do, be sure to back up before you install a new version! Hopefully I'll have it hammered out enough for a 1.0 release in a few weeks.

Thanks!

and like always some requests

1. Action to stop tween (You can start, reset, reverse and pause only)

2. Debugger State value. I really like what you did in debugger, showing all available values is powerful. But for better visual sake could State show names instead of numbers? Like Start instead of 1, or Pause for 2

Good suggestion on State in debugger. I'll do the same for Tweened, as well.

What do you mean by a stop action? How would it differ from pause?

Do you get this.inst in on create function? It has not been created at that monument yet.

I've tried it several places, all outside of on create.

To reproduce:

• Copy a blank behavior from the SDK.
• In the sample action, add console.log(this.inst.inst);.
• Create a new project with a sprite with the behavior.
• Add a on touched object to call the sample action.
• Run the project, open the output console, and touch/click the sprite.
• Output is "undefined".

It seems like this might be a bug!

I just posted 0.4, which adds a "Scale" property to tween (see the docs for details).

Enjoy.