I have a character that it moves upward and it has a camera that follows it. Building the project on my computer the game hasn’t problems. But, bundling the game on mobile the character starts progressively wiggling as it moves on.
I have tried both orthographic camera and rendercam and it has the same effect.
This is what happens on my iPhone 6 with iOS 12.2 (I have even tried on an Android device and it does the same thing):
It’s maybe different than wiggle in my project since your project work without any problem on my desktop.
From what I’ve heard is that position floating points loose precision on big numbers and you are moving 1000 pixels in second (by floated number per frame).
Just an idea - try this in player script
function update(self, dt) local pos = go.get_position("hero") pos.x = pos.x + 1000 * dt local p = pos p.x = math.floor(p.x) go.set_position(p, "hero") end
Thanks for the suggestion.
I tried that but unfortunately the result was the same.
I should also have mentioned that this is a simplification of a problem on my actual game, where there is a character that can jump on different platforms that evolves upwards, and when the character reaches high y coordinates, when it jumps, it wiggles like the gif posted above. So I think that the problem is related on the coordinates when they become very big.
That seems weird problem to have in Game engine. Never heard such problem in Gamemaker where are no vector3 for position, just variables x & y.
I’m almost 100% sure this has to do with shader precision. You could try to go from lowp to mediump or highp in the shader.
Even better would be to keep the player closer to 0 and move the rest of the elements.
Does it means it renders on world position not view port of camera?
Seems, not very practical.
The position of your game object will translate to a world position when rendered. The camera will render at a specific position in the world. We will not translate everything to 0 before it is rendered.
Thanks, that solved my problem.
But if you move all the objects and keep the player still, this issue would affect every object. Seems like the only way is to change the shader precision.
So many games do this! It is a common solution to this very common problem. It is interesting that it is necessary, though.
Another piece of advice involves use lerping (is that the right word?) instead of setting position directly.
You will draw what is around the player and that will be drawn at around 0x0 where the precision is good.
You would parent everything in the game world to a root game object and only move that object, not all objects.
So basically I would need to put Player, tiles, background, etc under parent GO and whatever amount player moves I set the reverse value to parent GO?
That’s a weird solution but not a “deal-breaker” solution. Since my only real extended experience is with Gamemaker I know only the way it handled the situation and it is totally different and has no such problem, whatever the coordinates camera and objects are. Unless it offsets world in the backend automatically.
It all depends on the size of your world. For an endless runner it’s the de facto way of creating such games. For a platformer or top down game with moderately sized levels you don’t have to do it. For larger worlds it might not be needed if you increase the shader precision. What kind of game are you making? What’s the size of your game world?
Oh, for endless runner that’s understandable.
I’m primarily interested in platformer games and that made me a bit worried about world size, but if that trick of offsetting parent doesn’t give performance hit, I have no problem with that.
But for a platformer game we’re likely not talking about super large levels right?
What is “super large levels”?
I’m a pixel art lover so, let’s say NES Contra or Megaman sized levels, but what if I’ll do team-up it probably will be bigger scale.
I took a look at Megaman 1 levels and the size is in the range of around 5-6000 pixels. Not sure what kind of precision that is required to render in this range without problems. @Mathias_Westerdahl and @jhonny.goransson do you have some input?
Imho, this is subjective.
In the range [4196, 8192) you have the precision 0.00048828125 which might not seem “large” enough to look weird, but remember that floating point “errors” progagate when you multiply with other floating point values (which the engine does a lot), so you’ll most likely see the errors grow.
E.g. in Just Cause, where the gameworld is 32km2, the coordinates are in the range [-16384,16384] and the single floating point precision is 0.000976562.
Each 512x512 meter patch, and all the objects in that patch, are translated back to origin, and updated in that space in order to keep precision high. If that wasn’t done, the animations would look very jerky, and the models/meshes wouldbn’t align properly etc.
