Large distances causes rendering issues

Link to .capx file (required!):

dl.dropboxusercontent.com/u/2425456/large_distance_problem.capx

Steps to reproduce:

1. Press and hold "W" to accelerate Player very fast using a basic Custom Movement.

Observed result:

When approaching large distances, the sprite and/or camera starts to gradually jerk more and more.

Chrome and Firefox also exhibits rendering issues when rotating the ship at large distances (try stop moving by pressing "b" after reaching a large distance, and then turn the ship around). For some reason, this turning glitch does not happen in IE10, although it has the same problem when moving.

Expected result:

The same smooth movement as seen at lower positions.

Browsers affected:

Chrome: yes

Firefox: yes

Internet Explorer: yes

Operating system & service pack:

Windows 8 Pro 64-bit

Construct 2 version:

Release 139 (64-bit)

I've noticed similar graphical issues using custom movement when moving at lower speeds in larger games.

It's very possible that this isn't easily fixed, however.

Yes, same here. I first noticed it when moving at slower speeds but over large distances.

I've tried with pixel rounding both on and off, and using scrollto behavior as well as custom "scroll to Player each tick". Haven't tried other movement types though.

I could be missing something crucial, but just can't figure out what. It seems to be able to store and display the large numbers fine, so I can't help but believe it should be able to render them as well.

Could it have something to do with floats? I've heard that float variable types can be unreliable in certain circumstances. Could this be one of those?

I think its more like you're telling it to be in more than one place at a time with the keyboard negated events.

Darn you quantum teleportation.

I updated the demo so you can use "x" to instantly set the position to very far away, bypassing the Custom Movement. Still strange distortions I'm afraid.

It really does look like quantum mechanics...

Closing as won't fix. Computers do not have infinite precision. Double precision floats (which the engine uses for position values - in fact, what Javascript uses for all number values) only give you about 15 significant digits of precision; summing floating point values introduces further error which accumulates with the square of the number of additions (this is increasing exponentially every tick), and therefore probably loses you a few extra digits of precision after a few moments. Therefore moving the player tens of millions of pixels away and then trying to move them slowly uses up just about all the precision you've got, and the errors become noticable. This is not a C2 bug and will happen with any framework or technology at all that makes use of floating point numbers. There does not appear to be any reason for you to use such large values, especially when the actual motion in the game appears to be slow... so you need to redesign your games to use values in a much more reasonable range.

Hi. Thanks for the detailed answer! I suspected it had something to do with precision.

My use-case is more reasonable than the demo I attached above, as it was mainly an extreme example. In short, I'm trying to create a space game/simulator with massive distances in relation to scales. In practice, I won't get to the extreme distances shown in the demo, but enough to notice some minor stuttering.

I'm thinking of ways to circumvent this limitation. Do you think it would help if I now and then move all active objects in the layout, including the player, to position 0,0? Thus, they would maintain their relative distances, but the "active zone" that includes the player and the player camera would never move too far off the center.

Basically, what I mean is that when the player gets too far away, he's moved to position 0,0, but the world around him is moved as well.

Yes, that would work - or just keep the player still, and simulate movement by moving the world around them, creating things as they get near and destroying them as they get far away.

Good idea! It worked almost perfect just placing all objects in a family and looping them each tick. Next to no performance loss. Thanks a lot for your help.

System Every tick
    Local number PlayerX = 0
    Local number PlayerY = 0
    Set PlayerX to Player.X
    Set PlayerY to Player.Y
    Player: Set position to (0,0)
    Scroll to Player
    For each Objects
        Objects Set position to (Self.X-PlayerX, Self.Y-PlayerY)

Holy crap! Construct 2's plugin system is amazing!

I just spent 10 minutes fiddling with the default particles plugin, added 6 lines of sweet js code, and suddenly the particles follow their emitter.

It should be easy to add it as an option to the GUI so that it can be set for each emitter.

I'm also thinking of adding an event action to manually move all particles on screen, which would likely be a breeze as well.

Ashley, would you consider adding this functionality to the official plugin if I make these modifications? I guess I'll start by making a custom copy of the particles plugin for my project, but then I would have to manually merge it with the official plugin when it gets updated.

SirSpunky, I would love to see the script modifications you made. I was wanting particles to follow their emmiter for other reasons (mostly I want some effects not to trail around).